微服務概覽

微服務是圍繞業務領域建模可獨立發布的服務，服務封裝了對應功能并可以通過網路被其他服務訪問，

從外部來看，單個微服務被視為一個黑盒子，它使用最合適的協議在一個或多個網路端點(例如，佇列或REST API)上承載業務功能，消費者，無論他們是其他微服務還是其他型別的程式，都通過這些聯網的端點來訪問這個功能，內部實作細節(如撰寫服務的技識訓存盤資料的方式)完全對外部世界隱藏，這意味著微服務架構在大多數情況下避免使用共享資料庫;相反，每個微服務在需要的地方封裝自己的資料庫，

資訊隱藏指的是盡可能少的對外部介面暴露服務資訊，微服務公開的網路介面只要向后兼容，就可以自由的對服務內部進行更改，這也符合系統的高內聚低耦合設計思路，

微服務的關鍵概念

獨立可部署

我們可以對微服務進行更改、部署并將更改發布給我們的用戶，而無需部署任何其他微服務，

圍繞業務領域建模

對于微服務架構，我們使用像領域驅動設計的思想來定義我們的服務邊界，通過圍繞業務領域建模服務，我們可以更輕松地推出新功能并以不同方式重組微服務，從而為我們的用戶提供新功能，

對于微服務，我們優先考慮業務功能的高內聚性，而不是技術功能的高內聚性，

擁有自己的狀態

微服務應該避免使用共享資料庫，

隱藏微服務中的內部狀態類似于面向物件（OO）編程中的封裝實踐，

尺寸

Thoughtworks 的技術總監 James Lewis 曾說過“微服務應該和你的腦袋一樣大”，

微服務模式（Manning Publications）的作者 Chris Richardson 曾經說過的——微服務的目標是“盡可能小地介面” ，
尺寸并不需要太擔心，比這個更需要關注的兩件事

• 你可以處理多少個微服務
• 增量遷移到微服務架構

靈活性

James Lewis 說過 “microservices buy you options.”，這句話可以這么理解，微服務架構是有成本的，你必須決定付出的成本是否值得你選擇的選項，

越向微服務演進，則靈活性會大幅提升，而這也會增加更多的痛點，所以強烈提倡逐步采用微服務，然后時刻評估引入微服務的影響，并在需要時停下來，

架構和組織的一致性

一般的Web業務都會有一個三層架構——前端團隊的UI、后端負責的業務邏輯層以及負責管理資料存盤的DBA，

如果需要開發一個新的需求，我們需要拆分需求到三個團隊，然后需要各個團隊以正確的順序進行部署，這是一種相關技術內聚度高但業務功能內聚度低的架構，

這種組織方式在微服務場景下變的不太適用，我們需要垂直業務線分解組織和架構，

這樣變更后，我們的業務領域成為推動我們系統架構的主要力量，能夠更容易地進行更改，并使我們更容易將團隊與組織內的業務線保持一致，

Team Topologies 出品的《高效能團隊模式：支持軟體快速交付的組織架構》一書中就介紹了這種組織方式的概念：
A stream-aligned team is a team aligned to a single, valuable stream of work...[T]he team is empowered to build and deliver customer or user value as quickly, safely, and independently as possible, without requiring hand-offs to other teams to perform parts of the work.

單體

Single-Process Monolith

Ruby on Rails 的創建者 David Heinemeier Hansson 有效地證明了這種架構對小型組織有意義，

Modular Monolith

對于許多組織來說，模塊化單體可以是一個很好的選擇，如果模塊邊界定義良好，它可以支持高度的并行作業，同

時通過使用更簡單的部署拓撲來避免更分布式微服務架構的挑戰，
模塊化單體架構的挑戰之一是資料庫往往缺乏我們在代碼級別的拆分，如果你想在未來拆分單體架構，則會面臨重大挑戰，

我們也看到過一些團隊通過將資料庫按照與模塊相同的方式來拆分進一步推動模塊化單體的想法

Distributed Monolith

分布式單體是一個由多個服務組成的系統，但無論出于何種原因，整個系統都必須部署在一起，分布式單體架構可能很符合 SOA 的定義，但往往無法兌現 SOA 的承諾，以我的經驗，分布式單體具有分布式系統的所有缺點，也具有單體的缺點，但沒有足夠的優點，

分布式單體通常出現在沒有足夠關注資訊隱藏和業務功能凝聚力等概念的環境中，取而代之的是，高度耦合的體系結構會導致更改跨越服務邊界，而看似無害的本地范圍內的更改會破壞系統的其他部分，

