在“高内聚 低耦合”的微服務思想熏陶下，現在的系統規劃建設專業化程度越來越高，職能定位也日漸清晰。或者說大家起碼都知道了什麼是正确的事情，隻不過在實施層面有可能視實際情況決定一步邁過去，或者戰術迂回達到目的。

本文所探讨的問題是一些因為業務流程或者數據流程的先後關系導緻的系統間架構耦合的現象及解決思路，造成系統間互為上下遊，即一個系統的輸出數據是另一個系統的輸入數據，反過來，該系統加工後輸出的數據還需要再提供給原系統使用。

為了加深理解，我們将上述描述的數據流抽象成如下的示意圖，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系統，從效果上看可以效解決此類問題。

這是一段最原始的，從文字角度解釋“耦合”的描述，也許可以引起大家的思考。 “耦”字為左右結構，左為“耒”、右同“偶”。“耒”是中國起源最早的一種翻土農具，“偶”指的是成雙不奇。“耒”和“偶”以左右結構所形成的“耦”指兩人并肩而耕，聯合使用農具耕地。

系統間和系統内的服務邊界問題其實一直貫穿着我們對項目管理的思考，微服務思想“理解”和“貫徹”是兩回事，甚至“理解”這個問題是遠遠簡單于“貫徹的實踐”。

需要的是每次遇到技術方案抉擇時，都要堅持做正确的事，而不是做簡單的事。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!