知識星球（給ImportNew加星標，提高Java技能）
轉自：cyfonly
看到最近“微服務架構”這個概念這麼火，作為一個積極上進的程式猿，成小胖忍不住想要學習學習。而架構師老王（不是隔壁老王）最近剛好在做公司基礎服務的微服務化研究和落地，對此深有研究。
於是成小胖馬上屁顛屁顛的跑過去向老王請教：“王哥，我看微服務架構這麼火，我也想學，您給我講講啥是微服務架構唄？”
老王笑了笑說：“要想知道什麼是微服務架構，你得先知道什麼系統架構設計。”
成小胖的理想是成為一名架構師，平時積累了不少知識，因此對“系統架構設計”這個概念還是很熟悉的，因此他馬上就給出了答案【1】：
系統架構設計描述了在應用系統的內部，如何根據業務、技術、組織、靈活性、可擴充套件性以及可維護性等多種因素，將應用系統劃分成不同的部分，並使這些部分彼此之間相互分工、相互協作，從而為使用者提供某種特定的價值的方式。
老王滿意的點點頭，繼續問：“你看最近我在做微服務的研究和落地，你知道為什麼要做這個事情嗎？”
“因為目前的三層架構存在很多弊端，不滿足業務發展的需求了唄。”
“對的，我看你對公司目前的架構也非常熟悉了，你來仔細說說現在的三層架構吧。”
於是成小胖拿了一張A4紙，圖文並茂地給老王講了他對三層架構的理解：
三層架構是指在業務和技術的發展過程中，系統中不同職責的部分被定義在不同的層次，每一層負責的功能更加具體化。三層架構通常包括表示層、業務邏輯層和資料訪問層，層與層之間互相連線、互相協作，構成一個整體，並且層的內部可以被替換成其他可以工作的部分，但對整體的影響不大。
以 Web 應用程式為例，早期是將所有的表示邏輯、業務邏輯和資料訪問邏輯放在一起，這就是一層架構。
後來隨著 java、.NET 等高階語言的發展，提供了越來越方便的資料訪問機制，如 java 的 JDBC 和 .NET 的 ADO.NET。這時資料訪問部分被分離開來，形成了二層架構。
再後來，隨著面向物件設計、企業架構樣式等理念的不斷發展，表示邏輯和業務邏輯也被分離開來，形成了現在的三層架構。
三層架構的具體內容如下：
- 表示層： 使用者使用應用程式時，看到的、聽見的、輸入的或者互動的部分。
- 業務邏輯層： 根據使用者輸入的資訊，進行邏輯計算或者業務處理的部分。
- 資料訪問層： 關註有效地操作原始資料的部分，如將資料儲存到儲存介質（如資料庫、檔案系統）及從儲存介質中讀取資料等。
老王對這個解釋非常滿意，作了進一步的補充：“你看雖然現在程式被分成了三層，但只是邏輯上的分層，並不是物理上的分層。也就是說，對不同層的程式碼而言，經過編譯、打包和部署後，所有的程式碼最終還是執行在同一個行程中。而這，就是所謂的單塊架構。”
成小胖撓了撓頭：“原來單塊架構是這個意思啊~~”
“嗯。根據你的實際工作經驗，你再總結下單塊架構的優缺點吧。”
平時勤於總結的成小胖很快便列出了單塊架構的優缺點：
優點：
- 易於開發： 開發方式簡單，IDE 支援好，方便執行和除錯。
- 易於測試： 所有功能執行在一個行程中，一旦行程啟動，便可以進行系統測試。
- 易於部署： 只需要將打好的一個軟體包釋出到伺服器即可。
- 易於水平伸縮： 只需要建立一個伺服器節點，配置好執行時環境，再將軟體包釋出到新伺服器節點即可執行程式（當然也需要採取分發策略保證請求能有效地分發到新節點）。
缺點：
- 維護成本大： 當應用程式的功能越來越多、團隊越來越大時，溝通成本、管理成本顯著增加。當出現 bug 時，可能引起 bug 的原因組合越來越多，導致分析、定位和修複的成本增加；並且在對全域性功能缺乏深度理解的情況下，容易在修複 bug 時引入新的 bug。
- 持續交付週期長： 構建和部署時間會隨著功能的增多而增加，任何細微的修改都會觸發部署流水線。
- 新人培養週期長： 新成員瞭解背景、熟悉業務和配置環境的時間越來越長。
- 技術選型成本高： 單塊架構傾向於採用統一的技術平臺或方案來解決所有問題，如果後續想引入新的技術或框架，成本和風險都很大。
- 可擴充套件性差： 隨著功能的增加，垂直擴充套件的成本將會越來越大；而對於水平擴充套件而言，因為所有程式碼都執行在同一個行程，沒辦法做到針對應用程式的部分功能做獨立的擴充套件。
老王拍了拍成小胖的肩膀，眼睛眯成了一條縫：“小夥子總結的很不錯！既然你已經對目前的單塊架構的優缺點有了很好的理解，那現在咱們就可以開始來學習微服務架構了。”
老王先從網上搜索“微服務架構”關鍵字，出來這麼一段話：
微服務架構是一種架構樣式，它提倡將單一應用程式劃分成一組小的服務，服務之間互相協調、互相配合，為使用者提供最終價值。每個服務執行在其獨立的行程中，服務於服務間採用輕量級的通訊機制互相溝通（通常是基於 HTTP 的 RESTful API）。每個服務都圍繞著具體業務進行構建，並且能夠被獨立地部署到生產環境、類生產環境等。另外，應儘量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務背景關係，選擇合適的語言、工具對其進行構建。
成小胖看完了這段話，說：“看著有點暈，雲裡霧裡的感覺……”
老王嘿嘿一笑：“莫慌，現在就給你詳細講講微服務架構的特性。”
1. 單一職責
微服務架構中的每個服務，都是具有業務邏輯的，符合高內聚、低耦合原則以及單一職責原則的單元，不同的服務透過“管道”的方式靈活組合，從而構建出龐大的系統。
2. 輕量級通訊
服務之間透過輕量級的通訊機制實現互通互聯，而所謂的輕量級，通常指語言無關、平臺無關的互動方式。
對於輕量級通訊的格式而言，我們熟悉的 XML 和 JSON，它們是語言無關、平臺無關的；對於通訊的協議而言，通常基於 HTTP，能讓服務間的通訊變得標準化、無狀態化。目前大家熟悉的 REST（Representational State Transfer）是實現服務間互相協作的輕量級通訊機制之一。使用輕量級通訊機制，可以讓團隊選擇更適合的語言、工具或者平臺來開發服務本身。
3. 獨立性
每個服務在應用交付過程中，獨立地開發、測試和部署。
在單塊架構中所有功能都在同一個程式碼庫，功能的開發不具有獨立性；當不同小組完成多個功能後，需要經過整合和回歸測試，測試過程也不具有獨立性；當測試完成後，應用被構建成一個包，如果某個功能存在 bug，將導致整個部署失敗或者回滾。
在微服務架構中，每個服務都是獨立的業務單元，與其他服務高度解耦，只需要改變當前服務本身，就可以完成獨立的開發、測試和部署。
4. 行程隔離
單塊架構中，整個系統執行在同一個行程中，當應用進行部署時，必須停掉當前正在執行的應用，部署完成後再重啟行程，無法做到獨立部署。
有時候我們會將重覆的程式碼抽取出來封裝成元件，在單塊架構中，元件通常的形態叫做共享庫（如 jar 包或者 DLL），但是當程式執行時，所有元件最終也會被載入到同一行程中執行。
在微服務架構中，應用程式由多個服務組成，每個服務都是高度自治的獨立業務物體，可以執行在獨立的行程中，不同的服務能非常容易地部署到不同的主機上。
理論上所有服務可以部署在同一個伺服器節點，但是並不推薦這麼做，因為微服務架構的主旨就是高度自治和高度隔離。
“王哥你真厲害，您這麼一說我的思維清晰了很多！”成小胖激動的幾乎要叫起來。
“我之前瞭解過 SOA，好像跟微服務架構的思想很像啊，您能幫我區分一下嗎？”成小胖追問到。
老王嘿嘿一笑，拿起成小胖手上的A4紙，翻到另外一面畫了個表格：
成小胖看了之後說：“您這麼一畫我倒是大概明白了，但是 DevOps 這個概念我不懂誒……”
“這個 DevOps 就說來話長了，有時間你自己先去查查資料瞭解下吧。”
“好的。現在我對微服務架構的概念有了瞭解，您能再深入剖析下它的本質嗎？”
“好，你可仔細聽好了哈！”
1. 服務作為元件
微服務也可以被認為是一種元件，但是跟傳統元件的區別在於它可以獨立部署，因此它的一個顯著的優勢。另外一個優點是，它在元件與元件之間定義了清晰的、語言無關、平臺無關的規範介面，耦合度低，靈活性非常高。但它的不足之處是，分散式呼叫嚴重依賴於網路的可靠性和穩定性。
2. 圍繞業務組織團隊
在單塊架構中，企業一般會根據技能劃分團隊，在這種組織架構下，即便是簡單的需求變更都有可能需要跨團隊協作，溝通成本很高。而在微服務架構中，它提倡以業務為核心，按照業務能力來組織團隊，團隊中的成員具有多樣性的技能。
3. 關註產品而非專案
在單塊架構中，應用基本上是基於“專案樣式”構建的，即專案啟動時從不同技能資源池中抽取相關資源組成團隊，專案結束後釋放所有資源。這種情況下團隊成員缺乏主人翁意識和產品成就感。
在微服務架構中，提倡採用“產品樣式”構建，即更傾向於讓團隊負責整個服務的生命週期，以便提供更優質的服務。
4. 技術多樣性
微服務架構中，提倡針對不同的業務特徵選擇合適的技術方案，有針對性的解決具體業務問題，而不是像單塊架構中採用統一的平臺或技術來解決所有問題。
5. 業務資料獨立
隨著業務的發展，可以方便地選擇更合的工具管理或者遷移業務資料。
6. 基礎設施自動化
微服務架構提供自主管理其相關的業務資料，這樣可以隨著業務的發展提供資料介面整合，而不是以資料庫的方式同其他服務整合。另外，在微服務架構的實踐過程中，對持續交付和部署流水線的要求很高，將促進企業不斷尋找更高效的方式完成基礎設施的自動化及 DevOps 運維能力的提升。
聽完成小胖忍不住表達了敬佩之意：“老司機就是老司機，噢說錯了……架構師就是架構師，總結得這麼簡潔又深刻！”
“咳咳，低調低調……”
“聽您講解了這麼多，我覺得微服務架構解決了很多當前三層架構的痛點。不過我覺得沒有任何一項技術或架構是完美的。”
“非常正確。進行微服務架構的落地是存在很多挑戰的。”
1. 分散式系統的複雜性
微服務架構是基於分散式的系統，而構建分散式系統必然會帶來額外的開銷。
- 效能： 分散式系統是跨行程、跨網路的呼叫，受網路延遲和頻寬的影響。
- 可靠性： 由於高度依賴於網路狀況，任何一次的遠端呼叫都有可能失敗，隨著服務的增多還會出現更多的潛在故障點。因此，如何提高系統的可靠性、降低因網路引起的故障率，是系統構建的一大挑戰。
- 非同步： 非同步通訊大大增加了功能實現的複雜度，並且伴隨著定位難、除錯難等問題。
- 資料一致性： 要保證分散式系統的資料強一致性，成本是非常高的，需要在 C（一致性）A（可用性）P（分割槽容錯性） 三者之間做出權衡。
2. 運維成本
運維主要包括配置、部署、監控與告警和日誌收集四大方面。微服務架構中，每個服務都需要獨立地配置、部署、監控和收集日誌，成本呈指數級增長。
3. 自動化部署
在微服務架構中，每個服務都獨立部署，交付週期短且頻率高，人工部署已經無法適應業務的快速變化。因此如何有效地構建自動化部署體系，是微服務面臨的另一個挑戰。
4. DevOps 與組織架構
在微服務架構的實施過程中，開發人員和運維人員的角色發生了變化，開發者將承擔起整個服務的生命週期的責任，包括部署和監控；而運維則更傾向於顧問式的角色，儘早考慮服務如何部署。因此，按需調整組織架構、構建全功能的團隊，也是一個不小的挑戰。
5. 服務間的依賴測試
單塊架構中，通常使用整合測試來驗證依賴是否正常。而在微服務架構中，服務數量眾多，每個服務都是獨立的業務單元，服務主要透過介面進行互動，如何保證依賴的正常，是測試面臨的主要挑戰。
6. 服務間的依賴管理
微服務架構中，服務數量眾多，如何清晰有效地展示服務間的依賴關係也是個不小的挑戰。
“微服務的落地需要經過全面的考察和完善的試驗，並不是每個場景都適合使用微服務架構，也不是每個企業都有能力或者精力去面對這些挑戰。”老王最後語重心長的說。
“嗯嗯，每件事都有兩面性，最合適的才是最好的！對了王哥，您已經給我上完理論課了，啥時候帶我實踐下唄？”
“你先好好消化完今天講的這些，下次再說吧……”
“好吧，很期待我們的下一次交流……”