單體和交付競爭

不同的開發人員想要更改同一段代碼，不同的團隊想要在不同的時間推出功能（或延遲部署），以及圍繞誰擁有什么以及誰做決定的混亂局面，大量研究表明，所有權界限混淆的挑戰，此問題稱為交付競爭，

擁有一個單體并不意味著你肯定會面臨交付競爭的挑戰，就像擁有一個微服務架構意味著你永遠不會面臨這個問題一樣，但是微服務架構確實為您提供了更具體的邊界，可以圍繞這些邊界在系統中繪制所有權的分界線，從而在減少此問題時為你提供更大的靈活性，

單體的優勢

單體也有很多優點，更簡單的部署拓撲可以避免許多與分布式系統相關的陷阱，這可以使開發人員的作業流程更加簡單，監控、故障排除和端到端測驗等也可以大大簡化，

單體應用還可以簡化單體應用內部的代碼重用，如果我們想在分布式系統中重用代碼，我們需要決定是要復制代碼、拆分庫還是將共享功能推送到服務中，有了單體，我們的選擇就簡單多了，很多人喜歡這種簡單——所有的代碼都在那里；用它！

關于代碼重用的問題，谷歌提出的單一倉庫（所有專案在一個倉庫中）其實可以解決，但是這也就導致開發流程變的更復雜，

技術采用

當你升級你的微服務架構時，你應該不斷地尋找由日益分散的系統引起的問題，然后尋找可能有幫助的技術，而不是一上來就開始使用各種新的技術，

日志聚合與分布式跟蹤

隨著你管理的微服務越來越多，你就很難了解系統在生產環境中的表現，這也會導致線上故障排除變得更加困難，我們主張日志聚合系統作為采用微服務架構的先決條件，

這些系統允許你收集和匯總所有服務的日志，為你提供一個可以分析日志的中心位置，甚至成為主動警報機制的一部分，該領域的許多選擇可滿足多種情況，

你可以通過實作相關 ID 使這些日志聚合工具更加有用，其中單個 ID 用于一組相關的服務呼叫，例如，用戶互動而觸發的呼叫鏈，通過將此 ID 記錄為每個日志條目的一部分，隔離與給定呼叫流相關聯的日志變得更加容易，這反過來又使故障排除更加容易，

你的系統變得越來越復雜，因此必須考慮一些工具，這些工具可以讓你更好地探索系統正在做什么，提供跨多個服務分析跟蹤、檢測瓶頸以及提供給你不了解的系統問題的能力，開源工具可以提供其中一些功能，一個例子是Jaeger，它專注于等式的分布式跟蹤方面，

容器和 Kubernetes

不要急于采用 Kubernetes，甚至是容器，與更傳統的部署技術相比，它們絕對具有顯著優勢，但如果你只有幾個微服務，則很難證明采用它們的合理性，在管理部署的開銷開始變得令人頭疼之后，開始考慮服務的容器化和 Kubernetes 的使用，但是，如果你最終這樣做了，請盡最大努力確保有專業人士正在為你維護 Kubernetes 集群，可能是通過使用公共云提供商上的托管服務，運行你自己的 Kubernetes 集群可能需要大量作業！

流式傳輸

Apache Kafka已成為微服務環境中流資料的選擇，這是有充分理由的，訊息持久性、壓縮以及處理大量訊息的擴展能力等功能非常有用，Kafka 已開始以 KSQLDB 的形式添加流處理功能，但你也可以將其與Apache Flink等專用流處理解決方案一起使用，Debezium是一種開源工具，旨在幫助通過 Kafka 從現有資料源流式傳輸資料，幫助傳統資料源可以成為基于流的架構的一部分，

公共云和無服務器

公共云提供商提供大量托管服務，從托管資料庫實體或 Kubernetes 集群到訊息佇列或分布式檔案系統，通過使用這些托管服務，你可以將大量作業轉嫁給可以更好地處理這些任務的第三方，

功能即服務 (FaaS) 平臺特別受關注，因為它們圍繞代碼部署提供了很好的抽象，你不必擔心需要多少臺服務器來運行服務，只需部署代碼并讓底層平臺按需處理代碼實體，

微服務的優勢

技術異質性

一個由多個微服務協作組成的系統，我們可以決定在每個微服務內部使用不同的技術，這使我們能夠為每項作業選擇正確的工具，而不必選擇一種更標準化、一刀切的方法，
微服務可以讓你更輕松地擁抱不同的技術

