軟件體系架構閱讀筆記十二

在使用了微服務架構之後，總體的業務流程被拆分紅小的微服務，並組合在一塊兒對外提供服務，微服務之間使用輕量級的網絡協議通訊，一般是RESTful風格的遠程調用。因爲服務與服務的調用再也不是進程內的調用，而是經過網絡進行的遠程調用，衆所周知，網絡通訊是不穩定、不可靠的，一個服務依賴的服務可能出錯、超時或者宕機，若是沒有及時發現和隔離問題，或者在設計中沒有考慮如何應對這樣的問題，那麼極可能在短期內服務的線程池中的線程被用滿、資源耗盡，致使出現雪崩效應。本節針對微服務架構中可能遇到的這些問題，講解應該採起哪些措施和方案來解決。

1. 艙壁隔離模式

這裏用航船的設計比喻艙壁隔離模式，若一艘航船遇到了意外事故，其中一個船艙進了水，則咱們但願這個船艙和其餘船艙是隔離的，但願其餘船艙能夠不進水，不受影響。在微服務架構中，這主要體如今以下兩個方面。

1）微服務容器分組

筆者所在的支付平臺應用了微服務，將微服務的每一個節點的服務池分爲三組：準生產環境、灰度環境和生產環境。準生產環境供內側使用；灰度環境會跑一些普通商戶的流量；大部分生產流量和VIP商戶的流量則跑在生產環境中。這樣，在一次比較大的重構過程當中，咱們就能夠充分利用灰度環境的隔離性進行預驗證，用普通商戶的流量驗證重構沒有問題後，再上生產環境。

另一個案例是一些社交平臺將名人的自媒體流量所有路由到服務的核心池子中，而將普通用戶的流量路由到另一個服務池子中，有效隔離了普通用戶和重要用戶的負載。

其服務分組以下圖所示。

 

 

2）線程池隔離

在微服務架構實施的過程當中，咱們不必定將每一個服務拆分到微小的力度，這取決於職能團隊和財務的情況，咱們通常會將同一類功能劃分在一個微服務中，儘可能避免微服務過細而致使成本增長，適可而止。

這樣就會致使多個功能混合部署在一個微服務實例中，這些微服務的不一樣功能一般使用同一個線程池，致使一個功能流量增長時耗盡線程池的線程，而阻塞其餘功能的服務。

線程池隔離以下圖所示。

 

2. 熔斷模式

能夠用家裏的電路保險開關來比喻熔斷模式，若是家裏的用電量過大，則電路保險開關就會自動跳閘，這時須要人工找到用電量過大的電器來解決問題，而後打開電路保險開關。在這個過程當中，電路保險開關起到保護整個家庭電路系統的做用。

對於微服務系統也同樣，當服務的輸入負載迅速增長時，若是沒有有效的措施對負載進行熔斷，則會使服務迅速被壓垮，服務被壓垮會致使依賴的服務都被壓垮，出現雪崩效應，所以，可經過模擬家庭的電路保險開關，在微服務架構中實現熔斷模式。

微服務化的熔斷模式的狀態流轉以下圖所示。

 轉載博客：https://blog.csdn.net/kwame211/article/details/78015601