架构：数据闭环。

我会带着你远行 2022-12-06 15:55 147阅读 0赞

数据闭环，并不是说我们要将所有的功能全包揽在身上，不依赖其他业务方，也不依赖中台。而是想强调一件事，那就是业务问题排查过程尽量不要牵扯过多团队，因为数据链路越长越乱处理问题时效性越差，服务性能往往也不尽人意。我先分享个案例给你，或许能帮助你理解和产生共鸣。

我们有一个内容渠道是直播，渠道权限和创建直播间入口都是我们来维护的，但是创建直播后的内容保存接口是直播团队维护的，保存接口会校验达人权限和等级，而校验接口又是另外一个团队提供的，他们对我们缓存进行了封装。最近发现权限校验异常频发，原因是缓存和数据库状态不一致。可是对于达人或者不知情的人来说，在达人创作平台上碰到的问题就应该由创作端来负责，可真正出现问题的环节不在我们这。

上面的例子暴露出了很多问题，比如业务不是独立性的、其他服务直接共享了缓存。没有备忘录，其他同事根本不会知道还有这种隐藏的逻辑。这就好比一个枚举类在这个系统上修改了，但是在另外一个使用到它的系统却没有同步修改，灾难往往就在不久的将来。想要避免这些问题，那就要做好服务拆分。业内推荐的微服务拆分一般有以下四种：

# 基于业务逻辑拆分 #

一个内容从达人生产到用户能看到，需要经过很多中间过程。涉及到用户成长体系、渠道权限管理、频道样式创作、内容机审人审质检等等。如果中间环节都拆分成单独的业务，而各种样式内容的站内站外分发交由各个频道独立处理，也就是内容从生产到审核都是在闭环的，那案例中的隐藏的大坑就不复存在。每三个同事负责每几个环节的微服务，哪个环节出现问题那就让负责这个环节的同事排查就可以了，不需要多方同时介入，大家各司其职。

按照业务逻辑拆分后，不仅能形成更稳定的接口，还能确保我们能够更好的反映业务流程的变化。另外，每个独立部署的业务都可以使用特定的专业技能进行开发，比如内容推荐算法。每个独立部署的业务都有主要负责的研发，产品也就不需要抢研发资源来满足需求。

# 基于可扩展拆分 #

我们部门负责京东内容生态的建设，服务业务方各种定制化需求，其他事业群比如国际站却以为我们是技术中台，然后要求我们做一个国际化的达人创作平台。不过说实在的，那怕小步慢跑也无法满足他们的需求，因为内容这么多环节都有可能涉及到兼容性问题，比如发现好货中的商品信息上游是否兼容、内容安全校验算法是否兼容等等。

因为我们不是技术中台，没必要将功能以可扩展性为目标进行组件化，实现整套开放赋能，毕竟组织架构影响着技术架构。在这件事情上，我们只能分享经验和体系架构，或者他们觉得某个功能能直接复用，我们肯定大大方方将其拆出来然后贡献出去，让其独立演化，仅止而已。

# 基于可靠性拆分 #

MCN机构达人生产内容然后引导用户购买商品所得到的佣金是他们的命根子，如果出现计算不准确、提现异常的情况，达人就会觉得有猫腻，产生不信任，就会主动离开。而内容由于机器审核异常导致短暂无法正常进入人工审核阶段，是可以接受。可以看出我们对佣金结算和审核系统的可靠性容忍程度截然不同。

另外，佣金结算是一个长期不迭代的、稳定的业务，而审核系统可能会经常引入新的校验逻辑而需要变更上线，也就意味着后者的上线变更可能会直接影响到结算业务。因为代码越是修改，引入不确定性的风险越大。那我们需要避免因为审核系统需求上线变更导致佣金结算业务受到影响。最好的方式就是将他们拆开。

也就是说，一个服务故障发生时产生的影响面很大，它就算系统中很脆弱的部分，我们必须将其拆分出去，将异常隔离。

# 基于性能拆分 #

我们内容人工审核是由外包团体承包的，时常收到他们反馈说，下午6点左右审核页面加载很慢，审核通过按钮需要点好几下才能生效。我们结合数据库IO告警和数据库慢查询来看，那个时间段应该是有人在跑大数据调度任务，可是很难定位到具体的任务。不知道读者有没有体验过这种因为数据源依赖导致个别业务性能受到影响，包括很难优化的数据库慢查询。因此，它们的数据源应该拆分掉，业务同理。

最后多说一点，不管采用何种方式拆分服务，或者何种组合拆分方式，都要注意数据流向，千万不能出现循环依赖，包括使用MQ解藕，那也算一种隐层的依赖。