《企業級容器云架構開發指南》—2 微　服　務

第2章

微　服　務

我們所負責的系統是否適合進行微服務化改造？如果適合我們應該如何著手將現有系統一步步微服務化？在本章我們將圍繞微服務的概念、特點、設計模式，以及如何將一個單體拆分為微服務這幾個主要的關鍵點，來了解一下什么是微服務。

2.1　為何要做微服務

2.1.1　架構設計新理念：做好隔離

無論是微服務還是單體服務，都是一種項目的架構方式，項目架構首先要確認架構原則是什么，以及目標是什么，答案很簡單，架構原則需要根據公司的目標來制定，也就是說架構原則應該與公司的發展愿景和使命相符。架構目標就是盈利，盈利的方法有很多，通過降低成本換取利益最大化是盈利的一個主要途徑。而如何能實現降本增效的目的呢？其實無論是單體服務還是微服務，都可以從可用性、可擴展性、質量、成本、效率、響應時間這幾個維度入手。微服務也是把單體解構之后，變成一個個構建小、發布快的小服務，從而提高可用性，增強可擴展性，最終完成降本增效的目的。

在這里，我們列出15個最常用的架構原則，這些原則并不是在所有的設計中都必須涉及，而是供客戶剪裁，由客戶根據項目的特性增加或者刪除某項或某幾項原則。我們概括地討論這些原則，并著重考慮其與微服務架構設計的相關性。

1）N+1設計：確保系統發生故障時，至少有一個冗余的實例。

2）回滾設計：確保系統可以回滾到以前發布過的任何版本。

3）禁用設計：確保一些具有高風險的系統功能能夠通過開關來禁用，這能為修復贏得時間。

4）監控設計：在設計階段就必須考慮監控，而不是在實施完成之后。監控做得好，將為系統的可擴展性預留空間。

5）設計多活的數據中心：確保系統可在地理上隔離災難和危機。

6）使用成熟的技術：只用確實好用的技術。

7）異步設計：只有在確實有必要的情況下才使用同步設計，以增加系統的可擴展性。

8）無狀態系統：只有在確實有必要的情況下才使用狀態，狀態耗費資金，降低處理能力、可用性和可擴展性。

9）水平擴展而非垂直升級：永遠不要依賴更大、更快的系統。

10）設計至少要有兩個步驟的前瞻性：在擴展性問題上提前考慮好下一步的行動計劃。

11）非核心的購買：如果不是最擅長的，也提供不了差異化的具有競爭優勢的功能，則直接購買。

12）使用大規模量產的商品化硬件：只有在確實有必要的情況下才定制硬件。

13）小構建、小發布、快試錯：不斷迭代，讓系統不斷地成長。

14）自動化：設計和構建自動化的過程，如果機器可以做，就不要依賴人。

15）隔離故障：實現故障隔離設計，通過斷路保護避免故障傳播和交叉影響。

以上就是我們常用的一些架構原則，我們也可以用圖2-1這樣的形式直觀地了解微服務的架構原則。在技術高速發展的今天，架構設計理念也在發生著變化。例如，平均修復時間和平均故障間隔時間是做系統時必然會面對的兩個指標，那么這兩個指標哪個更重要一點？其實這個問題沒有標準答案，歷史經驗更多是關注平均故障間隔時間，選用很健壯的數據庫，選擇高可用的中間鍵，購買小機，提高高可用性，增加系統的安全設置，目的都是盡量少出錯、不出錯，讓錯誤在更早的時候及時得到處理，這一切都是為了提升平均故障間隔時間。但到了現階段，當我們購買的X86越來越多，甚至系統所占的機房和數據中心不再是一個的時候，我們的理念也隨之發生了變化：我們認為出錯是必然的。有運維經驗的人都知道，如果有上百臺的X86，那么出錯是必然的，很難像原來的小機時代，能夠實現盡量不出錯。

既然出錯是必然的，那么我們就需要在設計初期考慮如何能將出錯造成的影響降到最小，這時做好隔離就尤為重要了。無論是從虛擬機、容器層面，還是到現在從數據和應用兩個層面切分做微服務，所有的這一切都是為了實現隔離，讓一個點出錯產生的影響最小，并更快恢復，最大限度地降低出錯對業務的影響，這也是目前我們在架構設計理念的顯著變化。