借助微服務，我們還能夠更快地采用技術并了解新的進步如何幫助我們，嘗試和采用新技術的最大障礙之一是與之相關的風險，對于單體應用程式，如果我想嘗試一種新的編程語言、資料庫或框架，任何更改都會影響我的大部分系統，有了一個由多種服務組成的系統，我有多個新地方可以嘗試一項新技術，我可以選擇風險最低的微服務并在那里使用該技術，因為我知道我可以限制任何潛在的負面影響，許多組織發現這種更快地吸收新技術的能力是一個真正的優勢，

魯棒性

一種提高應用程式穩健性的關鍵概念是隔板，系統的一個組件可能會發生故障，但只要該故障沒有級聯，你就可以隔離問題，系統的其余部分可以繼續作業，服務邊界成為明顯的隔板，在單體服務中，如果服務失敗，一切都會停止作業，使用單體系統，我們可以在多臺機器上運行以減少失敗的機會，但是使用微服務，我們可以構建系統來處理某些組成服務的完全故障并相應地進行降級，

然而，我們確實需要小心，為了確保我們的微服務系統能夠正確地接受這種改進的健壯性，我們需要了解分布式系統必須處理的新故障源，網路會失敗，機器也會失敗，我們需要知道如何處理此類故障以及這些故障將對我們軟體的最終用戶產生的影響（如果有的話），

縮放

在一個大型的單體服務中，我們需要一起擴展所有內容，也許我們整個系統的一小部分在性能上受到限制，但如果這種行為被鎖定在一個巨大的單體應用程式中，我們需要將所有東西都作為一個整體來處理，使用微服務，我們可以只擴展那些需要擴展的服務，允許我們在更小、更不強大的硬體上運行系統的其他部分，

易于部署

對百萬行單體應用程式的單行更改需要部署整個應用程式才能發布更改，這可能是一個影響大、風險高的部署，在實踐中，由于可以理解到的恐懼，諸如此類的部署最終很少發生，不幸的是，這意味著我們的更改會在不同版本之間繼續累積，直到我們進入生產環境的應用程式的新版本發生大量更改，版本之間的差異越大，我們出錯的風險就越高！

使用微服務，我們可以對單個服務進行更改并獨立于系統的其余部分進行部署，這使我們能夠更快地部署我們的代碼，如果確實出現問題，可以快速將其隔離到單個服務，從而輕松實作快速回滾，這也意味著我們可以更快地將我們的新功能提供給客戶，

組織協調

我們中的許多人都經歷過與大型團隊和大型代碼庫相關的問題，當團隊分散時，這些問題可能會加劇，我們還知道，處理較小代碼庫的較小團隊往往更有效率，

微服務使我們能夠更好地使我們的架構與我們的組織保持一致，幫助我們最大限度地減少在任何一個代碼庫上作業的人數，從而達到團隊規模和生產力的最佳平衡點，微服務還允許我們隨著組織的變化而改變服務的所有權——使我們能夠在未來保持架構和組織之間的一致性，

可組合性

使用微服務，我們允許我們的功能以不同的方式用于不同的目的，當我們考慮消費者如何使用我們的軟體時，這一點尤其重要，

微服務的劣勢

開發者體驗

越來越多的服務，這讓本地開發變的復雜，本地環境能運行服務的數量是有限的
極端解決方案“云上開發”，但這會導致反饋周期受到很大影響

針對于微服務開發部分解決方案確實很少，我了解的方案比如建立內網網關打通開發網路與企業網路，然后來進行開發，但這也只是解決了網路問題，之前了解過云原生工具Nocalhost，可以縮短整個開發反饋周期，并且可以和IDE直接集成，

技術過載

微服務很可能讓你可以選擇使用不同的編程語言撰寫每個微服務、在不同的運行時上運行或使用不同的資料庫——但這些只是選項，而不是要求，你必須仔細平衡你使用的技術的廣度和復雜性與各種技術可能帶來的成本，

當你開始采用微服務時，一些基本挑戰是不可避免的：你需要花費大量時間來了解圍繞資料一致性、延遲、服務建模等問題，如果你試圖了解這些想法如何改變你對軟體開發的看法，同時你正在接受大量新技術，那么你將遇到困難，還需要知道的是，嘗試了解所有這些新技術所將占用你大量的時間，同時也將減少功能實際交付給用戶的時間，

