微服務架構

什麼是MSA 
微服務架構（Microservices Architecture ，MSA） 
業界對於與微服務自己並無一個嚴格的定義。James Leiws 和 Martin Flower 對微服務架構作了這樣的定義： 
「微服務架構風格就像是把小的服務開發成單一應用的形式，運行在其本身的進程中，並採用輕量級的機制通訊（通常是HTTP資源API）。這些服務都是圍繞業務能力來構建的，經過全自動部署工具來實現獨立部署。這些服務可使用不一樣的編程語言和不用的數據存儲技術，並保持最小化集中管理。」

MSA包含以下特徵：

• 組件以服務形式來提供 
  如題， 微服務也是面相服務的
• 圍繞業務功能進行組織 
  微服務更傾向於圍繞業務功能對服務結構進行劃分，拆解。這樣的服務，是針對業務領域有關完整實現的軟件，它包含使用接口，持久存儲以及對應的交互，因此團隊應該是跨職能的，包含完整的開發技術，用戶體驗，數據庫以及項目管理。
• 產品不是項目 
  傳統的開發模式致力於提供一些被認爲是完整的軟件，一旦開發完成，軟件移交給維護或者實施部門，而後開發組就能夠解散了。而微服務要求開發團隊對軟件產品的整個生命週期負責。
• 強化終端及弱化通道 
  微服務的應用致力於鬆耦合和高內聚，它們更喜歡簡單的REST 風格，而不是複雜的協議（如WS或者BPEL或者集中式框架）或採用輕量級的消息總線（RabbitMQ 或ZeroMQ等）來發布消息
• 分散治理 
  將總體式框架中的組件拆分紅不一樣的服務，在構建它們時將會有更多的選擇。
• 分散數據管理 
  每一個服務管理本身的數據庫，不管是相同數據庫的不一樣實例，或者是不一樣的數據庫系統。
• 基礎設施自動化
• 容錯性設計 
  爲每一個應用的服務以及數據中心提供平常的故障檢測和恢復
• 改進設計 
  因爲設計會不斷更改，微服務所提供的服務應該可以替換或者報廢，而不是長久的發展。

MSA VC SOA

單體架構的列子 
應用做爲一體應用部署 有一些好處 
- 易於開發——當前開發工具和IDE的目標就是支持這種一體應用的開發。 
- 易於部署——只須要將WAR 文件或目錄結構放到合適的運行環境下便可。 
- 易於伸縮——只須要在負載均衡器下面運行應用的多分副本就能夠伸縮。

可是這種應用一旦變大，團隊增加看這種方法的缺點就愈來愈明顯：

• 代碼庫龐大—–巨大一體的代碼庫會嚇到開發者，尤爲是團隊新人。 應用難於理解和修改，開發速度將會減慢，模塊沒有硬邊界，模塊化也會隨着時間的增長而破壞。代碼質量逐漸降低。
• IDE 超載——代碼庫越大，IDE 越慢，開發效率越低。
• Web容器超載—–應用越大，容器啓動時間越長，時間浪費在啓動容器上
• 難於部署—— 對於頻繁的部署，巨大的單體架構應用是個問題，更新一個組件，必須從新部署整個應用， 還會中斷後臺任務
• 難於伸縮 
  單體架構只能在一個維度伸縮——-雖然能夠運行多個副原本伸縮，以知足業務量的增長，一些雲服務還能夠動態的根據負載調整應用實例數量。可是這個架構並不能經過伸縮來知足數據量的增長，每一個應用實例都要訪問所有數據，使得緩存低效，並且提高了內存佔用和I/O 流量，不一樣組件所須要的資源不一樣，因此單體架構下，不能獨立的伸縮各個組件。
• 難於調整開發規模——單體應用對整個開發規模也是障礙，一旦應用達到一個規模，將工程組織分紅專一於特定功能的模塊的團隊同常會更有效，
• 須要一個技術棧長期投入——單體架構迫使咱們開發初期選用的技術棧，很難遞增式的採用更新的技術，若是使用了後期過期的平臺框架， 當將應用遷移 到更好的框架上就頗有挑戰，甚至爲了採用新的平臺框架，須要重寫整個應用。

微服務架構正是解決單體架構缺點的替代模式。

微服務架構例子 
一個微服務架構的應用或是多層架構，或是六角架構，而且包含 多種類型的組件。

• 表示組件（Presentation Component） 
  響應處理HTTP請求，並返回HTML 或JSON/HTML （對於Web Service API 而言）

• 業務邏輯（Business Logic ） 
  應用的業務邏輯

• 數據庫訪問邏輯（Database access logic） 
  數據庫訪問對象用於訪問數據庫

• 應用集成邏輯（Application integration logic） 
  消息層，如基於Spring 的集成

  這些邏輯組件分別響應應用中不一樣的功能模塊。

最終的微服務架構解決方案

• 經過採用伸縮立方，特別是Y 軸方向上的伸縮來架構應用，將應用按功能分爲一組相互協做的服務集合，每一個服務實現一組有限並相關的功能
• 服務間經過HTTP/REST 等同步協議或AMQP 等異步協議進行通訊。
• 服務獨立開發和部署

• 每一個服務爲了與其餘服務器解耦，都有本身的數據庫。必要時，數據庫間的一致性經過數據庫複製機制或應用級事件來維護。

  這個方案 有一些好處：

• 每一個微服務都相對較小 
  易於開發者理解 
  IDE 反應更快，開發更高效 
  Web 容器啓動更快，開發更高效，提高了部署速度

• 每一個服務均可以獨立部署，易於頻繁部署新版本的服務

• 易於伸縮開發組織結構。 咱們能夠對多個團隊的開發工做進行組織，每一個團隊負責單個服務，每一個團隊能夠獨立於其餘團隊開發，部署和伸縮服務
• 提高故障隔離（fault） 好比，若是一個服務器存在內存泄露，那麼只有該服務受影響，其餘服務仍然能夠處理請求。相比之下，單體架構的一個出錯組件能夠拖垮整個系統
• 每一個服務能夠獨立開發和部署
• 消除了任何對技術棧的長期投入

固然這方案也有必定的弊病：

• 開發者要處理分佈式系統的額外複雜度
• 開發者IDE大可能是面向構建單體架構應用的，並無顯示提供對開發分佈式應用的支持
• 測試更加困難
• 開發者須要實現服務間的通訊機制
• 不適用分佈式事務實現跨服務的用例更加困難
• 生產環境的部署複雜度高，對於包含多種不一樣服務類型的系統，部署和管理操做複雜度任然存在
• 內存消耗增長。微服務架構使用 N x M 個服務實例來替代N 個單體架構應用體系，若是每一個服務運行在本身獨立的JVM 上，一般有必要對實例進行隔離，對這麼多運行的JVM， 就有M 倍的開銷，另外，若是每一個服務運行在獨立的虛擬機上，那麼開銷會更大