圖2-1　微服務架構原則

微服務是實現隔離的重要手段，但故障隔離不是免費的，也未必是便宜的。那么何種情況下需要優先考慮通過微服務實現隔離呢？答案取決于該系統的特定需求、增長率、不可用率和客戶期望等一系列因素。如果微服務故障隔離做好了，后面會得到很好的回饋。

在這里，我們提供一些簡單的原則來幫助大家制定故障隔離方案。

1）泳道與盈利原則：一定要確保與盈利關系最密切的事情和可能失敗及有需求限制的其他系統適當地隔離，并創建泳道。例如，如果是一個商務系統，影響業務最關鍵的就是訂單和收費這兩個與錢關系最緊密的模塊，我們需要考慮將其從硬件、中間應用層和最上層的網絡層都實現隔離。

2）隔離頻繁出錯組件：如果有的模塊特別容易出錯，那么這個模塊也具備率先考慮通過微服務實現隔離的特質。

3）泳道與天然隔離：客戶邊界是最好的泳道隔離鎖，這種分割沿著客戶的邊界實施。分割通常先在存儲或數據庫層完成，再創建一條從請求到數據庫并從數據庫返回客戶的完整泳道。

隔離會耗費成本和資源，共享將獲得成本效益，所以我們需要權衡隔離。在大多數情況下，單一泳道可運行多個應用。但如果某個服務特別忙，那么可以給它分配一個專用泳道；如果大部分服務利用率都很低，那么可以把它們都分配到一個泳道。

如何進行故障隔離，有幾條重要的原則。

1）原則1：絕不共享或者盡量減少共享。包括共享網絡、共享硬件、共享URL、共享數據庫等一切資源，泳道共享越少，其故障隔離度就越高。

2）原則2：不跨越泳道。同步通信從不跨越泳道，如果跨越了泳道，那么邊界劃分就會不正確。

3）原則3：交易發生在泳道。不能建立多服務泳道，那些服務通信將違反原則2。如果我們在白板上畫一個從用戶指向最后一個功能組件的箭頭，該箭頭不應該跨越泳道。

我們都了解傳統行業中的城市規劃師要規劃城市整體架構，要充分考慮水、電各種區塊；而建筑師要負責建筑圖紙的設計，最終將圖紙上的建筑落地實現。那么，如果將軟件架構師與建筑師、城市規劃師類比，哪個角色與軟件架構師更相符呢？有的人認為是城市規劃師，也有人認為是建筑師，當然也有人認為軟件規劃師兼具兩者的特點，因為做系統要考慮很多因素，要考慮整個資源的共享。

現在的系統更像高度復雜的城市，而不是單獨的房屋，所以軟件架構師更像城市規劃師，他的職責是對城市進行規劃，確定每個區域應該做的事情，這些區域應當達到統一的規范要求，又要具備隨時擴張或縮減的靈活性。同時，他還應當保證這種劃分適合專業人員在對應區域工作。明白了這一點，就可以明白版本管理、持續集成、自動化測試、自動化發布、服務治理、詳盡監控等“磨刀工夫”的價值，沒有這些工作，就談不上微服務的質量和保障級別，也就無法駕馭微服務的體系。

由此，也很容易明白軟件架構師在這個時代所要面對的挑戰。一方面，軟件架構師沒有現成的足夠強大的集成工具，只能靠一堆“稀松平常”的工具組裝出整體可靠的系統；另一方面，要深入理解業務，把業務拆散成邊界清晰的概念，以“高內聚低耦合”的服務分而治之，還必須考慮實現的限制——“高內聚低耦合”的原則人人都知道，如果沒有可靠的分布式事務管理機制，就不得不把并非“高內聚”的模塊聚合起來，但又要擔心業務邊界模糊的風險。RESTful固然優雅，但有時候又不得不使用RPC通信，所以又要提防RPC帶來的強綁定，客戶端、服務器端同步更新等很多問題。

這一切設計、權衡、決策并沒有成型的理論和學說可以依靠，通常只能完全依賴軟件架構師的經驗、理解、思考。所以困難很大，風險也很大，如果做得好，收益也是非凡的。而這恰恰是軟件架構師的價值所在。

OpenStack 云計算

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。