微服務有且僅有一種非常專項的功能，通過遠程API來提供系統其余功能。舉個例子：試想一下倉庫的管理系統，這樣的系統中微服務可能提供的一些功能有：

• 接收庫存
• 計算新的庫存該存到什么地方
• 計算在倉庫內將庫存運往正確放置點的路線
• 為倉庫員工分配運送路線
• 接收訂單
• 計算倉庫內指定一組訂單的揀貨路線
• 為倉庫員工分配揀貨路線

以上這些功能(可能還會有更多)都是由單個微服務實現的。每個微服務都有單獨的運行線程，并且可以獨立于其他微服務進行部署。同樣每個微服務都有自己的專用數據庫，盡管每個微服務都會與其他微服務協作與溝通。

一個系統中的不同微服務完全有可能在不同的平臺上實現，一些可能在.NET上，另外一些在Erlang，其他的在Node.js上。只要能協調多語言的問題，各個微服務彼此正常溝通，就能奏效。HTTP是良好的溝通選擇：上面所有提到的平臺，還有很多其他平臺都能很好的處理HTTP。當然也有符合微服務溝通規則的其他技術：例如一些隊列、一些服務總線還有一些二進制協議。在這些技術當中，HTTP可能是支持最廣泛的，相當容易理解，而且就像萬維網所展示的那樣很好用，總體來說是很好的方案。

再次以倉庫系統為例：該系統的一個微服務是分配揀貨路線微服務。圖一展示了“分配揀貨路線微服務”從另一個協作微服務收到的請求：為指定員工設定了下一次的揀貨路線。分配揀貨線路微服務必須為員工找到合適的線路，而另一個微服務則完成計算***路線的工作，分配揀貨路線微服務只需收到揀貨路線通知并確定如何為雇員分配路線。在分配揀貨路線的微服務中，收到請求——分配指定員工的揀貨路線，搜索數據庫，找到合適的揀貨路線，并從中選擇一個返回給微服務調用。

圖一 分配揀貨路線微服務

微服務架構是什么?

微服務是一種架構類型，屬于輕量級的面向服務體系架構，這些服務都是嚴格專注于執行同一件事并把它做好。

使用微服務作為主要架構類型的系統是一個擁有大量協調微服務的分布式系統，每個微服務分管自己的進程。由于微服務之間緊密協作，每個微服務只提供拼圖的一小塊，而系統做為完整的作品存在。協作時，各服務彼此通過一個不綁定具體平臺的輕量級媒介進行溝通，比如.NET，Java或者Erlang。如前所述，本書中所有微服務之間的溝通都是通過HTTP的，不過還有其他可選方案，比如隊列、總線或者類似Thrift的二進制協議。

在構建與維護復雜的服務器端軟件系統時，微服務架構類型迅速流行起來。可以想見，這樣一來：在傳統的面向服務方法和整體架構(monolithic architectures)中，微服務都有大量潛在好處。在運作良好的前提下，微服務在可塑性、可擴展性與彈性方面都具有優勢，并允許使用者只花費很短的時間就實現從開始到生產環境部署的過程。

微服務特性

雖然已經說了這么多，不過定義還很模糊。為了縮小微服務的界定范圍，我們先來考察一下微服務的特性。在筆者理解中，微服務這個術語的特性是：

1. 負責單個功能

2. 單獨部署

3. 包含一個或多個進程

4. 擁有自己的數據存儲

5. 一支小團隊就能維護幾個微服務

6. 可替換的

這張特性列表不但幫助識別微服務，還能夠在發揮微服務優勢(一個擁有可塑性、可擴展性與彈性的系統)的前提下協助界定與執行該服務，依次看下去。

負責單個功能

微服務在整個系統中只負責單個功能。這句話分解來說包含兩部分內容：***，微服務只有單個責任;第二，負責的是功能。單一責任原則有幾種描述，其中一個傳統的描述是：

“當需要修改某個類的時候原因有且只有一個("There should never be more than one reason for a class to change.")” -- Robert C. Martin SRP: 單一責任原則

