《互联网分层架构的本质》简述了两个观点:
《分层架构:什么时候抽象DAO层,什么时候抽象数据服务层》中的观点是:
文本将要解答的问题是:
基础数据的访问服务化之后,一个业务系统的后端架构如上:
随着时间的推移,系统架构并不会一成不变:
于是系统架构变成了上图这个样子,业务垂直拆分,有若干个基础数据服务:
这个架构图中的依赖关系是不是看上去很别扭?
再举一个更具体的例子,58同城列表页web-server如何获取底层的数据?
如果只有一个列表页这么写还行,但如果有招聘、房产、二手、二手车、黄页…等多个大部分是共性数据,少部分是个性数据的列表页,每次都这么获取数据,就略显低效了,有大量冗余、重复、每次必写的代码。
特别的,不同业务上游列表页都依赖于底层若干相同服务:
如何让数据的获取更加高效快捷呢?
业务服务化,通用业务服务层的抽象势在必行。
通过抽象通用业务服务层,例如58同城“通用列表服务”:
是不是连接关系也看起来更清晰?
这样的好处是:
结论:
当业务越来越复杂,垂直拆分的系统越来越多,基础数据服务越来越多,底层数据获取复杂性成为通用痛点的时候,就应该抽象出通用业务服务,简化数据获取过程,提高数据获取效率,向上游屏蔽底层的复杂性。
最后再强调两点:
任何脱离业务的架构设计,都是耍流氓。