不少公司，都实施了微服务架构，底层抽象出不少基础数据服务。
（2）基础数据服务经过DAO，从db/cache获取数据；
除了基础
数据的访问须要服务化，业务层是否须要服务化？若是须要，什么时机进行服务化？这是本文要讨论的两个问题。
（1）随着业务愈来愈复杂，业务会不断进行垂直拆分；
画外音：以58同城为例，有招聘、房产、二手、二手车、黄页等多个业务。
（2）随着数据愈来愈复杂，基础数据服务也会愈来愈多；
画外音，例如：用户服务，订单服务，搜索服务，推荐服务等。
因而系统架构变成了上图这个样子，业务垂直拆分，有若干个基础数据服务：
（1）垂直业务要经过多个RPC接口访问不一样的基础数据服务，服务共享是服务化的特征；
（2）每一个基础数据服务访问本身的数据存储，数据私有也是服务化的特征；
（2）业务站点层与基础数据服务层之间的链接关系错综复杂，变成了蜘蛛网；
再举一个更具体的例子，58同城列表页站点如何获取底层的数据？
（1）首先调用商业基础服务，获取商业广告帖子数据，用于顶部置顶/精准的广告帖子展现；
（2）再调用搜索基础服务，获取天然搜索帖子数据，用于中间天然搜索帖子展现；
（3）再调用推荐基础服务，获取推荐帖子数据，用于底部推荐帖子展现；
（4）再调用用户基础服务，获取用户数据，用于右侧用户信息展现；
若是只有一个列表页这么写还行，但若是有招聘、房产、二手、二手车、黄页等多个业务，都这么获取共性数据，而只有少部分个性数据，每次都这么一个个调用基础服务，有大量冗余、重复、每次必写的代码。
特别的，不一样业务上游列表页都依赖于底层若干相同服务：
（1）一旦一个服务RPC接口有稍许变化，全部上游的系统都须要升级修改；
（3）一旦拷贝代码，出现一个bug，多个子系统都须要升级修改；
经过抽象通用业务服务层，例如58同城“通用列表服务”：
（1）业务站点层，能够经过RPC接口，像调用本地函数同样，调用通用业务服务，一次性获取全部通用数据；
（2）通用业务服务，也能够经过屡次调用基础数据服务提供的RPC接口，分别获取数据，底层数据获取的复杂性，全都屏蔽在了此处；
（1）复杂的从基础服务获取数据代码，只有在通用业务服务处写了一次，没有代码拷贝；
（2）底层基础数据服务接口发生变化，只有通用业务服务一处须要升级修改；
（3）若是有bug，无论是底层基础数据服务的bug，仍是通用业务服务的bug，都只有一处须要升级修改；
（4）业务站点层获取数据更便捷，获取全部数据，只需一个RPC接口调用；
因而，当业务愈来愈复杂，垂直拆分的系统愈来愈多，基础数据服务愈来愈多，底层数据获取复杂性成为通用痛点的时候，就应该抽象出通用业务服务，简化数据获取过程，提升数据获取效率，向上游屏蔽底层的复杂性。
（1）是否须要抽象通用业务服务，和业务复杂性，以及业务发展阶段有关，不可一律而论；
画外音：若是没有多个业务线，大几率基础服务就够用。
画外音：帖子列表业务服务，帖子详情业务服务，是58同城特有的；而基础服务，例如用户，订单，支付等基础服务，基本上各个公司是相似的。
本文分享自微信公众号 - 架构师之路（road5858）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。微信