盡管這種說法特別提到了“類”，這一原則卻不只適用于面向對象語言的類層面。通過微服務，這里在服務層面運用單一責任原則。另一種較新的說法也是描述單一責任原則的：

聚合因同一理由變化的東西，分離因不同理由而變化的東西。("Gather together the things that change for the same reasons. Separate those things that change for different reasons.")-- Robert C. Martin單一責任原則

這一原則適用于微服務：微服務應當正好實現一個功能。微服務必須只在功能改變時才跟著改變。此外，應當努力讓微服務完全實現相關功能，這樣在功能改變時微服務也得跟著改變。

微服務系統的一個功能可能意味著幾件事。首先，功能可能是業務方面的。業務功能就是系統所完成的、對系統的目的有貢獻的事情——比如持續追蹤用戶的購物車或者計算價格。梳理一個系統擁有的獨立業務功能有一個好辦法，就是使用Domain Driven Design。第二，有時候功能可以是多個其他微服務需要利用的技術功能——例如集成到一些第三方系統中。技術功能并非是將系統分解成微服務的主因，而是由于微服務執行業務功能需要同樣的技術能力而導致的結果。

獨立部署

每個微服務都應當是單獨部署的。也就是說：當你改變一個特定的微服務時，需要能夠將微服務的變更部署到生產環境中，而無需部署或觸及系統的其他部分。事實上，系統中的其他微服務應當在改動的微服務部署之時，還有新版本部署完成之后繼續持續運行。

試想一下電子商務網站：每次購物車微服務發生改變時，都應當能立即進行部署。同時價格計算微服務、推薦微服務、產品目錄微服務等等應當繼續運行并滿足用戶的請求。

能夠單獨部署每個微服務非常重要，原因有好幾個。其中一點是，在一個微服務系統中有很多微服務，每個微服務都會與其他幾個相協作。各部分的開發工作同時完成，或者很多微服務并行。如果需要按同一步調部署所有或者很多微服務的話，管理部署很快就會變得捉襟見肘，特別是經常會導致高風險部署，這是我們很希望避免的。相反我們希望能夠對每個微服務進行小變更部署，這樣風險會更低。

能夠在系統的其他部分繼續正常運行的時候部署單個微服務，構建過程必須牢記這一點：每個微服務必須打包到不同的構件或程序包中。同樣地，部署過程本身還必須支持在其他微服務繼續運行之時，獨立部署變更的微服務。比如，每次將微服務部署到服務器的過程中，為了減少停機時間可以使用滾動部署的辦法。

微服務互動的方式也受到期望獨立部署的影響。改變微服務接口必須在大多數情況下向后兼容，這樣其他現有的微服務就可以繼續按照與舊版本融合的方式與新版本集成了。此外，微服務互動的方式必須有彈性，每個微服務必須在其他微服務偶爾出錯時繼續保持***運行狀態。一個微服務出錯——比如因為部署時的短暫停機——必須不影響其他微服務運行，只是造成功能縮減或者進行時間稍長。

包含一個或多個進程

一個微服務由一個或多個進程組成，這個特性有兩面性。首先，每個微服務獨立于其他微服務運行;其次，每個微服務可以擁有不止一個進程。

某微服務獨立運行，是由于希望保持每個微服務盡可能獨立于其他微服務繼續運行。此外，為了獨立部署微服務，那個微服務不能按照其他微服務的方式來運行。再用購物車微服務來舉例：如果按照與產品目錄微服務相同的方式運行，購物車代碼可能對產品目錄代碼產生負面影響，這代表著購物車微服務與產品目錄微服務之間緊密卻不受歡迎的耦合。

現在思考一下部署購物車微服務的新版本情況。要么得重新部署產品目錄微服務，要么就得有某種動態代碼加載功能，來替換正在運行中的購物車代碼。前一個選項與微服務獨立部署的原則完全相違背，后一個選項太過復雜而且起碼有由于部署購物車微服務而造成產品目錄微服務停機的風險。

