微服務為何如此炙手可熱
前言
編程是一個還很年輕的行業，計算機從出現到現在也不過 70 年左右，因此我們總是在現存的行業中不斷尋找，探索，嘗試。從最初的單體架構到之后的分布式架構在到現在的微服務架構，說明我們的確也在尋找更好的方法來構建我們的應用，從而提高客戶滿意度和開發效率。微服務不是被發明出來的，而是隨著區域領域設計，持續交付，按需虛擬化，小團隊自治協作，大型集群系統的流行等現實中總結出來的一種趨勢或模式。
2014年馬丁·福勒(Martin Fowler)發表了以“微服務”為主題的文章后，短短數年，“微服務”已經變的炙手可熱，成為大家所熟知的技術名詞，受到無數人的追捧。仿佛設計架構不是“微服務”風格的話，就在技術上有不足似的。
面對快速發展變化的IT行業，各種和微服務相關的技術和框架不斷涌現，架構師和開發人員需要具備透過這些表象看清事物本源的能力。微服務架構不僅涉及架構和開發階段，還包含了測試、部署及運維等，它是一個完整的生命周期。隨著各種技術、框架和工具的豐富和完善，尤其是Service Mesh之類的技術的演進，Service Mesh的目標是要將微服務治理體系下沉為與業務無關的基礎設施。也就是說，在未來大家開發過程中可能不會意識到微服務的存在。但作為有追求的開發人員和架構師，很有必要了解微服務的方方面面。
什么是微服務
在單體應用中，開發者會在類、模塊、類庫的層面來設計功能屬性。為了解決各種各樣的復雜問題，軟件開發者一直致力于努力提供各種有效而及時的解決方案。然而面對日漸壯大的應用，即便團隊成員受過專業的訓練，可能也只是掙扎著盡量維持之前的節奏。糟糕的情況是，曾經簡潔，穩定的產品變得越來越難以維護和脆弱。無法按時發布新的版本或補丁，無法再為客戶持續交付更多價值。微服務解決了這類問題，它為我們提供了一種更好的持續交付業務影響的方式。在微服務應用中，開發者的目標變成了可獨立部署的功能單元，圍繞這些功能單元設計功能屬性。
微服務是一系列自治服務的集合，每個服務只負責完成一塊功能，這些服務共同合作完成更加復雜的業務。
微服務核心原則
支撐微服務開發的五大架構原則為：自治性、可恢復性、透明性、自動化和一致性。工程師在開發和運行時應該結合這些原則做出合理的技術和決策。進而使系統更易于修改、擴展和穩定。
- 自治性你是否能夠修改一個服務并對其進行部署，而不影響其它任何服務。 —黃金法則我們已經明確每個服務的操作和修改都是獨立于其他服務的。為了保證自治性開發者需要把服務設計的松耦合和可獨立部署。松耦合是指每個服務通過明確定義的接口或者事件消息來與其他服務進行交互。可獨立部署是說不同的服務通常有多個不同的團隊并行開發，不要強迫所有的團隊按照同樣的設計步驟進行部署。理想情況下，大家想要的是服務夠快、頻繁改動發布。
- 可恢復性微服務與生俱來具備故障隔離機制：獨立部署運行的微服務在應用或基礎設施出現故障后，故障只會影響到整個系統的一部分功能。盡管這樣，微服務還是會存在多點故障的問題。比如，在異步交互及熔斷器和超時等。
- 透明性不管在什么時候，系統都應該是透明的，可觀測的，這樣當故障發生時不但能及時的發現問題，更可能會盡快的診斷解決問題。
- 自動化通過開發大量的服務來緩解應用不斷變大所帶來的的痛苦，這貌似有悖常理。相對于單體應用，微服務確實是一種更加復雜的架構。開發者需要使用自動化來保證部署和運維過程中的正確性。微服務架目前流行的兩種趨勢，一種是DevOps 基礎設施即代碼，另一種是通過API進行編程的基礎設施環境(AWS、Azure)。
- 一致性開發者應該圍繞業務概念來組織服務和團隊，只有這樣服務和團隊的內聚性才能更高。微服務架構應該偏向于縱向拆分。每個服務應該與一個獨立的業務功能匹配，并將相關的技術層內容封裝在一起。
微服務優勢
- 技術選型靈活微服務架構下，技術選型是去中心化的。在一個有多個服務相互協作的系統中，可以在不同的服務中使用最合適該服務的技術。
- 容錯當某一功能發生故障時，在單一進程的傳統架構下，故障很有可能在進程內擴散，形成應用全局性的不可用。在微服務架構下，故障會被隔離在單個服務中。若設計良好，其他服務可通過重試、平穩退化等機制實現應用層面的容錯。
- 擴展單塊架構應用也可以實現橫向擴展，就是將整個應用完整的復制到不同的節點。當應用的不同組件在擴展需求上存在差異時，微服務架構便體現出其靈活性，因為每個服務可以根據實際需求獨立進行擴展。
- 簡化部署在有幾百萬行代碼的程序中，即使修改一行代碼，也需要重新部署整個應用程序才能發布該變更。這種部署影響大風險高。在微服務架構中，各個服務部署是獨立的，這樣就可以更快的對特定的代碼進行部署，如果真出了問題，也只會影響一個服務，并且容易快速回滾。
- 與組織結構相匹配我們經歷過太多由于團隊和代碼庫過大所引發的問題。微服務可以很好的將架構和組織進行匹配，避免出現過大的代碼庫，從而獲得理想的團隊大小及生產力。服務的所有權也可以在團隊之間遷移，從而避免異地團隊的出現。我們可以結合康威定律進行合理的調整：第一定律 組織溝通方式會通過系統設計表達出來。第二定律 時間再多一件事情也不可能做的完美，但總有時間做完一件事情。第三定律 線型系統和線型組織架構間有潛在的異質同態特性。第四定律 大的系統組織總是比小系統更傾向于分解。
- 可組合性分布式系統和面向服務架構的主要好處是易于重構已有功能。而在微服務架構中，根據不同的目的可以通過不同的方式使用同一功能，在考慮客戶如何使用該軟件時尤為重要。
- 可替代性我們在工作中可能接觸過一些龐大丑陋的遺留系統，他們無人敢碰，但是對公司業務至關重要。為什么這些系統直到現在還沒有被取代?其實你很清楚：工作量大，且風險極高。想想看，在單體應用中你是否會在一天內刪除上百行代碼且確信不會引發問題?使用微服務架構的團隊可以在需要時輕易重寫服務，或者刪除不在使用的服務。當一個代碼庫只有幾百行時，也不會對它有太多情感上的依賴，所以很容易替換它。
微服務挑戰
設計挑戰
- 設計挑戰劃定微服務范圍需要業務領域知識。每個微服務都只負責一個功能，識別這些功能需要豐富的業務領域知識。開發者對問題領域理解不充分或錯誤的理解，將導致錯誤的設計決定。也就是我們所說的范圍邊界劃分不清晰或不合理，可能給下游業務造成更高的代價。服務契約的維護每個微服務應該對外暴露一個契約(接口)用于定義它所期望接受和返回的消息。一個良好的契約應該具備以下特點：完整、簡潔、可預測。
- 運維挑戰工程師面對的微服務兩大運維挑戰：可觀測性和多點故障。可觀測性難實現的原因在于工程師需要對應用整體有所了解，把每個服務所生產的數據進行關聯和匯總。如果開發者提前認定服務存在的缺陷，那么就能更好的提醒自己如何進行設計和監控，而不會等到故障出現時才大吃一驚。
- 微服務是多個團隊設計在規模較大的組織中，通常是由多個團隊來開發和運行微服務應用。每個團隊負責不同的微服務，他們有自己的目標、工作方式和交付周期。如果開發者還需要和其他獨立的團隊協調時間表和優先級，就很難設計出一個內聚的系統。
微服務設計
- 單一職責原則把因相同原因而變化的東西聚合在一起，把因不同原因而變化的東西分離出來。這就是我們常說的內聚性。
- 服務邊界一個微服務應該可以在兩周內完全重寫，這個經驗法則在某些特定的場合下是有效的。 ——復雜度拆分大家通常能夠意識到什么是“過大”，如果你不在感覺到你的代碼庫過大，可能他就是足夠小了，足夠小即可。 ——最小原則拆分最小拆分原則需要注意的一個問題是：服務越小雖然獨特性的好處顯而易見，但是管理大量服務也會越發的復雜。如果代碼庫過大，當下團隊無法正常運維，那么應該將其拆分成小的。 ——組織匹配度拆分然而一個常見的拆分誤區是通過代碼庫的大小或代碼行數來衡量。因為服務代碼存在依賴項，每個依賴項又會包含很多代碼。
總結
希望到目前為止你已經了解了什么是微服務、它有什么特性和好處。架構師的一個重要職責是，確保團隊有共同的技術愿景，以幫助我們向客戶交付他們想要的系統。在這個編程的行業還很年輕的時代，如何在現存的行業中尋找合理的技術解決方案，做出正確的決策，這也是架構師這一角色難做好的原因之一，我們不是醫生也不是電工，我們處在行業的中間地帶，因此很耐被理解我們到底在做什么，因為很多時候我們也不清楚自己到底處在什么位置上。
規則對于智者來說是指導，對于愚蠢者來說是遵從。 每種架構的演進或者說每種技術的進步都伴隨著相應的契約規則。微服務價值體現在松耦合、高內聚。我們應該了解和追尋技術發展的源動力。因為成功要靠不斷的取舍來實現。
