Martin Fowler的《微服務》是第一篇詳細介紹微服務的文章。對微服務進行了定義，並與傳統架構進行了對比，闡述了微服務的優勢。
- 原文: microservices
- 中文翻譯: 微服務
- 演說視頻@GOTO Berlin 2014
注1: 上面的中文翻譯是目前找到的最好的版本, 語句通順而準確, 向作者致敬!
注2: 找到的第一個版本的翻譯是微服務中文翻譯版本, 翻譯質量很不理想, 非常拗口而且語義也和原文有差異. 看不下去, 我曾決定自己再潤色一遍. 但翻譯到中途時發現了上面的好版本就放棄了.
注3: 這個所謂好的翻譯, 也只是前半段水準不錯, 後半段就急劇下滑, 看不下去......
術語表
| 術語(English) | 翻譯(中文) | 備註 |
|---|---|---|
| micro service | 微服務 | |
| monolithic | 單塊/單體 | 和微服務相對的傳統架構模式 |
| Conway's Law | 康威定律 | 內容一句話: "組織決定架構" |
讀書筆記
注: 英文原文和翻譯版本請見上面的鏈接. 以下部分爲個人學習筆記.
微服務定義:
微服務架構風格是一種將一個單一應用程序開發爲一組小型服務的方法，每個服務運行在自己的進程中，服務間通信採用輕量級通信機制(通常用HTTP資源API)。這些服務圍繞業務能力構建並且可通過全自動部署機制獨立部署。這些服務共用一個最小型的集中式的管理，服務可用不同的語言開發，使用不同的數據存儲技術。
和單體服務器的對比:
單體服務器是構建這樣一個系統最自然的方式。處理請求的所有邏輯都運行在一個單一進程中，允許你使用編程語言的基本特性將應用程序劃分類、函數和命名空間。你認真的在開發機上運行測試應用程序，並使用部署管道來保證變更已被正確地測試並部署到生產環境中。該單體的水平擴展可以通過在負載均衡器後面運行多個實例來實現。
單體服務器的問題:
＞ 變更週期被捆綁在一起 —— 即使只變更應用程序的一部分，也需要重新構建並部署整個單體。長此以往，通常將很難保持一個良好的模塊架構，這使得很難變更只發生在需要變更的模塊內。程序擴展要求進行整個應用程序的擴展而不是需要更多資源的應用程序部分的擴展。
微服務架構風格：
構建應用程序爲服務套件。除了服務是可獨立部署、可獨立擴展的之外，每個服務都提供一個固定的模塊邊界。甚至允許不同的服務用不同的的語言開發，由不同的團隊管理。
微服務架構的特徵 / Characteristics of a Microservice Architecture
通過服務組件化 / Componentization via Services
組件的定義:
組件是一個可獨立替換和獨立升級的軟件單元。
微服務架構組件化軟件的主要方式:
分解成服務, 而服務是一種進程外的組件，通過web服務請求或rpc機制通信
使用服務作爲組件而不是使用庫的主要原因:
- 服務是可獨立部署的
- 更加明確的組件接口: 服務通過明確的遠程調用機制可以避免組件間的緊耦合 **
缺點:
- 遠程調用比進程內調用更昂貴
- 導致遠程API被設計成粗粒度, 不便於使用
圍繞業務能力組織 / Organized around Business Capabilities
康威定律(Conway's Law):
任何設計系統(廣泛定義的)的組織將產生一種設計，他的結構就是該住址的通信結構。 -- Melvyn Conway 1967
簡單一句話就是: "組織決定架構"!
微服務的組織方式:
微服務採用不同的分割方法，劃分成圍繞業務能力組織的服務。這些服務採取該業務領域軟件的寬棧實現，包括用戶接口、持久化存儲和任何外部協作。因此，團隊都是跨職能的，包括開發需要的全方位技能：用戶體驗、數據庫、項目管理。
建議:
敦促創建單體應用程序的大型團隊將團隊本身按業務線拆分
是產品不是項目 / Products not Projects
項目模式：
目標是交付將要完成的一些軟件。完成後的軟件被交接給維護組織，然後它的構建團隊就解散了。
微服務支持者傾向於避免這種模式，而是認爲一個團隊應該負責產品的整個生命週期。
產品模式:
產品思想與業務能力緊緊聯繫在一起。要持續關注軟件如何幫助用戶提升業務能力，而不是把軟件看成是將要完成的一組功能。
微服務相對單體應用的優勢:
同樣的方法也可以用在單體應用程序上，但服務的粒度更小，使得它更容易在服務開發者和用戶之間建立個人關係。
智能端點和啞管道 / Smart endpoints and dumb pipes
在不同進程間創建通信結構時, 智能放在哪裏, 有兩種不同思路:
-
把顯著的智慧強壓進通信機制本身
一個很好的例子就是企業服務總線(ESB)，在ESB產品中通常爲消息路由、編排(choreography)、轉化和應用業務規則引入先進的設施.
-
智能端點和啞管道
微服務社區主張另一種方法, 基於微服務構建的應用程序的目標是儘可能的解耦和儘可能的內聚 - 他們擁有自己的領域邏輯，他們的行爲更像經典UNIX理念中的過濾器 - 接收請求，應用適當的邏輯併產生響應。
使用簡單的REST風格的協議來編排，而不是使用像WS-Choreography或者BPEL或者通過中心工具編制(orchestration)等複雜的協議。
最常用的兩種協議:
- 使用rest API的HTTP請求-響應和輕量級消息傳送
- 在輕量級消息總線上傳遞消息
把單體變成微服務:
最大的問題在於通信模式的改變。一種幼稚的轉換是從內存方法調用轉變成RPC，這導致頻繁通信且性能不好。相反，你需要用粗粒度通信代替細粒度通信。
去中心化治理 / Decentralized Governance
集中治理的一個後果是技術平臺的單一標準化發展趨勢。不是每個問題都是釘子，不是每個問題都是錘子。我們更喜歡使用正確的工具來完成工作.
把單體的組件分裂成服務，在構建這些服務時可以有自己的選擇。
去中心化治理的最高境界就是亞馬遜廣爲流傳的build it/run it理念: 團隊要對他們構建的軟件的各方面負責，包括7*24小時的運營.
去中心化數據管理 / Decentralized Data Management
DDD把一個複雜域劃分成多個有界的上下文，並且映射出它們之間的關係。這個過程對單體架構和微服務架構都是有用的，但在服務和上下文邊界間有天然的相關性，邊界有助於澄清和加強分離，就像業務能力部分描述的那樣。
微服務更傾向於讓每個服務管理自己的數據庫，或者同一數據庫技術的不同實例，或完全不同的數據庫系統.
分佈式事務:
微服務架構強調服務間的無事務協作，關注最終一致性和事後補償。
權衡
修復錯誤的代價是否小於一致性下業務損失的代價?
基礎設施自動化 / Infrastructure Automation
基於持續部署(和它的前身持續集成), 構建管線圖:
關鍵特性:
- 自動化測試
- 自動化部署
- 在生產環境中管理微服務
爲失效設計 / Design for Failure
使用服務作爲組件的一個後果:
應用程序需要被設計成能夠容忍服務失效。任何服務調用都可能因爲服務提供者不可用而失敗，客戶端必須儘可能優雅的應對這種失敗。
與單體應用設計相比這是一個劣勢，因爲它引入額外的複雜度。
爲因對隨時可能失敗的服務, 微服務:
- 快速檢測故障
- 自動恢復服務
- 應用程序的實時監測: 包括性能指標(如TPS)和業務指標(如訂單數)
- 告警系統: 通知開發團隊跟進和調查
微服務希望看到爲每個單獨的服務設置的完善的監控和日誌記錄:
- 控制面板上顯示啓動/關閉狀態
- 各種各樣的運營和業務相關指標
- 斷路器狀態
- 當前吞吐量和時延
進化式設計 / Evolutionary Design
分割應用的原則: 組件可獨立的更換和升級
微服務強調可替代性, 通過變更模式來驅動模塊化: 同時變化的東西保持在同一模塊中。系統中很少變更的部分應該和正在經歷大量擾動的部分放在不同的服務裏。如果你發現你自己不斷地一起改變兩個服務，這是它們應該被合併的一個標誌。
微服務是未來嗎？ / Are Microservices the Future?
Martin-Fowler 在2014年出寫下這個文章時, 還是"懷着謹慎樂觀的態度". 而這之後的一年半的時間, 業界對微服務的接受程度遠遠超過當時的預期, 幾乎可是說是推崇甚至有成爲業界標杆的趨勢.