架构设计实例（架构耦合问题之互为上下游的案例）

在“高内聚 低耦合”的微服务思想熏陶下，现在的系统规划建设专业化程度越来越高，职能定位也日渐清晰。或者说大家起码都知道了什么是正确的事情，只不过在实施层面有可能视实际情况决定一步迈过去，或者战术迂回达到目的。

本文所探讨的问题是一些因为业务流程或者数据流程的先后关系导致的系统间架构耦合的现象及解决思路，造成系统间互为上下游，即一个系统的输出数据是另一个系统的输入数据，反过来，该系统加工后输出的数据还需要再提供给原系统使用。

为了加深理解，我们将上述描述的数据流抽象成如下的示意图，A 和 B 分别表示两个系统，数字1表示A系统的输出数据是B 系统的输入数据；数字2表示B系统的输出数据是A系统的输入数据，其本质是B系统需要利用A系统的特定数据经过加工处理后，再提供给A系统进行加工，这种循环式数据流的架构设计我们称之为“互为上下游的系统”，A是B的上游，B是A的上游。

其恶劣影响是造成两个系统的深度耦合而互相等待，如若一个系统出异常，必然是相关系统一起陪着；同样对于耦合系统的老调重弹的问题，往往是只要A系统改造，B系统得跟着动，反之亦然。

问题其实不新鲜，生活中以你的车为例，如果你的音响坏了修一下，却被告知你的车轮也需要更换一个零件，恐怕你很难为此心平气和的买单。当然事实不会，那是因为他们之间是完全松耦合，甚至不相干的。

将场景还原到上述的示意图后，我开始总结思考他们的规律，并试图解决此类问题。经过研究，解铃换需系铃人的思想还是最为淳朴，可行的思路有两种，即分别将上图中的流程1和流程2的通路切断。

解决方案一：“打断通路1”，由源系统直接给B供数，保留B给A的供数逻辑。

这里的改造主要放在了源系统，作为数据源头，由源系统加工并处理好数据分别提供。B系统获得数据后开始处理，向A提供数据。

这里有几个注意点值得讨论，

第一：源系统如果是不同的系统，则需要源系统之间做数据同步，保证数据一致性，或者唯一的系统落地进行汇总最全最正确的数字；

第二：如果源系统仅涉及唯一一个系统，那就还会涉及到另外一个话题，如果此对下游的数据内容要求基本一致，但接口不同，那么反复提供无疑会增加源系统，尤其是加大作为业务系统的性能压力。此时，往往我们会想到引入数据仓库来解决问题，针对实时非实时的数据需求，也是需要有不一样的技术方案。

解决方案二：“打断通路2”，把B中与外部相关逻辑放在A中实现，保留A 到B的流程，将耦合的根因直接摘除，此方案是基于微服务彻底化的思路。

非常典型的案例是核心系统和增值税系统，价税分离功能移到核心或者独立的总账系统中，增值税的职能“弱化”到涉票流水查询及开票功能。此方案的改造工作量主要在A系统，从效果上看可以效解决此类问题。

这是一段最原始的，从文字角度解释“耦合”的描述，也许可以引起大家的思考。 “耦”字为左右结构，左为“耒”、右同“偶”。“耒”是中国起源最早的一种翻土农具，“偶”指的是成双不奇。“耒”和“偶”以左右结构所形成的“耦”指两人并肩而耕，联合使用农具耕地。

系统间和系统内的服务边界问题其实一直贯穿着我们对项目管理的思考，微服务思想“理解”和“贯彻”是两回事，甚至“理解”这个问题是远远简单于“贯彻的实践”。

需要的是每次遇到技术方案抉择时，都要坚持做正确的事，而不是做简单的事。