很多公司都实现了微服务架构，底层抽象出很多基础数据服务。基础数据访问服务后，结构如上：站点业务通过RPC接口调用基础数据服务；基础数据服务通过DAO从db/cache中获取数据；数据库/缓存存储数据；除了基础的数据访问需要服务，业务层需要面向服务吗？如果是这样，它什么时候会面向服务？这是本文要讨论的两个问题。随着时间的推移，系统架构不会一成不变：（1）随着业务越来越复杂，业务会不断垂直拆分；画外音：以58同城为例，有招聘、房产、黄页等服务。（2）随着数据越来越复杂，基础数据服务也会越来越多；画外音，比如：用户服务，订单服务，搜索服务，推荐服务等。所以系统架构变成了上图这样，业务垂直拆分，基础数据服务有几个：垂直业务需要接入通过多个RPC接口服务不同的基础数据，服务共享是服务的一个特性；每个基础数据服务访问自己的数据存储，数据隐私也是服务的一个特点；上面的架构图中的依赖关系看起来是不是很别扭？基础数据服务与存储层的连接关系非常清晰；业务站点层和基础数据服务层之间的连接关系错综复杂，形成了蜘蛛网；举个更具体的例子，58同城列表页站点是如何获取底层数据的？首先调用商业基础服务获取商业广告发布数据，用于置顶/精准广告发布展示；然后调用搜索基础服务获取自然搜索帖子数据，用于中间的自然搜索帖子展示；然后调用推荐基础服务获取推荐帖子数据，用于底部推荐帖子展示；然后调用用户基础服务获取用户数据，用于在右侧展示用户信息；…如果只有一个列表页还好，但是如果有招聘、房产、二手、二手车、黄页等多个业务，公共数据会通过这种方式获取，并且只有一小部分个性数据每次都会调用基础服务，每次都会写很多冗余、重复、必要的代码。特别是，不同业务的上游列表页都依赖于同一个底层服务：一旦某个服务RPC接口稍有变化，就需要对所有上游系统进行升级改造；子系统之间很可能发生代码复制；一旦代码被复制，一个Bug，多个子系统需要升级修改；如何让数据获取更高效、更快捷？业务服务，通用业务服务层的抽象势在必行。通过抽象通用业务服务层，如58同城“通用列表服务”：业务站点层可以通过RPC接口调用通用业务服务，就像调用本地函数一样，一次性获取所有通用数据；一般业务服务也可以通过基础数据服务提供的RPC接口多次调用单独获取数据。底层数据获取的复杂性全部屏蔽在这里；连接关系看起来是不是更清晰了？这样做的好处是：从基础服务获取数据复杂，一般业务服务只写一次数据代码，没有代码拷贝；底层基础数据服务接口发生变化，只需要升级一部分通用业务服务；如果有bug，不管是底层基础数据服务的bug，还是一般业务服务的bug，都只有一个，需要升级修改；业务站点层获取数据更方便，只需调用一次RPC接口即可获取所有数据；因此，当业务越来越复杂，越来越多的系统被垂直拆分，基础数据服务越来越多，当底层数据获取的复杂性成为普遍痛点时，应该将通用的业务服务进行抽象化简化数据采集??流程，提高数据采集效率，屏蔽上游底层复杂性。最后强调两点：（1）需要抽象通用的业务服务，与业务的复杂程度和业务发展的阶段有关，不能一概而论；画外音：如果没有多个业务线，大概率基本服务就够了。（2）需要抽象出哪些通用业务服务，哪些与具体业务相关；画外音：postlistbusinessservices，postdetailbusinessservices，这是58独有的基础服务，比如用户，订单，支付等基础服务，基本上每个公司都是大同小异的。任何倒闭的建筑设计都是耍流氓。【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此阅读更多该作者好文
