摘要：導言耦合性，是對模塊間關聯程度的度量。模塊間的耦合度是指模塊之間的依賴關系，包括控制關系調用關系數據傳遞關系。

導言：

耦合性，是對模塊間關聯程度的度量。耦合的強弱取決于模塊間接口的復雜性、調用模塊的方式以及通過界面傳送數據的多少。模塊間的耦合度是指模塊之間的依賴關系，包括控制關系、調用關系、數據傳遞關系。模塊間聯系越多，其耦合性越強，同時表明其獨立性越差。軟件設計中通常用耦合度和內聚度作為衡量模塊獨立程度的標準。高內聚低耦合，是軟件工程中的概念，是判斷設計好壞的標準，主要是面向對象的設計，主要是看類的內聚性是否高，耦合度是否低。

SpringCloud和Dubbo都是現在比較成熟的微服務框架，如何使用兩者構建搭建你的微服務系統呢？他們是如何將你的系統解耦的？又是怎么解耦的呢？請聽我慢慢道來：

將現有耦合在一起的模塊進行重新的設計，設計成可以獨立部署的多個模塊，使用微服務框架很容易做到，成熟的示例代碼都特別多，這里不再多講。下面是我的微服務實現的一個架構設計圖。

架構設計原則之一就是反向依賴，只從上往下依賴，所以，我們將公共的重復功能的模塊抽取出來。必須強調一點的是，公共模塊必須足夠的功能單一，不能有其他業務的邏輯判斷在里面。在整個模塊依賴關系里，應該是一棵樹狀結構的關系圖，而不是一個網狀的關系圖。

1）做好代碼控制

筆者之前就碰到過這種問題，模塊劃分完了，當需求變更的時候，研發人員根本不管是不是公共模塊，只要能快速完成任務，哪里改的快就在哪里改。因此，這個需要內部要做好代碼的權限管理，不應該開放所有的提交代碼的權限給所有的人。后來我就將公共模塊的合并代碼的權限收回了，合并代碼需要先提交申請，代碼review過才能合并代碼。這就保證了公共模塊代碼的功能單一。

2）做好版本管理

公共模塊被多個模塊模塊使用，任何代碼的修改都可能會導致到正在使用的模塊無法使用。這個就需要做好各個模塊的版本管理，我是使用maven進行版本管理的，定義一個總的父pom項目來進行各個模塊的版本管理，任何被其他模塊使用的開發包都要在父pom里進行版本管理。當新的需求來了以后，需要對公共模塊進行修改時，要更新模塊的版本號，同時更新父pom的版本號，需要使用公共模塊新功能的模塊就修改父pom的版本號，不需要使用公共模塊新功能的模塊就不用修改父pom的版本號，這樣公共模塊的新老版本都能使用，即使出現問題，也只會影響到使用新版本的模塊。

現在的代碼迭代速度快，同時會面對多個需求，有的需求緊急，有的需求不緊急，而且緊急程度可能隨時會調整，如果將所有的需求都放在一個分支，當只想上線其中幾個需求的時候發現無法將不上線需求的代碼拆分出來，是不是很尷尬，即使能拆分出來，代碼修改過以后又要重新進行部署測試，很費時費力，所以要針對不同的需求重新建立研發分支，這樣就將不同需求的分支解耦，保證想上哪個就上哪個，需要上多個需求的就將分支合并上線。

為每個模塊每個環境配置一個配置文件，這樣就可以把不同的環境的配置解耦，不用每次上線都更新一次。但是如果需要修改數據庫配置，還是需要重新部署重啟應用才能解決。使用微服務的配置中心就能解決這個問題了，比如使用ZooKeeper作為SpringCloud的配置中心，修改ZooKeeper中的節點數據就可以實時更新配置并生效。