隨著你增加微服務架構的復雜性，請考慮根據需要引入新技術，當你擁有三個服務時，你不需要 Kubernetes 集群！除了確保你不會因這些新工具的復雜性而不堪重負之外，這種逐漸增加的額外好處是使你能夠獲得新的更好的做事方式，這些方式無疑會隨著時間的推移而出現，

成本

短期來看，你會看到因為引入微服務你的成本會隨之增加，
其次學習新的技術和思想以及團隊作業方式的變更都需要時間，這將導致新功能交付變緩，你或許需要更多的人員來抵消這一成本，

根據經驗，對于一個主要關注降低成本的組織來說，微服務是一個非常糟糕的選擇，因為決策者將始終有削減陳本的心態，而IT被視為成本中心而不是利潤中心，另一方面，如果你可以使用這一架構來接觸更多的客戶或并行開發更多功能，那么微服務可以幫你賺到更多的錢，微服務是增加利潤的一種方式嗎？也許，那微服務是降低成本的方法嗎？基本不可能，

報表

對于單體系統，通常只有一個資料庫，這就意味著想要分析所有資料，只需要對這個資料庫（也可能針對只讀副本）進行報表的生成，

通過微服務架構，我們打破了這種單體架構，這并不意味著我們不再需要生成報表；我們只是讓它變得更加困難，因為現在我們的資料分散在多個邏輯隔離的模式中，
更現代的報表生成的方法，例如使用流式傳輸來允許對大量資料進行實時傳輸，這可以很好地與微服務架構配合使用，但通常需要采用新的想法和相關技術，或者，可能只需將微服務中的資料發布到中央報表資料庫（或者可能是不太結構化的資料湖）中，

監控和故障排除

對于一個標準的單體應用程式，我們可以相當簡單的進行監控，我們要擔心的機器數量很少，應用程式的故障模式也很單一——應用程式通常要么全部啟動，要么全部關閉，使用微服務架構，如果只有一個服務實體出現故障，我們是否了解其影響？

對于單體系統，如果我們的 CPU 長時間卡在 100%，我們知道這是一個大問題，擁有數十或數百個行程的微服務架構，我們可以說同樣的話嗎？當只有一個行程卡在 100% CPU 時，我們是否需要在凌晨 3 點叫醒某人？

安全

現在，更多資訊通過我們的服務之間的網路流動，這可能使我們的資料更容易在傳輸程序中被觀察到，并且可能被作為中間人攻擊的一部分進行操縱，這意味著您可能需要更加小心地保護傳輸中的資料，并確保您的微服務端點受到保護，以便只有授權方才能使用它們，

測驗

對于任何型別的自動化功能測驗，你都有一個微妙的平衡行為，測驗執行的功能越多（即測驗范圍越廣），你對應用程式的信心就越大，另一方面，測驗的范圍越大，設定測驗資料和支持的工具就越困難，測驗運行的時間就越長，當它失敗時就越難弄清楚什么是壞的，

就其涵蓋的功能而言，任何型別系統的端到端測驗都處于規模的極端，而且我們習慣于它們在撰寫和維護方面比小范圍的單元測驗更有問題，但是，這通常是值得的，因為我們希望通過端到端測驗以與用戶相同的方式使用我們的系統來獲得信心，

但是使用微服務架構，我們端到端測驗的范圍變得非常大，我們現在需要跨多個行程運行測驗，所有這些都需要針對測驗場景進行部署和適當配置，我們還需要為環境問題（例如服務實體死亡或部署失敗的網路超時）導致我們的測驗失敗時發生的誤報做好準備，

這些力量意味著，隨著你的微服務架構的發展，你在端到端測驗方面的投資回報將逐漸減少，測驗將花費更多，但無法給你與過去相同的信心，這將推動你走向新的測驗形式，例如合同驅動測驗或生產測驗，以及探索漸進式交付技術，例如并行運行或金絲雀發布，

延遲

以前可能在一個處理器上本地完成的處理現在最終可以拆分為多個單獨的微服務，以前僅在單個行程中流動的資訊現在需要通過網路進行序列化、傳輸和反序列化，你可能比以往任何時候都更頻繁地使用這些網路，所有這些都可能導致系統延遲惡化，

