《微服務設計》第 1 章　微服務

• 2019 年 10 月 8 日
• 筆記

第 1 章　微服務

• Eric Evans 的《領域驅動設計》一書幫助我們理解了用代碼呈現真實世界的重要性，並且告訴我們如何更好地進行建模。持續交付理論告訴我們如何更有效及更高效地發佈軟件產品，並指出保持每次提交均可發佈的重要性。基於對 Web 的理解，我們尋找到了機器與機器交互的更好方式。Alistair Cockburn 的六邊形架構理論（http://alistair.cockburn.us/Hexagonal+architecture）把我們從分層架構中拯救出來，從而能夠更好地體現業務邏輯。藉助虛擬化平台，我們能夠按需創建機器並且調整其大小，藉助基礎設施的自動化我們也很容易從一台機器擴展到多台。在類似 Amazon 和 Google 這樣成功的大型組織中，有很多小團隊，他們各自對某個服務的全生命周期負責。最近，Netflix 分享了構建大型反脆弱系統的經驗，而這種構建方式在 10 年前是很難想像的
• 隨着領域驅動設計、持續交付、按需虛擬化、基礎設施自動化、小型自治團隊、大型集群系統這些實踐的流行，微服務也應運而生。它並不是被發明出來的，而是從現實世界中總結出來的一種趨勢或模式

1.1　什麼是微服務

• 微服務就是一些協同工作的小而自治的服務

1.1.1　很小，專註於做好一件事

• 內聚性是指將相關代碼放在一起，在考慮使用微服務的時候，內聚性這一概念很重要
• 把因相同原因而變化的東西聚合到一起，而把因不同原因而變化的東西分離開來。」
• 微服務將這個理念應用在獨立的服務上。根據業務的邊界來確定服務的邊界，這樣就很容易確定某個功能代碼應該放在哪裡
• 澳大利亞 RealEstate.com.au 的 Jon Eaves 認為，一個微服務應該可以在兩周內完全重寫，這個經驗法則在他所處的特定上下文中是有效的
• 如果你不再感覺你的代碼庫過大，可能它就足夠小了
• 另外一個幫助你回答服務應該多小的關鍵因素是，該服務是否能夠很好地與團隊結構相匹配。如果

1.1.2　自治性

• 一個微服務就是一個獨立的實體。它可以獨立地部署在 PAAS（Platform As A Service，平台即服務）上，也可以作為一個操作系統進程存在
• 這些服務應該可以彼此間獨立進行修改，並且某一個服務的部署不應該引起該服務消費方的變動。對於
• 如果系統沒有很好地解耦，那麼一旦出現問題，所有的功能都將不可用。有一個黃金法則是：你是否能夠修改一個服務並對其進行部署，而不影響其他任何服務？

1.2　主要好處

1.2.1　技術異構性

• 如果系統中的一部分需要做性能提升，可以使用性能更好的技術棧重新構建該部分。系統中的不同部分也可使用不同的數據存儲技術，
• 下圖展示了該異構架構

• 對於微服務系統而言，總會存在一些地方讓我可以嘗試新技術。你可以選擇一個風險最小的服務來採用新技術，即便出現問題也容易處理。這種可以快速採用新技術的能力對很多組織而言是非常有價值的

1.2.2　彈性

• 將同樣的實例運行在不同的機器上來降低功能完全不可用的概率，然而微服務系統本身就能夠很好地處理服務不可用和功能降級問題

1.2.3　擴展

• 使用較小的多個服務，則可以只對需要擴展的服務進行擴展，這樣就可以把那些不需要擴展的服務運行在更小的、性能稍差的硬件上

1.2.4　簡化部署

• 在微服務架構中，各個服務的部署是獨立的，這樣就可以更快地對特定部分的代碼進行部署。如果真的出了問題，也只會影響一個服務，並且容易快速回滾，這也意味着客戶可以更快地使用我們開發的新功能。Amazon 和 Netflix 等組織採用這種架構主要就是基於上述考慮

1.2.5　與組織結構相匹配

• 微服務架構可以很好地將架構與組織結構相匹配，避免出現過大的代碼庫，從而獲得理想的團隊大小及生產力

1.2.6　可組合性

• 分佈式系統和面向服務架構聲稱的主要好處是易於重用已有功能。而在微服務架構中，根據不同的目的，人們可以通過不同的方式使用同一個功能，在考慮客戶如何使用該軟件時這一點尤其重要

1.2.7　對可替代性的優化

• 使用微服務架構的團隊可以在需要時輕易地重寫服務，或者刪除不再使用的服務

1.3　面向服務的架構

• SOA（Service-Oriented Architecture，面向服務的架構）是一種設計方法，其中包含多個服務，而服務之間通過配合最終會提供一系列功能。一個服務通常以獨立的形式存在於操作系統進程中。服務之間通過網絡調用，而非採用進程內調用的方式進行通信
• 更好地實施 SOA，而這事實上就是微服務架構。就像認為 XP 或者 Scrum 是敏捷軟件開發的一種特定方法一樣，你也可以認為微服務架構是 SOA 的一種特定方法

1.4　其他分解技術

1.4.1　共享庫

• 基本上所有的語言都支持將整個代碼庫分解成為多個庫，這是一種非常標準的分解技術
• 這種方式存在一些缺點
• 首先，你無法選擇異構的技術
• 其次，你會失去獨立地對系統某一部分進行擴展的能力。再次，除非你使用的是動態鏈接庫，否則每次當庫有更新的時候，都需要重新部署整個進程，以至於無法獨立地部署變更。而最糟糕的影響可能是你會缺乏一個比較明顯的接縫來建立架構的安全性保護措施，從而無法確保系統的彈性

1.4.2　模塊

• 有些語言提供了自己的模塊分解技術。它們允許對模塊進行生命周期管理，這樣就可以把模塊部署到運行的進程中，並且可以在不停止整個進程的前提下對某個模塊進行修改

1.5　沒有銀彈

• 微服務不是免費的午餐，更不是銀彈，如果你想要得到一條通用準則，那麼微服務是一個錯誤的選擇。你需要面對所有分佈式系統需要面對的複雜性