amp 调用链_我司微服务调用链非常的长，A调用B B调用M。调用混乱，形成蜘蛛侠。该如何治理，中台能解决么？...

很多开发觉得服务互调没问题，这一点正好把微服务的“自治”这一点一拳打到了十万八千里外。假想你是两个平级的服务，在没有BFF、Application这一层的情况下，直接接入到了前端，业务入口竟然是一个Service，简直滑天下之大稽。

问题是什么？怎么办？

A、B两个同级服务相互依赖，A挂了，B还能自治吗？注意，他们是同级服务。换一层来举例子，你的MySQL依赖Redis，你访问Redis相关业务是走MySQL的一个入口，因为这个业务一开始需要MySQL做一点事情，有一天你的Redis挂了，然后你的MySQL的部分功能也出了问题。这不是滑稽是什么？

要系统的解决这个问题很难，首先取决于你司的成本，其次取决于你们运气够不够好，能不能找招到一个能够全局的去按照你司具体问题去说服上层拿到资源(如果你就是老板当我没说)，并对组织架构进行大刀阔斧的改革，并根据当前研发的现状去推动这些事情。

梳理业务

要做的第一件事情你们先要梳理业务，如果业务特别复杂，这一步就够你们喝几壶的了，怎样梳理，梳理成怎样，产出是什么？你需要真正的搞清楚这个问题。以我的角度来看，产出物是不限的，可以是图文、BPMN、也可以是一系列UML图，也可以是纯文字，但有两个前提分别是：

(1)产出物一定是符合你们业务结构的，按照你们业务场景和业务主体进行分类，并严格划分边界。如果是长时间在迭代的系统，且没有历史文档，产出业务逻辑的启动可以考虑使用 Event Stroming。怎么做Event Stroming，网上已经有很多教程了。

(2)产出物需要大部分人都能看得懂。在考虑到后续维护、交接成本的时候，这一点尤为重要。如果只有少部分人能看懂，这个文档意义就不算很大了。如果只有少部分人能维护，那一定要进行培训，如何维护，并指定相应的维护规范，严格把控文档的质量。

下一步该做什么？

如果梳理出来你的业务概念不是很多，你的Use Case也不是很多，再展望一下后续几个月的需求，如果没有多到你不借助笔记/文档/图形就不能很详细的清楚的情况，那你需要的可能是一些技术上的编排解决方案，而不是整个组织架构和业务的重构。到这一步可以参考其他提供了编排方案的回答。

如果梳理出来整体的业务多到不能脱离文档一次性完整数出来，就可以考虑做整体调整和重构了。

在复杂业务中，严格分层是很有必要的，首先能保证下游业务的自治和业务概念的统一，单一服务维护者只用考虑一个服务的上下文，基本不需要和同级其他业务交互。业务流实现在BFF/Application层便于业务流的控制和维护，将业务流和业务能力相互分开。这样的好处在于业务能力可以决定业务流的上限，单一业务组可以在垂直业务中深耕业务能力。无论是产品、研发都可以非常直观的提供出当前服务所能提供的能力，对公司内部资源的利用和规划都能提供很大的帮助。

重构 or 2.0

第二件事就到了开发痛苦的时候了，就是按照文档，并结合现在的代码进行重构，并制定重构方案和成本，并与重新按照文档实现比较，如果在没有梳理完全的情况下这两步并行，如果非常在意业务的完整性，那只能做重构，且开发时间也不是很确定了。在交给开发时，需要明确的几点是：

(1)同级服务不允许直接依赖，必须完成单元的业务实现，比如你是订单服务，那只允许集成订单相关的概念，同层其他业务概念不允许入侵到这个服务。

(2)增加一层集成层(BFF/Application层)做业务集成，产品提的业务需要在这一层实现，体现为产品提的Use Case作为单元测试实现在代码中。在这一层中做各个服务之间的集成。

比如你的业务场景是：可以直接购买一件商品。原来的调用链是

【商城(前端)】->【商品目录】->【订单】->【支付]

增加了这一层之后变为：

【商城(前端)】->【商城(BFF/App)】->【商品目录】

【商城(BFF/App)】->【订单】

【商城(BFF/App)】->【支付】

这样就能确保业务流完全在【商城(BFF/App)】中，其他的服务解耦(因为就没有同级调用了)，确保了，如果支付挂了，订单、商品目录是不受影响的。

一致性

维护

(未完待续)