《互联网分层架构的本质》简述两个观点：互联网分层架构的本质是数据移动互联网分层架构演进的核心原理：是为了让上游更高效地获取和处理数据，让下游可以屏蔽数据获取的细节《分层架构：什么时候抽象DAO层，什么时候抽象数据服务层》的要点是：当手写代码从DB获取数据成为普遍痛点时，应该抽象DAO层来简化数据获取流程，提高数据获取效率，以及屏蔽上游的潜在复杂性。系统越复杂，系统的垂直拆分就越多。数据库实现水平拆分，数据层实现缓存加速。当底层数据获取的复杂性成为普遍痛点时，数据服务层应该被抽象出来，简化数据获取。流程，提高数据获取效率，向上游屏蔽底层的复杂性之后，一个业务系统的后端架构如上：web-server通过RPC接口从基础数据服务中获取数据。基础数据服务通过DAO从db/cache获取数据。db/cache存储数据。它不会保持不变：随着业务变得越来越复杂，业务将继续垂直拆分。随着数据越来越复杂，基础数据服务也会越来越多。于是，系统架构就变成了上图这样，业务垂直拆分。基础数据服务有几种：垂直业务需要通过多个RPC接口访问不同的基础数据服务。服务共享是一种面向服务的特性。每个基本数据服务都访问自己的数据存储。数据隐私也是一种面向服务的特性。架构图中的依赖关系看起来是不是很别扭？基础数据服务与存储层的连接关系非常清晰。业务web-server层与基础数据服务层的连接关系错综复杂，已经成为一张蜘蛛网。举个具体的例子，58同城列表页面的web-server是如何获取底层数据的？首先调用商业基础服务获取商业广告贴数据用于置顶/精准广告贴展示，然后调用搜索基础服务获取自然搜索贴数据，用于展示中间的自然搜索贴然后调用推荐基础服务获取推荐帖子数据，用于在底部显示推荐帖子，然后调用用户基础服务获取用户数据，用于右侧显示用户信息&helli;如果只有一个列表页，这样写还可以，但是如果有多个列表页，比如招聘、房产、二手、二手车、黄页等，大部分都是公用数据，还有一小部分是个性数据。每次都这样获取数据，效率略低，冗余、重复、每次都要写的特殊代码很多，而且不同业务的上游列表页都依赖同一个底层服务：一次服务RPC接口变化不大，所有上游系统都需要升级修改。代码复制很可能发生在子系统之间。一旦复制代码，出现bug，需要对多个子系统进行升级修改。如何让数据获取更高效、更快捷？业务服务，通用业务服务层的抽象是必须做的。通过抽象通用业务服务层，如58同城“通用列表服务”：web-server层，可以通过RPC接口调用通用业务服务，就像调用本地函数一样，获取所有通用数据和通用业务一次服务，也可以通过多次调用基础数据服务提供的RPC接口，分别获取数据。底层数据获取的复杂性都被屏蔽在这里。连接关系看起来是不是更清晰了？这样做的好处是：从基础服务中获取复杂的数据一般的业务服务只需要写一次代码。没有底层基础数据服务接口的代码拷贝，只需要升级通用业务服务的一部分。如果有bug，不管是底层基础数据服务的bug，还是一般业务服务的bug，需要升级修改的地方只有一个。web-server获取数据更方便。获取所有数据，只需要一次RPC接口调用。越来越多的，当底层数据获取的复杂性成为普遍痛点时，需要抽象通用业务服务，简化数据获取流程，提高数据获取效率，向上游屏蔽底层复杂性。最后强调两点：是否抽象出通用的业务服务，与业务的复杂程度和业务发展的阶段有关，不能一概而论。需要抽象出什么样的通用业务服务，任何脱离具体业务相关业务的架构设计都是流氓。【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此阅读更多该作者好文
