《提高能力，漲薪可待》-如何設計一個符合本身公司的微服務架構

時間 2019-11-24

標籤提高能力，漲薪可待如何設計一個符合本身公司微服架構欄目系統架構简体版

原文原文鏈接

歡迎關注掘金：【Ccww】，一塊兒學習
提高能力，漲薪可待
面試知識，工做可待
實戰演練，拒絕996
也歡迎關注微信公衆號【Ccww筆記】，原創技術文章第一時間推出
若是此文對你有幫助、喜歡的話，那就點個讚唄！面試

前言

是否是感受在工做上難於晉升了呢？
是否是感受找工做面試是那麼難呢？
是否是感受本身天天都在996加班呢？redis

在工做上必須保持學習的能力，這樣才能在工做獲得更好的晉升，漲薪指日可待，歡迎一塊兒學習【提高能力，漲薪可待】系列spring

redis
- 《提高能力，漲薪可待》-簡明的圖解Redis RDB持久化、AOF持久化
- 《提高能力，漲薪可待》-Redis經常使用的五種數據類型底層結構
Java併發
- 《提高能力，漲薪可待》-Java併發之AQS全面詳解
mongodb、spring boot、Spring security...

在找工做面試應在學習的基礎進行總結面試知識點，工做也指日可待，歡迎一塊兒學習【面試知識，工做可待】系列mongodb

最後，理論知識到準備充足，是否是該躬行起來呢？歡迎一塊兒學習【實戰演練，拒絕996】系列數據庫

1.複雜性系統拆分微服務帶來問題

使用微服務架構能夠爲咱們帶了好處、便利的同時，但也帶了不少挑戰，新的問題。好比，微服務之間的調用和調用和通訊會不會很複雜？通信模式，一對一仍是一對多的？依賴的服務沒有準備好，如何驗證個人開發功能？數據一致性的問題等等。總結起來：後端

微服務的粗細粒度難於掌握
分佈式的微服務增長了服務之間互相調用以及通訊的複雜性
數據一致性問題
測試複雜度提高，微服務集成關聯
運維複雜度陡增，部署數量多、監控進程致使總體運維複雜度提高
依賴服務變動難於跟蹤

爲了解決這些問題，咱們在設計微服務架構時，必須進行全盤考慮，權衡利弊，這樣才能作出合理的抉擇，達到最佳的效果，從而達到咱們複雜系統微服務拆分的最終目的。接下來咱們來討論討論設計思想。緩存

2. 微服務劃分方法

微服務架構設計首要任務根據給定的因素粗粒度將業務功能合理的劃分微服務。每一個公司每一個複雜系統業務劃分區域都不一樣，但均可以基於這兩種方式建立微服務：安全

按照業務功能不一樣水平劃分-Rest API微服務：
- 負責業務功能行爲設計
- 數據管理
- 基於Rest協議對外提供接口
基於Rest API微服務先後端分離垂直劃分-Web UI微服務：
- 專一於交互頁面的設計
- 基於Rest API微服務存取數據

基於分佈式的高性能、高併發的設計，結合Rest API微服務和Web UI微服務能夠構建一個適應任何規模訪問的多維的穩定牢固，且擴展性良好的系統平臺。性能優化

3. 微服務治理與統籌

在微服務設計中，微服務治理能力是相當重要的，甚至一個微服務系統好壞，取決微服務治理能力。可使用治理組件和服務來管理統籌龐大分佈式系統，確保系統處於有序不亂、穩定而高效。服務器

這裏只提供Spring Cloud基礎組件（選擇治理組件應該基於公司的狀況而定），包括：

Eureka（微服務註冊與發現）：提供服務註冊和發現的功能。
Ribbon（負載均衡）：提供負載均衡調度管理的功能。
Zuul（微服務網關）：提供網關服務和動態路由的功能。
Hystrix（微服務熔斷）：提供容錯機制、服務降級、故障轉移等功能。
Config(統一配置)：提供統一的配置管理服務功能。
Sleuth（微服務跟蹤）：可用來監控集羣中服務運行狀況。

這些組件是如何進行微服務治理的呢？主要過程以下圖：

4. 水平方向-Rest API微服務設計

Rest API微服務實現功能：

負責業務功能行爲設計
數據管理
基於Rest協議對外提供接口

Rest API微服務主要是關於涉及數據庫，其中，數據管理基於數據庫實現數據持久化。接口開發根據Restful規範使用GET、POST、PUT、DELETE對數據進行CRUD操做。

但最重要的如何設計Rest API微服務，其性能將對整個系統的性能相當重要，起決定性做用。這邊提供一下方案：

使用數據庫集羣和分組提供數據庫訪問性能：
- 基於分佈式架構集羣，經過主從同步方式擴展數據庫訪問性能，多個只讀從機緩解主機讀寫壓力
- 基於集羣分組，一般狀況下，只有一個分組正常服務，其餘做備份角色。
數據庫中間件實現讀寫分離
使用數據緩存也是能夠提搞數據存取性能，可以使用Redis等高性能的NoSQL數據庫。但爲了提供緩存的命中率，需遵照：
- 不要在緩存中存取大容量的數據
- 合理設置每一個緩存數據的有效時間，不將緩存數據作持久化。
保持Rest API微服務的獨立性，禁止在Rest API微服務中之間進行互相調用。

5. 垂直方向-Web UI微服務設計

基於Rest API微服務先後端分離的垂直劃分-Web UI微服務包括兩個功能：

專一於交互頁面的設計
基於Rest API微服務存取數據

在設計Web UI微服務主要考慮是高併發的問題，能夠經過如下方法來實現高併發：

在Rest API微服務，使用FeignClient實現負載均衡調用。FeignClient自動實現了Zuul動態路由和Ribbon負載均衡服務
使用Hystrix組件實現斷路器的設計，提供對服務訪問容錯設計和降級使用機制。
使用非阻塞的異步調用實現高併發
使用分佈式文件系統，將圖片、視頻等資料獨立一個分佈式文件系統管理。好比，FastDFS。

6. 微服務之間調用規則

爲了保證各個微服務的獨立性，並減小通訊的複雜性，提升微服務之間的調用效率，咱們對微服務之間的調用，遵循以下規定：

服務之間主要有Web UI微服務對Rest API微服務調用，一個Web UI微服務能夠併發調多個Rest API。
爲了保證Rest API的高性能特性，同時避免Rest API變動影響，禁止Rest API之間互相調用，Rest API之間只能經過MQ進行互相通訊。
Web UI之間可以使用與之對應的實例進行相互跳轉，還能夠進行負載均衡管理。

7. 數據最終一致性設計

對於微服務的多服務架構數據需確保數據一致性，能夠基於CAP原理的BASE理論來合理設計。具體實現操做：

經過調用各個Rest API實現實時同步操做
使用消息通道以事件響應的方式進行異步處理。

CAP(Consistency,Availability,Partition tolerance)即一致性、可用性、分區容錯性三者不可兼得
BASE(Basically Avaiable,Soft state,Eventually consistent)即基本可用、軟狀態、最終一致性。BASE是對CAP中一致性和可用性進行權衡的結果