當采用微服務架構把原來的系統拆分成多個系統以后，你會發現原來簡單的問題，現在變的復雜了，比如功能的權限控制，原來是跟業務代碼放到一起，現在如果每個業務模塊都有功能權限的代碼，將是一件非常麻煩的事情。那么解決辦法就是將權限功能遷移出來，恰巧使用SpringCloudGateway就能完成這件事情，SpringCloudGateway能夠進行負載均衡，各種路由攔截，只要將原來的權限控制代碼遷移到Gateway里實現以下就可以了，權限配置管理界面和代碼邏輯都不用變。如果是API接口呢，就需要將安全驗證等功能放在Gateway里實現就好了。

當你的系統訪問量越來越大的時候，你會發現每次升級都是一件非常麻煩的事情，領導會跟你說這個功能忙時不能停機影響用戶使用呀，只能半夜升級呀，多么痛快的事情啊。有的時候運營人員也會發現，怎么我的后臺訪問怎么這么慢？問題出在哪里呢？問題就出在，所有的模塊都用了一個Gateway，多端同時使用了相同的流量入口，當在舉行大促時，并發量非常高，帶寬占用非常大，那么其他的功能也會跟著慢下來。

不能在舉行大促時發券時，我線下支付一直支付不了，這是非常嚴重的事故了，客服電話會被打爆了。所以，必須要對流量進行拆分，各個端的流量不能相互影響，比如APP端、微信端、運營后臺和商戶后臺等都要分配獨立的Gateway，并接入獨立的帶寬，對于流量大的端可以使用彈性帶寬，對于運營后臺和商戶后臺就比較小的固定的帶寬即可。這樣就大大降低了升級時的難度，是不是再上線時就沒那么緊張了？

系統剛上線的時候，數據量不大，所有的模塊感覺都挺好的，當時間一長，系統訪問量非常大的時候會發現功能怎么都變慢了，怎么mysql的cpu經常100%。那么恭喜你，你中招了，你的數據需要解耦了。

首先要模塊間數據解耦，將不同模塊使用獨立的數據庫，保證各模塊之間的數據不相互影響。

其次就是冷熱數據解耦，同一個模塊運行時間長了以后也會積累大量的數據，為了保證系統的性能的穩定，要減少因為數據量太大造成的性能降低，需要對歷史數據進行定期的遷移，對于完整數據分析匯總就在其他的庫中實現。

一個好的架構設計是要有好的橫向擴展的能力，在不需要修改代碼只通過增加硬件的方式就能提高系統的性能。SpringCloud和Dubbo的注冊中心天生就能夠實現動態添加模塊的節點，其他模塊調用能夠實時發現并請求到新的模塊節點上。

互聯網開發在于能夠快速的試錯，當一個新的版本上線時，經常是需要先讓一部分用戶進行測試一下，這就是傳說中的灰度發布，同一個模塊先部署升級幾臺服務器到新版本，重啟完成后流量進來以后，就可以驗證當前部署的這幾臺服務器有沒有問題，就繼續部署其他的節點，如果有問題馬上回滾到上一個版本。使用SpringCloudGateway的WeighRouterFilter就能實現這個功能。

當同一個模塊的瞬間有非常高并發的時候，對，就是說的秒殺，純粹的流量解耦還是不夠，因為不能讓前面的流量沖擊后面真正的下單的功能，這個時候就需要更細的流量解耦，要將靜態文件的訪問通通拋給CDN來解決，動態和靜態之間是通過定時器來出發的，時間未到之前一直刷新的是靜態的文件，當時間到了之后，生成新的js文件，告訴靜態頁面可以訪問下單功能了。

在模塊劃分時，要遵循“一個模塊，一個功能”的原則，盡可能使模塊達到功能內聚。

事實上，微服務架構短期來看，并沒有很明顯的好處，甚至短期內會影響系統的開發進度，因為高內聚，低耦合的系統對開發設計人員提出了更高的要求。高內聚，低耦合的好處體現在系統持續發展的過程中，高內聚，低耦合的系統具有更好的重用性，維護性，擴展性，可以更高效的完成系統的維護開發，持續的支持業務的發展，而不會成為業務發展的障礙。

———— / END / ————