当前位置：首页 > 域名

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

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

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

站点业务通过RPC接口，到底调用基础数据服务; 基础数据服务通过DAO，需不需服从db/cache获取数据; db/cache存储数据;

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

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

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

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

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

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

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

垂直业务要通过多个RPC接口访问不同的基础数据服务，服务器托管服务共享是服务化的特征; 每个基础数据服务访问自己的数据存储，数据私有也是服务化的特征;

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

基础数据服务与存储层之间连接关系很清晰; 业务站点层与基础数据服务层之间的连接关系错综复杂，变成了蜘蛛网;

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

首先调用商业基础服务，获取商业广告帖子数据，用于顶部置顶/精准的广告帖子展示; 再调用搜索基础服务，获取自然搜索帖子数据，用于中间自然搜索帖子展示; 再调用推荐基础服务，获取推荐帖子数据，用于底部推荐帖子展示; 再调用用户基础服务，获取用户数据，用于右侧用户信息展示; …

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

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

一旦一个服务RPC接口有稍许变化，所有上游的系统都需要升级修改; 子系统之间很可能出现代码拷贝; 一旦拷贝代码，出现一个bug，多个子系统都需要升级修改;

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

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

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

业务站点层，可以通过RPC接口，像调用本地函数一样，调用通用业务服务，一次性获取所有通用数据; 通用业务服务，也可以通过多次调用基础数据服务提供的RPC接口，分别获取数据，底层数据获取的复杂性，全都屏蔽在了此处;

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

这样的好处是：

复杂的从基础服务获取数据代码，只有在通用业务服务处写了一次，没有代码拷贝; 底层基础数据服务接口发生变化，只有通用业务服务一处需要升级修改; 如果有bug，亿华云计算不管是底层基础数据服务的bug，还是通用业务服务的bug，都只有一处需要升级修改; 业务站点层获取数据更便捷，获取所有数据，只需一个RPC接口调用;