每個微服務可能包含不止一個進程，表面來看可能令人驚訝，畢竟這里嘗試讓每個微服務盡可能簡單好控制，那么為什么要自找麻煩擁有不止一個進程呢?用電子商務網站做個比方：執行推薦算法會在電子商務網站上展示推薦選項，這些算法都在這個微服務所屬的進程中運行，還存儲了提供推薦需要的數據。這個數據可能存儲在硬盤文件里，不過更有可能存在數據庫里，在第二個進程中運行的數據庫也屬于這個微服務。一個微服務通常擁有2個或以上進程的需求，就是因為微服務需要實現所需要的一切，以提供包含諸如數據存儲還有后臺處理之類的功能。

擁有自己的數據存儲

一個微服務包含數據存儲，在該進程中存儲所需的數據，正是由于我們希望微服務的范圍是一個完整的功能。大多數業務功能需要一些數據存儲，例如對于產品目錄微服務來說，每個產品的信息需要存儲下來。為了保持產品目錄微服務與其他微服務的松散耦合性，存儲的產品信息數據完全包含在產品目錄微服務之中。由產品目錄微服務確定何時、如何存儲產品信息。其他微服務——比如購物車微服務——只能通過產品目錄微服務的接口來訪問產品信息，而永遠不能直接訪問產品目錄存儲。

每個微服務包含自己的數據存儲，這開啟了根據每個微服務需求，為不同微服務使用不同數據庫技術的可能性。產品目錄微服務可能使用SQL服務器來存儲產品信息，而購物車微服務可能用Redis來存儲每個用戶的購物車信息，推薦微服務則使用Elastic Search索引來提供推薦服務。為每個微服務所選擇的數據庫技術是執行的一部分，對其他微服務來講是隱藏的。將數據庫技術與每個微服務需求進行混合配對的好處在于，每個微服務可以使用最適合的數據庫。對開發時間、性能和可擴展性很有好處，不過也帶來了成本問題。數據庫技術上非常復雜，學習使用和在生產環境上運行一個可靠的數據庫都不容易。為微服務選擇數據庫信息時，應當考慮取舍的問題。不過也要記住，由于微服務擁有自己的數據存儲，稍候切換到另一個數據庫也是可行的。

小團隊就能維護

到現在本文并未討論太多微服務的規模問題，雖然微服務中的“微”暗示著這些服務規模很小。但這里并不認為討論微服務應當有幾行代碼，需求/用例有多少或者應當執行的功能點有幾個這些有什么意義。所有這些取決于微服務所提供功能的復雜性。真正有意義的是考慮維護微服務的工作量。指出微服務規模大小的一條經驗法則是：一個5人小團隊就應當能夠維護幾個或者更多的微服務。維護一個微服務包括保持其正常運行并達成目標：開發新的功能、從發展到過大規模的微服務中分解出新的微服務、監控測試與修復bug及其他。考慮到一個小團隊應當能夠完成幾個微服務的所有這些工作，你應當對典型的微服務規模有概念了。

可替換的

一個微服務是可替換的，代表著它可以在合理的時間框架內從頭重寫。也就是說，維護該微服務的團隊可以決定用全新的實現來替代現有的，并且不會打亂正常工作的進程。這條特性也是微服務規模的一條約束：如果一個微服務成長地太大，替代成本就會過高，只有保持小型才能讓重寫比較現實。

為什么團隊會決定重寫微服務?一個原因可能是代碼太亂，另一個原因是微服務不能在生產環境中運行良好。盡管這些情況并非所愿，卻出體現了微服務的優勢。即便努力構建微服務，時間造成的需求變更可能促使現有的實現方式無法滿足需求而需要變更。而且隨著時間過去，代碼可能會由于初始設計周折太多而變成一團亂麻。性能要求可能會需要大幅提升，而現有設計無法滿足。如果一個微服務小到在合理時間框架內便能重寫，偶爾出現這些情況都是ok的。了解現有實現所有知識的同時，再結合新需求考慮，就能簡單地完成重寫工作。