導言：耦合性，是對模塊間關聯水平的懷抱。耦合的強弱取決於模塊間接口的龐大性、挪用模塊的方式以及通過界面傳送數據的幾多。模塊間的耦合度是指模塊之間的依賴關系，包羅控制關系、挪用關系、數據通報關系。

模塊間聯系越多，其耦合性越強，同時講明其獨立性越差。軟件設計中通常用耦合度和內聚度作為權衡模塊獨立水平的尺度。高內聚低耦合，是軟件工程中的觀點，是判斷設計優劣的尺度，主要是面向工具的設計，主要是看類的內聚性是否高，耦合度是否低。

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文件，告訴靜態頁面可以會見下單功效了。

總結在模塊劃分時，要遵循“一個模塊，一個功效”的原則，盡可能使模塊到達功效內聚。事實上，微服務架構短期來看，並沒有很顯著的利益，甚至短期內會影響系統的開發進度，因為高內聚，低耦合的系統對開發設計人員提出了更高的要求。高內聚，低耦合的利益體現在系統連續生長的歷程中，高內聚，低耦合的系統具有更好的重用性，維護性，擴展性，可以更高效的完成系統的維護開發，連續的支持業務的生長，而不會成為業務生長的障礙。

作者：Java微服務鏈接：https://www.jianshu.com/p/01eabd8a4bee泉源：簡書著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請註明出處。

本文來源：澳門人威尼斯-www.jswzmjx.com