您现在的位置是：亿华云 > 人工智能
啊，业务层是否也需要服务化？
亿华云2025-10-02 19:05:50【人工智能】5人已围观
简介《互联网分层架构的本质》简述了两个观点：互联网分层架构的本质，是数据的移动 互联网分层架构演进的核心原则：是让上游更高效的获取与处理数据，让下游能屏蔽数据的获取细节 《分层
《互联网分层架构的啊本质》简述了两个观点：
互联网分层架构的本质，是业务也需数据的移动 互联网分层架构演进的核心原则：是让上游更高效的获取与处理数据，让下游能屏蔽数据的层否获取细节《分层架构：什么时候抽象DAO层，什么时候抽象数据服务层》中的服务观点是：
当手写代码从DB中获取数据，成为通用痛点的啊时候，就应该抽象出DAO层，业务也需简化数据获取过程，层否提高数据获取效率，服务向上游屏蔽底层的啊复杂性 当业务越来越复杂，垂直拆分的业务也需系统越来越多，数据库实施了水平切分，层否数据层实施了缓存加速之后，服务底层数据获取复杂性成为通用痛点的啊时候，就应该抽象出数据服务层，业务也需简化数据获取过程，层否提高数据获取效率，向上游屏蔽底层的复杂性文本将要解答的问题是：
基础数据的云南idc服务商访问需要服务化，业务层是否需要服务化 如果需要服务化，什么时候服务化
基础数据的访问服务化之后，一个业务系统的后端架构如上：
web-server通过RPC接口，从基础数据service获取数据 基础数据service通过DAO，从db/cache获取数据 db/cache存储数据随着时间的推移，系统架构并不会一成不变：
随着业务越来越复杂，业务会不断进行垂直拆分 随着数据越来越复杂，基础数据service也会越来越多
于是系统架构变成了上图这个样子，业务垂直拆分，有若干个基础数据服务：
垂直业务要通过多个RPC接口访问不同的基础数据service，service共有是服务化的特征 每个基础数据service访问自己的数据存储，数据私有也是服务化的特征这个架构图中的依赖关系是不是看上去很别扭?
基础数据service与存储层之前连接关系很清晰 业务web-server层与基础数据service层之间的连接关系错综复杂，变成了蜘蛛网再举一个更具体的例子，58同城列表页web-server如何获取底层的数据?
首先调用商业基础service，获取商业广告帖子数据，站群服务器用于顶部置顶/精准的广告帖子展示 再调用搜索基础service，获取自然搜索帖子数据，用于中部自然搜索帖子展示 再调用推荐基础service，获取推荐帖子数据，用于底部推荐帖子展示 再调用用户基础service，获取用户数据，用于右侧用户信息展示 …如果只有一个列表页这么写还行，但如果有招聘、房产、二手、二手车、黄页…等多个大部分是共性数据，少部分是个性数据的列表页，每次都这么获取数据，就略显低效了，有大量冗余、重复、每次必写的代码。
特别的，不同业务上游列表页都依赖于底层若干相同服务：
一旦一个服务RPC接口有稍许变化，所有上游的系统都需要升级修改 子系统之间很可能出现代码拷贝 一旦拷贝代码，出现一个bug，多个子系统都需要升级修改如何让数据的获取更加高效快捷呢?
业务服务化，通用业务服务层的抽象势在必行。亿华云
通过抽象通用业务服务层，例如58同城“通用列表服务”：
web-server层，可以通过RPC接口，像调用本地函数一样，调用通用业务service，一次性获取所有通用数据 通用业务service，也可以通过多次调用基础数据service提供的RPC接口，分别获取数据，底层数据获取的复杂性，全都屏蔽在了此处是不是连接关系也看起来更清晰?
这样的好处是：
复杂的从基础服务获取数据代码，只有在通用业务service处写了一次，没有代码拷贝 底层基础数据service接口发生变化，只有通用业务service一处需要升级修改 如果有bug，不管是底层基础数据service的bug，还是通用业务service的bug，都只有一处需要升级修改 业务web-server获取数据更便捷，获取所有数据，只需一个RPC接口调用
结论：
当业务越来越复杂，垂直拆分的系统越来越多，基础数据服务越来越多，底层数据获取复杂性成为通用痛点的时候，就应该抽象出通用业务服务，简化数据获取过程，提高数据获取效率，向上游屏蔽底层的复杂性。
最后再强调两点：
是否需要抽象通用业务服务，和业务复杂性，以及业务发展阶段有关，不可一概而论 需要抽象什么通用业务服务，和具体业务相关任何脱离业务的架构设计，都是耍流氓。
【本文为专栏作者“58沈剑”原创稿件，转载请联系原作者】
戳这里，看该作者更多好文
很赞哦!（4512）
上一篇： 数据中心可持续运营策略
下一篇： 戴尔科技集团打造现代化数据安全方案
