## 一、背景 ***軟件架構，總是在不斷的演進中...*** 把時間退回到二十年之前，當時企業級領域研發主要推崇的還是**C/S模式**，PB、Delphi這樣的開發軟件是企業應用開發的主流。隨著時間的推移，基于瀏覽器的**B/S架構**開始漸漸流行了起來。初期，Web開發ASP還占據了不少優勢，但JSP的預編譯模式讓性能有了很大提升，隨后基于JAVA語言的**J2EE架構**變得越來越流行。 早期軟件架構基本都是**單體架構**，系統之間往往不需要進行交互，這也導致數據孤島和ETL工具的發展。隨著企業應用越來越多，相互的關系也越來密切，應用之間也迫切需要進行實時交互訪問，隨后基于XML的異構系統集成和數據交互技術開始被很多公司采用，SOA的概念被提了出來，web service逐漸流行。 互聯網時代，很多公司為了適應更加靈活的業務需求，基于HTTP協議和Restful的架構風格及簡潔和結構清晰的JSON語言成為企業開發的最佳實踐，在SOA架構中，企業服務總線技術ESB所暴露的集中式架構的劣勢讓開發者明白基于注冊和發現的分布式架構才是解決問題的關鍵辦法。由此，微服務架構開始盛行。 在《微服務設計》中如何界定一個微服務，就是使用松耦合&高內聚原則，把因相同因素變化的事情聚集在一起，把因不同因素變化的事情區隔開來。 ## 二、微服務架構特性 微服務，其實是一種架構風格... ### 2.1 異構 服務不同最適合的技術方案不同，微服務可以幫助我們輕松采用不同的技術，并且理解這些新技術的好處。嘗試新技術通常伴隨著風險，但對于微服務系統而言，總會存在一些地方讓你可以選擇一個風險最小的服務采用新技術，并降低風險。 ### 2.2 隔離 微服務架構將系統分解為獨立運行單元，給系統帶來更好的隔離性，獨立的微服務在發生異常時更容易定位和隔離問題，隔離性也是服務擴展性的基礎。 ### 2.3 擴展 龐大的單體服務只能作為一個整體進行擴展，即使系統中只有一小部分模塊存在性能問題，也需要對整個系統進行擴展。而微服務架構可以根據性能需要對不同的模塊進行水平擴展，微服務的彈性也可以很好地處理服務不可用和功能降級問題。 ### 2.4 部署簡單 在微服務架構中，各個服務的部署是獨立的，這樣就可以更快地對特定部分的代碼進行部署。服務出現問題也更容易快速回滾，同時敏捷的交付和部署帶來了更好的業務需求響應體驗。 ### 2.5 靈活 在微服務架構中，系統會開放很多接口供外部使用，當情況發生改變時，可以使用不同的方式構建應用。而整體化的應用程序只能提供一個非常粗粒度的接口供外部使用。把單體應用分解成多個微服務，可以達到可復用、可組合的目的。 ## 什么是微服務？ 微服務是一種軟件架構模式，用于將大型整體應用程序分解為更小的可管理獨立服務，這些獨立服務通過跨語言的協議進行通信，每個服務都專注于做好一件事情。 來自行業專家的微服務的定義。 1. 松散耦合的面向服務的體系結構 --Adrian Cockcroft 2. 一種將單個應用程序開發為一套小型服務的方法，每個小型服務都運行在自己的進程中，并與輕量級機制進行通信 --Martin Fowler 微服務的概念并不新鮮，這是對面向服務的體系結構的重新構想，而是采用了一種更加全面的方式與unix進程和管道對齊的方法。 微服務架構的理念： * 這些服務是小的 - 作為一個單一的商業目的的細粒度，類似unix哲學的“做一件事，做得好” * 組織文化應該包含部署和測試的自動化。這減輕了管理和運營的負擔。 * 文化和設計原則應該包含失敗和錯誤，類似于抗脆弱的系統。 ## 為什么需要微服務？ 隨著組織規模技術和人數的增長，管理單一代碼庫變得更加困難。我們都已經習慣了在一段時間內整個Twitter失敗，因為他們試圖用一個單一的系統來擴展他們的用戶群和產品功能集。微服務使Twitter可以將他們的應用程序分解成更小的服務，這些服務可以由許多不同的團隊分別管理。每個團隊負責由許多可獨立于其他團隊部署的微服務組成的業務功能。  我們已經看到了第一手的經驗，微服務系統可以縮短開發周期，提高生產力和優越的可擴展系統。 我們來談談一些好處： 1. **更容易擴展開發** - 團隊圍繞不同的業務需求組織管理自己的服務。 2. **更容易理解** - 微服務要小得多，通常為1000 LOC或更少。 3. **更容易頻繁地部署新版本的服務** - 可以部署，縮放和獨立管理服務。 4. **改進的容錯和隔離** - 關注分離可以最大限度地減少一個服務中的問題對另一個服務的影響。 5. **提高執行速度** - 團隊通過獨立開發，部署和管理微服務來更快地實現業務需求。 6. **可重復使用的服務和快速原型** - 微服務中的unix理念使您能夠重用現有服務，并更快地構建全新的功能。