查看原文
其他

啊,业务层是否也需要服务化?

2017-10-18 58沈剑 架构师之路

互联网分层架构的本质》简述了两个观点:

  • 互联网分层架构的本质,是数据的移动

  • 互联网分层架构演进的核心原则:是让上游更高效的获取与处理数据,让下游能屏蔽数据的获取细节

 

分层架构:什么时候抽象DAO层,什么时候抽象数据服务层》中的观点是:

  • 当手写代码从DB中获取数据,成为通用痛点的时候就应该抽象出DAO层,简化数据获取过程,提高数据获取效率,向上游屏蔽底层的复杂性

  • 当业务越来越复杂,垂直拆分的系统越来越多,数据库实施了水平切分,数据层实施了缓存加速之后,底层数据获取复杂性成为通用痛点的时候就应该抽象出数据服务层,简化数据获取过程,提高数据获取效率,向上游屏蔽底层的复杂性

 

文本将要解答的问题是:

  • 基础数据的访问需要服务化,业务层是否需要服务化

  • 如果需要服务化,什么时候服务化

 

基础数据的访问服务化之后,一个业务系统的后端架构如上:

  • 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接口调用

 

结论

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

 

最后再强调两点:

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

  • 需要抽象什么通用业务服务,和具体业务相关

 

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

 

若有收获,随手帮转哟。

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存