业务层，到底需不需要服务化？

发布时间：2025-11-05 02:36:42 来源：创站工坊 作者：域名

很多公司，业务层都实施了微服务架构，到底底层抽象出很多基础数据服务。需不需服

基础数据的业务层访问服务化之后，架构如上：

除了基础数据的业务层访问需要服务化，业务层是到底否需要服务化?如果需要，什么时机进行服务化?需不需服这是本文要讨论的两个问题。

随着时间的业务层推移，系统架构并不会一成不变：

(1)随着业务越来越复杂，到底业务会不断进行垂直拆分;

画外音：以58同城为例，需不需服有招聘、业务层房产、到底二手、需不需服二手车、黄页等多个业务。

(2)随着数据越来越复杂，基础数据服务也会越来越多;

画外音，例如：用户服务，订单服务，搜索服务，推荐服务等。

于是系统架构变成了上图这个样子，业务垂直拆分，有若干个基础数据服务：

上面架构图中的依赖关系是不是看上去很别扭?

再举一个更具体的例子，58同城列表页站点如何获取底层的数据?

如果只有一个列表页这么写还行，但如果有招聘、房产、二手、二手车、黄页等多个业务，都这么获取共性数据，而只有少部分个性数据，每次都这么一个个调用基础服务，有大量冗余、服务器租用重复、每次必写的代码。

特别的，不同业务上游列表页都依赖于底层若干相同服务：

如何让数据的获取更加高效快捷呢?

业务服务化，通用业务服务层的抽象势在必行。

通过抽象通用业务服务层，例如58同城“通用列表服务”：

是不是连接关系也看起来更清晰?

这样的好处是：

于是，当业务越来越复杂，垂直拆分的系统越来越多，基础数据服务越来越多，底层数据获取复杂性成为通用痛点的时候，就应该抽象出通用业务服务，简化数据获取过程，提高数据获取效率，向上游屏蔽底层的复杂性。

最后再强调两点：

(1)是否需要抽象通用业务服务，和业务复杂性，以及业务发展阶段有关，不可一概而论;

画外音：如果没有多个业务线，大概率基础服务就够用。

(2)需要抽象什么通用业务服务，和具体业务相关;

画外音：帖子列表业务服务，帖子详情业务服务，是58同城特有的;而基础服务，例如用户，订单，支付等基础服务，基本上各个公司是类似的。

任何脱离业务的架构设计，都是耍流氓。

【本文为专栏作者“58沈剑”原创稿件，转载请联系原作者】

戳这里，看该作者更多好文

相关文章