盡管在設計或編碼階段很難衡量對操作延遲的確切影響，但這是以增量方式進行任何微服務遷移很重要的另一個原因，做一個小的改變，然后衡量影響，這假設你有某種方法可以測量你關心的操作的端到端延遲——像 Jaeger 這樣的分布式跟蹤工具可以在這里提供幫助，但是你還需要了解 這些操作可接受的延遲時間，有時讓操作變慢是完全可以接受的，只要它仍然足夠快！

資料一致性

在單個資料庫中存盤和管理資料的單體系統到在不同資料庫中管理多個行程的分布式系統，這對資料的一致性造成了潛在的挑戰，盡管過去你可能依賴資料庫事務來管理狀態更改，但你需要了解在分布式系統中不容易提供類似的安全性，在大多數情況下，分布式事務的使用被證明在協調狀態更改方面存在很大問題，

相反，你可能需要開始使用 sagas 和最終一致性等概念來管理和推理系統中的狀態，這些想法可能需要從根本上改變你對系統中資料的思考方式，這在遷移現有系統時可能會非常令人生畏，再一次，這是另一個在分解應用程式時要謹慎的好理由，采用增量方法進行分解，以便你能夠評估更改對生產體系結構的影響，這一點非常重要，

我應該使用微服務嗎

它們可能不適合為誰作業

微服務架構對于全新的產品或初創公司來說往往是一個糟糕的選擇，

• 往往全新的產品或初創公司在前期業務改動會非常頻繁，服務邊界無法確定，域模型也無法很好的建立，但這是微服務的前置條件，
• 微服務帶來了新作業和復雜性，這會占用寶貴的開發資源，團隊越小，這種成本就越明顯，

它們在哪里作業的更好

組織采用微服務的最大原因可能是允許更多的開發人員在同一個系統上作業，而不會互相妨礙，正確設定架構和組織邊界，讓更多人彼此獨立作業，從而減少交付爭用，一家五人創業公司可能會覺得微服務架構很麻煩，一個快速增長的 100 人規模化企業可能會發現，它的增長更容易適應與其產品開發作業適當協調的微服務架構，

軟體即服務 (SaaS)，這類非常適合微服務架構，這些產品通常需要 24-7 小時運行，這在推出變更時會帶來挑戰，微服務架構的獨立可發布性是該領域的一大福音，此外，微服務可以根據需要擴大或縮小，這意味著，當你為系統的負載特性建立一個合理的基線時，你將獲得更多控制權，以確保你可以以最具成本效益的方式擴展您的系統，

微服務與技術無關的特性確保可以充分利用云平臺，公共云供應商為你的代碼提供廣泛的服務和部署機制，你可以更輕松地將特定服務的要求與最能幫助你實施它們的云服務相匹配，例如，你可能決定將一個服務部署為一組功能，另外部署為托管虛擬機 (VM)，還可以部署在托管平臺即服務 (PaaS) 平臺上，

值得注意的是，采用廣泛的技術通常會成為一個問題，但能夠輕松嘗試新技術是快速識別可能產生效益的好方法，FaaS 平臺的日益普及就是這樣一個例子，對于適當的作業負載，FaaS 平臺可以大大減少運營開銷，但目前，它并不是一種適用于所有情況的部署機制，

微服務還為希望通過各種新渠道為客戶提供服務的組織帶來了明顯的好處，許多數字化轉型作業似乎都涉及嘗試解鎖隱藏在現有系統中的功能，我們的愿望是創造新的客戶體驗，通過任何最有意義的互動機制來支持用戶的需求，
最重要的是，微服務架構可以在你繼續發展系統時為你提供很大的靈活性，當然，這種靈活性是有代價的，但如果你想在未來可能想要做出的改變方面保持開放的選擇，這可能是一個值得付出的代價，

概括

微服務架構可以為你在技術選擇、處理健壯性和擴展性、組織團隊等方面提供極大的靈活性，這種靈活性是許多人采用微服務架構的部分原因，但是微服務帶來了很大程度的復雜性，你需要確保這種復雜性是合理的，對于許多人來說，它們已成為默認的系統架構，幾乎可以在所有情況下使用，但是，我仍然認為它們是一種架構選擇，必須根據你要解決的問題來證明其使用是合理的；通常，更簡單的方法可以更輕松地交付，

盡管如此，許多組織，尤其是大型組織，已經展示了微服務的有效性，當微服務的核心概念被正確理解和實施時，它們可以幫助創建授權、高效的架構，從而幫助系統變得不僅僅是其部分的總和，

標籤：其他

上一篇：如何寫好B端產品的技術方案？

下一篇：flowable 繞過idm自帶的身份驗證