內容來源：小代嘚吧嘚
作者：代堂鳴
其實說起“松耦合”，想必絕大多數 IT 從業者都對這個詞耳熟能詳，甚至都會覺得完全不用再對它進行任何闡述。但不得不說，在銀行IT系統建設過程中，不同干係人對“松耦合”具有不同的看法和認識。
從設計的角度看，如果系統內一個模組設計的變動不會引起另一個模組變動，模組間能夠靈活組合，那麼我們會說他設計的模組是松耦合的；從開發的角度看，如果修改一個元件的時候不影響其他元件，不會導致一連串的程式需要修改，那麼我們就說他的程式碼是松耦合的；從測試的角度看，符合松耦合的程式會更易於對區域性進行黑盒測試。
所以針對專案中的不同角色，多維度梳理銀行IT系統中松耦合的內容，並進行深入探討很有必要。在寫作的過程中，參考了很多資料並結合自己的理解，做了一些梳理和重新表達。歸納的也並不完善，歡迎大家補充。
“耦合”一詞被廣泛運用在通訊、軟體、機械等許多領域。其實就是用以描述偶數以上多體系的相互作用/彼此影響/互相聯合的現象。在軟體工程中，耦合指模組之間相互依賴對方的一個度量。模組間聯絡越緊密，其耦合性就越強，模組的獨立性則越差，維護成本也就越高，為了便於維護，自然是希望耦合越低越好。從事務間的關係上來看，可以分為組織耦合、執行耦合（流程耦合與資料耦合）、空間（地域）耦合、時間耦合；從耦合的機制上來看，還可以分為內容耦合、公共耦合、外部耦合、控制耦合、印記耦合、資料耦合和非直接耦合。例如，控制耦合指的是如果一個模組透過傳送開關、標誌等控制資訊，明顯地控制選擇另一模組的功能，就是控制耦合。 總之，只要事物之間相互影響、相互作用，都可以理解為是一種耦合。在系統執行中，基於某業務場景的兩個耦合方，有一方會向另一方發起一個執行耦合的要求，而另一方會進行相應的響應。我們把執行耦合的發起方稱之為：請求方；把響應方稱之為：服務方。比如銀行核心系統外調密管平臺，用於MAC生成、MAC地址驗證、驗密、設密等操作。那麼，我們將銀行核心系統稱為請求方；把密管平臺稱為服務方。又如，手機銀行調核心系統查詢賬戶資訊，那核心系統就是服務方。耦合點是指請求方與服務方之間的連線點，還可以細分為單點接入和多點接入。例如，支付系統大/小額直聯介面系統支援總行單點接入模式，即所有分行的交易透過總行一個單點接入人行支付系統。還支援總分行多點接入方案，即系統能夠支援總分行以不同的 MBFE 接入支付系統或同一城市多家分行接入支付系統的模式。拿傳統胖核心來說，隨著銀行業務的高速發展，核心系統所承載的交易範圍越來越多，包含了業務模組和管理功能，如信貸管理、風險管理、財務管理等業務中部分流程管理的功能。這些原因導致了系統升級困難，牽一髮而動全身，改造風險較大，難以快速響應業務發展和創新。所以，現在建設系統都講究松耦合。在《銀行資訊系統架構》一書中，關於松耦合是這麼說的：“松耦合原則是指要建立松耦合的體系架構，減少某一些系統的變動和故障對全域性的影響，提高架構的靈活性和擴充套件性，實現與敏捷業務相適應的IT架構。”以桌上型電腦為例，它由顯示器、主機箱、鍵盤滑鼠等硬體組成，各部分都是松耦合的。如果某一部分壞了，可以很容易就拆下來換新的或者維修，即松耦合的可維護性；如果要換音響，買個新的連線上就好了，即松耦合的可擴充套件性。
對於緊耦合的系統，其主要缺點在於程式程式碼間關聯度過高，不利於模組化處理，出現更新一個模組的結果，引發其它模組的結果也發生變化的窘境。那耦合度該怎麼衡量呢？可以透過耦合點&耦合方的多少、大小等方面來思考。耦合點越少越好，主要是為了避免一個類承擔的職責過多，即單一原則。如果一個類有多於一個的動機被改變，那麼這個類就具有多於一個的職責，則一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當發生變化時，設計會遭受到意想不到的破壞。所以，對於一個類應該儘量只專注於做一件事，而且引起它改變的因素只應該有一個。因此，耦合點越少越好，不僅僅是降低耦合，而且它也使得程式碼變得整潔明瞭、便於維護、降低管理成本。當然在取捨實現的時候，更多的是靠經驗和對業務邏輯的理解。耦合點越小越好，主要是為了避免“胖”介面出現，即介面隔離原則，指儘量細化介面，使用多個小而專的介面，而不要使用一個大的總介面。因為胖介面不僅僅是設計上的一種“浪費”，而且在實施上會帶來潛在的問題，所以對其進行修改將導致一連串的程式需要修改，有時候這是一種災難。例如，貸款程式要呼叫活期動賬程式，那麼貸款程式會透過通訊區將介面資訊傳遞給活期動賬程式，由於活期動賬程式包含了入賬和扣賬的處理，所以通訊區包含的耦合內容較多。應該將活期動賬程式分為入賬和扣賬兩個介面，每個介面只提供跟這個介面最直接的服務，將與之無關的全部隔離出去。不難看出，對介面進行細化可以提高程式設計靈活性是不爭的事實，但一定要適度，如果過小，則會造成介面數量過多，使設計複雜化。總之，要能減弱介面間的耦合性，那麼維護相對較多的介面也比維護一個龐大臃腫的介面要強。耦合方要求越低越好，主要是不希望類之間建立直接的聯絡，即迪米特法則，又叫最少知識原則。因為每個物件儘量減少對其他物件的瞭解，所以很容易使得系統的功能模組功能獨立，相互之間不存在（或很少有）依賴關係，更有利於複用，一個處在弱耦合的類被修改，不會對有關係的類造成波及。就好比請求方無需關心服務方的具體實現操作，當需要更換操作時，修改配置檔案，使得程式穩定，實現了請求方與服務方的松耦合。關於衡量耦合度的思路，就列舉到這裡。總的來說，耦合的強弱取決於模組間介面的複雜性、呼叫模組的方式以及透過介面傳送資料的多少。
我們經常在分析系統耦合度的過程中不知道該怎麼去梳理，或者當我們接觸到系統的時候，不知道該從哪些角度去分析系統的松耦合情況。對於這問題我們需要對系統進行全方面的分析，那就來一起聊聊，對銀行IT系統進行分析時能夠了解到的內容。生活中的很多物品都是由若干個零件組成，有手機、電腦等等。以麵包機為例，在我們印象中是這樣的：但麵包機經過拆解之後，大概有400多種零件，每個零件都是單獨存在的，而且是看得見摸得著。如果某個零件壞了，我們只要替換下來換一個好的再安裝就可以了。不難發現，這些零件與我們軟體工程中的元件有共通之處，比如可被組裝、有重複的部分等等。那回到主題，實現元件松耦合，該具有什麼樣的特性呢？我認為有以下幾點：介面的定義在系統設計過程中發揮著重要的作用，不管是在日常練習還是工作中，我們每個人都少不了要定義各種介面(interface)，有系統整合、有前後臺呼叫。介面的定義能在一定程度上反應程式設計師的程式設計功底或業務能力，可以看出有的人著重實現細節，有的更注重整體性......這都體現了背後所隱含的設計思想和設計理念的差異，定義的好，能規避掉很多無用的返工修改和可能出現的問題。在計算機發展的初期，程式設計師們使用機器語言來進行程式設計運算，可以理解為只有計算機能夠識別的一套0,1編碼。後來為了便於閱讀，出現的組合語言代替了機器語言的二進位制碼。當計算機語言發展到第三代時，就進入了“面向人類”的高階語言。隨著軟體開發規模愈來愈大，早期應用與資料之間多對多做法的弊端逐漸凸顯，導致軟體難以維護，比如修復一個Bug而引發更多Bug，以及軟體開發人員之間的資訊交流不準確等，因此容易產生疏漏和錯誤。那就需要一整套方法來規範這些人和事，所以引入了工程學的概念，即軟體工程。也就是現在的核心繫統都已能做到應用與資料松耦合的原因了，比如將資料庫的增刪改查封裝到類中、早期報表與應用程式和資料的解耦等。以資料庫的封裝來說，好處在於將變化隔離，便於使用、提高了重用性和安全性。規則如下：流程松耦合的前提是能準確對交易干係人的行為進行分析，這就需要我們瞭解清楚干係人在交易中的需求或是服務。如果對行為分析的不到位，一定會對業務流程分析產生一定的影響，甚至是庫表結構等資料層面的松耦合。因此設計一套簡潔，耦合度低的流程是非常重要的。比如，銀行櫃員為公司客戶提供金融服務，這就進入了公司業務條線，其中會包含存款、貸款、貿易融資、供應鏈、現金管理等具體業務。但這個粒度太粗，可以按不同的角色在對業務中承擔的職責進行逐步拆解。再如，銀行櫃員在為客戶辦理金融交易時，無需關心會計資訊，對核心這種交易系統而言也一樣，所以可以對前端業務的辦理與後臺的賬務處理進行解耦，就是我們常提到的交易與核算分離，也可以按上述方法進行分析。又如，採用非同步的方式連線本系統與第三方系統，這也算是一種解耦；再如，採用ESB服務匯流排的方式設定系統內部和系統間的服務呼叫，減少系統間的耦合性，便於系統的功能擴充套件等等。雖然這個抽絲剝繭過程主要依賴於設計者的經驗，而且需要不斷摸索、總結和反覆驗證。但只有這樣，才能打通業務和技術，落實對流程IT元件的生產和組裝，以及對業務按場景、事件等維度的流程配置和動態調整，實現流程松耦合。資料耦合在百度百科中是這麼說的，指的是兩個模組之間有呼叫關係，傳遞的是簡單的資料值，相當於高階語言的值傳遞。例子如下：確實是這樣的，再換個角度，說資料拆分。資料拆分可以與流程分解同步進行，有利於明確資料邊界，實現資料層面的解耦。如果我們不懂業務，就聽不懂別人的問題，就提不出好的建議，就無法更好的拆分資料，也就很難達到預期。所以，資料拆分是基於對業務&技術知識和實踐方面，有深入瞭解的前提條件下進行的。以編碼生成的規則為例，有日誌號、錯誤碼、客戶號、賬號、子序號、凍結編號等等。這些都屬於資料松耦合的範疇內。那良好的編碼該具備怎樣的規範呢？當然，各類資料的規範遠遠不止這些，比如客戶合併、機構撤併等場景。因此，除了要對現有資料進行拆分，還要對比各種種解決方案，以及可能存在資料冗餘的問題等，都會影響到後續的介面設計。除了以上介紹的兩種關鍵維度外，還有很多其他方面的松耦合影響著銀行IT系統。比如IT架構管控方面，有專案審查、方案確認、對硬體的依賴程度、程式碼版本控制、系統上線步驟的要求等全生命週期的管理。我們就來簡單嘮嘮。銀行IT系統建設是一個自頂向下逐步細化的過程，對於整個資訊系統來說也一樣，當然這也是很多業界大師都給出過的論證。因為在系統開發的過程中，經常會出現資訊不一致，而這種現象的存在對系統往往是致命的。因此，自頂向下是從整體架構的角度思考，以便達到資訊的一致性。銀行核心系統投產就是一個典型的例子，相信經歷過這激動人心的時刻，都會深有感觸。在短時間、資源緊張的情況下，面對磕磕碰碰，在日夜不懈奮鬥之後，將多個專案組成一個個投產版本，其複雜性與工程量可謂不易。比如對上線時間的考量、是否按子系統分步投產、是否某地域先投產、如何將風險降到最近，怎麼做到客戶無感知等等，這些都是對系統穩定的考驗。以分步投產為例：- 準備：客戶資訊補錄、資料清理、系統培訓、資料遷移、停售部分產品、網路改造、細化規章制度、機構櫃員資訊採集、切換演練、並行演練、投產預演、災備演練等
- 預備：如版本衝突問題，一般投產後幾天，出現的問題會相對較多，因此要考慮新版本上線的影響、與其他元件的相容情況、與功能間的松耦合
- 其他：如按子系統分佈投產，要考慮系統間的依賴情況，能否做到松耦合，以及對外報批報備及宣傳解釋、系統切換及檔案保管等
這例子只是一部分，還有很多有意思的設計關鍵點就不過多敘述了。當然，除了編碼的藝術、優雅的設計，合適的效能也是非常重要的。俗話說：“沒有對比就看不出差距”。
文章讀到這裡，相信大家緊耦合與松耦合有了一定的瞭解，那到底是用緊耦合好還是松耦合好？之前也有過一些交流，其實這是一個比較難回答的問題，沒有不顧場景和資源下絕對的好與壞，也不是一定要追求松耦合，關鍵要權衡利弊。- 首先，松耦合意味著更多的程式碼開發和維護工作量，那麼系統會付出更加複雜的代價；
- 其次，不同公司、部門或團隊也有不同的進度安排、利益和預算，是需要集中力量一起協作完成的；
- 最後是松耦合的架構增加了系統開銷，從而降低了系統處理效率。
例如，非同步處理的方式比同步處理的方式複雜；再如，元件服務化不徹底導致不清、服務間關係複雜；又如，由於呼叫鏈太長，且故障存在擴散現象，快速定位問題問題。
基於各家行的資訊系統情況與資料量，緊耦合與松耦合的相對優勢是存在的，或者說，各有優勢，看銀行根據自身情況取捨價值判斷。但當資訊系統或資料量發展到一定階段，松耦合是必經之路。無論是以前的SOA還是現在的微服務，主要都是為了化繁為簡。所以在系統設計時需要把松耦合的環節通盤考慮清楚並平衡多方因素，當然還有技術架構、部署架構等場景。每個環節都按照既定的目標去執行，形成統一的語言，才能最終實現真正意義上的松耦合，使系統架構隨著系統的發展而進行適應性的最佳化，始終保持適度的耦合度，起到落實IT和業務戰略目標。至此，松耦合的內容就到這裡。如果能為你帶來些許幫助，那是一件非常欣慰的事情。感謝網路上編寫了松耦合相關文章的作者。限於個人整體認知，有些方面只是概要講述，並未詳細展開。歡迎分享你的觀點，我們一起探討。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31558019/viewspace-2714010/，如需轉載，請註明出處，否則將追究法律責任。
