微服務架構：如何用十步解耦你的系統？

導言：

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

首先獻上微服務的技術點思惟導圖：

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面試題整理了1000多道400多頁pdf文檔，文章都會在裏面更新，整理的資料也會放在裏面。

喜歡文章記得關注我點個贊喲，感謝支持！