討論微服務以前，你知道微服務的 4 個定義嗎？

關於「什麼是微服務」的問題，其實並無一個統一的認識。這些年在不一樣的場合裏和不一樣背景的朋友都在探討微服務。但聊得越多，就愈加現你們聊的不是同一回事。和 DevOps 同樣，「微服務」也是一個內涵十分普遍的詞。本文從「Microservice「這個概念的源頭出發，總結了 4 個經常使用的微服務定義。

James Lewis 原始版的微服務 6 大特徵

這個版本起源於2012年，這裏首先要注意年份，那時候尚未 Docker，並且 Netflix 的微服務化過程也在這個概念提出以前——2008年就開始了，那時候甚至連 DevOps 還沒發明出來。James Lewis 在波蘭第 33 次 Degree in Kraków 會議上分享了一個案例，名稱是 「Micro Services - Java, the Unix Way」。在這個分享裏， James Lewis 分享了在 2011 年中參與的一個項目中所採用的一系列實踐，以 UNIX 的哲學從新看待企業級 Java 應用程序，而且把其中的一部分稱之爲「 Micro-Services 」。

這個時候的微服務所用的單詞和咱們如今所用的 Microservices 這個單詞有所不一樣。一方面，採用 Micro 做爲形容詞，是和 Monolithic 相對，而不是和 Macro 相對是源於操做系統這門大學課程。咱們知道，現代的操做系統課程都是以 UNIX 做爲案例進行講解的。而這兩個單詞來自於「微內核」（Micro-Kernel）和「宏內核」（Monolithic kernel）的比較。而很是見的「微觀經濟學」和「宏觀經濟學」中的 Micro 和 Macro 兩個相對應的單詞。

另外一方面，服務要以複數形式出現，表示的是一個以上。因爲漢語裏單複數是同型的，因此咱們在翻譯的時候會出現問題。所以，「微服務」在做爲架構的形式出現的時候，咱們會用「微服務架構」稱呼。單個的微服務從概念上爲了和 SOA 以及其它領域的「服務」有所區分，會以「單個微服務」以示區別。而」微服務「單獨拿出來是被看做爲一系列技術實踐的總稱。

在這個分享裏，James Lewis將所實踐的「微服務架構」總結爲 5 大特徵：

1. Small with a single responsibility —— 「小到只有單一原則」

   在這個特徵裏，關於微服務有多小有兩個標準：

   第一個標準是：若是一個類複雜的超過一個開發人員的理解範圍，那麼它就太大了，須要被繼續拆分。

   第二個標準是：若是它小到能夠隨時丟棄並重寫，而不是繼續維護遺留代碼，那麼它就足夠小。這個標準有個很重要的原則就是 Rewrite over Maintain，即「重寫勝於維護」。

2. Containerless and installed as well behaved Unix services —— 「去容器化而且做爲 Unix Service 安裝」

   在這個特徵中，James Lewis 提倡採用 Jetty 這樣的工具集成到 Maven 裏，能夠很方便的調試或者部署。而後打包成一個可執行的 JAR 包並以 UNIX 守護進程的方式在系統啓動時執行。

   特別是在 AWS 這樣的公有云環境下，把這樣的應用程序和虛擬機實例的初始化腳本結合在一塊兒。使得應用程序的生命週期和虛擬機的生命週期綁定成爲一體，因爲守護進程在全部 Unix 系統中都是通用的，所以簡化總體架構的開發和運維。

3. Located in different VCS roots ——「分佈在不一樣的版本控制代碼庫裏」

   在這個特徵中，James Lewis 提到了應用程序的分離，他認爲一個「微服務」應該徹底和另一個服務實現完全的隔離，這裏固然是指的從開始的代碼庫就開始隔離了。

   他一樣也要求開發人員看到類似性和抽象，並採用單一的領域來指導開發團隊的開發。

   所以接下來他繼續討論了領域驅動設計領域驅動設計和康威定律的重要性。他認爲界限上下文要足夠的清晰，但能夠有所重合。若是沒有辦法作到領域之間很清晰，就經過「物理上的手段」——分離不一樣的團隊來作到這一點。

   這不可避免的帶來一些公共代碼，但要把這些公共代碼做爲「庫」和「基礎設施即代碼」來對待，就像你代碼中用到的開源軟件。並搭建一個 nexus 庫來存儲那些二進制依賴。

4. Provisioned automatically ——「自動初始化」

   自動初始化的要點不在於如何自動化，由於不一樣的應用不一樣的平臺有不一樣的初始化方式。這裏的重點在於管理分佈式應用的複雜性。因此對於每一個服務，可以採用聲明出這些初始化。例如：服務 A，須要一個 負載均衡，而且能夠自動擴展。服務 B，也是一樣的聲明方式。而這些聲明能夠用基礎設施即代碼技術很好的管理起來。

5. Status aware and auto-scaling ——「關注狀態和自動擴展」

   在這裏，他認爲這些應用應該是可以感知吞吐量的監控指標來自我進行擴展的。對於一個現代的應用而言，這是一個基本的架構性要求，但這須要團隊有必定的 DevOps 能力。由於這不光要求開發人員可以讓應用無狀態化，並且要求基礎設施能夠及時捕獲環境的變化。

6. They interact via the uniform interface —— 「它們經過統一格式的接口進行交互」

   在這裏，James 建議你們採用已經成熟的 HTTP 協議以及標準的媒體類型進行接口交互，而不是採用其它的方式。而且採用 HEATOS 的方式構建 Restful API，使其成爲一個超媒體的應用狀態引擎。這樣就能夠將狀態和執行過程隔離區分開來，更加容易進行水平擴展。此外，它也構建了一個避免架構孵化的層，能夠獨立於客戶端持續演進。

在總結的時候，它特地提到了 UNIX 哲學。這引用自Doug McIlroy 的一篇採訪：

Everybody started putting forth the UNIX philosophy. Write programs that do one thing and do it well. Write programs to work together. Write programs that handle text streams, because that is a universal interface.」 Those ideas which add up to the tool approach, were there in some unformed way before pipes, but they really came together afterwards. Pipes became the catalyst for this UNIX philosophy. 「The tool thing has turned out to be actually successful. With pipes, many programs could work together, and they could work together at a distance.」

從這段話裏，咱們看到了「微服務架構」和 UNIX 哲學之間的關聯：

1. 職責獨立：讓多個程序（注意是 Programs 不是 Program）作好一件事。
2. 統一接口：文本流是統一的接口，每一個程序均可以經過統一的接口進行消費。
3. 公共通訊：採用管道（pipe）的方式

能夠說，微服務架構自己是對 UNIX 哲學在企業級 Java 應用系統中的另外一個案例。能夠說，雖然應用場景變了，但 UNIX 分解複雜度的方式和保持簡單的理念並未改變。

最後，James Lewis 把上述六點特徵變成了一個六邊形的業務能力：

Hexagonal Business capabilities composed of:
Micro Services that you can
Rewrite rather than maintain and which form
A Distributed Bounded Context.
Deployed as containerless OS services
With standardised application protocols and message semantics
Which are auto-scaling and designed for failure

翻譯過來就是：

微服務你能夠經過重寫而非維護一個分佈式的界限上下文，且做爲一個無應用容器的操做系統服務部署。並以標準化的應用協議和消息語義，爲失敗設計且可自動擴展。

Martin Fowler & James Lewis 合做版的微服務 9 大特徵

因爲在 James Lewis 以後，有不少不一樣的項目也採用「微服務」做爲它們的實踐的名稱。然而，不一樣的項目之間仍是存在一些差別的，且每一個人都按照本身的方式在實踐「微服務」。所以，基於「求同存異」的原則，Jame Lewis 的同事 —— 大名鼎鼎的 Martin Fowler 採用一種概括的方式來解決這個問題：他認爲「定義」是一些「共有的特徵」(Common characteristics)。Martin Fowler 繼續採用了 James Lewis 對這一系列實踐的命名，而且作了修改，使之成爲一個單獨的名詞 —— Microservices。

因此，他將微服務總結爲如下9大特徵：

1. 經過服務組件化

2. 圍繞業務能力組織

3. 是產品不是項目

4. 智能端點和啞管道

5. 去中心化治理

6. 去中心化數據管理

7. 基礎設施自動化

8. 爲失效設計

9. 演進式設計

這 9 大特徵的中文版具體內容請參考這裏，限於篇幅緣由，本文不展開討論。

咱們能夠從中看出，Martin Fowler 試圖將 James Lewis 的微服務定義進行通常化推廣，使其不光之能夠在不一樣的語言架構和技術棧上使用。又能夠兼顧敏捷、DevOps 等其它技術，成爲一個架構的「最佳實踐」集合。但這樣一組實踐本質上並無太多的創新，只是把咱們自己知道的不少架構和設計的原則結合在當前的技術棧上進行了一次總體的組合和應用。

恰逢一系列互聯網公司的成功事蹟帶來的新實踐（持續交付、DevOps）和新技術（Docker）在經歷了早期實踐者（Early Adopter）實踐積累後的結果井噴後。這樣的最佳實踐的集中反應當然獲得了技術人員的掌聲。然而，這樣的一種定義對於妄圖採用「微服務架構「的人來講是一個很高的門檻。若是這樣的 9 個特徵的總結是對」微服務架構「的定義。那麼，爲了要知足以上的 9 個定義，則須要花費很大的精力來進行改造，並且已經超出了技術升級和企業 IT 部門的職責範圍。此外，即使咱們知道其中每一個特徵所帶來的收益，但卻很難拿出案例和數據去佐證知足這 9 個特徵的改造收益。

避開這 9 個特徵的概念正交性不談，即使這 9 個特徵能夠從既有的結果來回答」什麼（What）是微服務「，但卻沒有給出「爲何（Why）要知足這些特徵」和」如何（How）同時知足這些特徵」。

若是本身挖的坑填不了，就教給別人來填吧：

Sam Newman 版微服務的 兩大特徵和 7 個原則

一樣做爲 Martin Fowler 的同事，Sam Newman 在其著做 」Building Microservice「（中文譯名爲」微服務設計「）的第一章就從新回答了」什麼是微服務架構「並回答了」爲何要採用微服務架構「的問題。

Sam Newman 在書中是這麼定義微服務的（《微服務設計》的翻譯）：

微服務就是一些協同工做的小而自治的服務。

Sam Newman 自述的微服務的定義更加簡單，包含了兩個特徵：「小」 和 「自治」。

除了繼承 James Lewis 關於微服務應該有多小的描述之外（固然，大小都是基於我的的主觀判斷），還創造性的用康威定律來約束微服務的大小，即「可否和團隊結構相匹配」：若是你的團隊維護單個服務很吃力，須要保持團隊大小不變的狀況下還對維護工做遊刃有餘，那麼這個服務就須要繼續被拆分。

而「自治」 則很謹慎的把 Martin Fowler 微服務定義的 9 大特徵中的「去中心化」、「獨立」 、」鬆散耦合「等字眼進行了統一。並進一步解釋到「一個微服務就是一個獨立的實體」。而且從外部，也就是黑盒的角度來看每一個符合」自治」的單個微服務所具備的特徵，即：

1. 能夠獨立部署。
2. 經過網絡通訊。
3. 對消費方的透明。
4. 儘量下降耦合，使其自治。

此外，他還採用了更簡單的「黃金法則」來判斷期」自治性」。即可否修改一個服務並對其部署，且不影響其餘任何服務。若是答案是否認的，說明你的微服務還不夠」自治「。

從 Sam Newman 的定義中，咱們能夠推導出「微服務」的幾個基本事實：

1. 微服務架構是一個分佈式系統架構。
2. 微服務是微服務架構的基本單元。
3. 網絡隔離是」必要的「解耦手段。
4. 微服務的業務功能從概念上是完整的，並符合用戶角度的「獨立」認知。

簡而言之，以上的兩個特徵的表述主要是將微服務從邏輯架構上和部署架構上都看做是一個正交的原子功能單元。而要作到這一點，則須要而要把整個應用系統正確的建模到這個層次，則須要參考不少的內部外部因素。

此外，爲了達到「小」和「自治」的目的，Sam Newman 還總結了 7 條原則用來在實施的時候和具體實踐結合，分別是：

1. 圍繞業務概念建模
2. 接受自動化文化
3. 隱藏內部實現細節
4. 讓一切都去中心化
5. 可獨立部署
6. 隔離失敗
7. 高度可觀察

能夠看出，Sam Newman 把 Martin Fowler 的 9 大特徵用更加具體的術語來從新描述，而且從邏輯上處理了 Martin Fowler 微服務 9 大特徵中概念重複和不明確的部分，使其更簡單和明確而且更加可操做。例如把「去中心化的數據管理」 和 「去中心化治理」合併爲「讓一切都去中心化」等。

更重要的是，Sam Newman 提出了採用微服務技術的主要好處，告訴了咱們「爲何要用微服務」：

1. 技術異構性：採用更合適的技術棧靈活的處理局部問題。
2. 彈性：這裏的「彈性」是彈性工程學的概念，指的是局部失敗會被隔離，使得總體不會失敗。
3. 擴展：能夠根據系統的部分組件按需擴展。
4. 簡化部署：這裏簡化部署不是指的是部署的拓撲結構，而是經過持續的小批量、小範圍的部署來下降總體失敗的風險。
5. 與組織結構相匹配：微服務架構可讓組織的團隊轉化爲合適的大小，並採用透明的制度來進行規範和複製。避免團隊的人數增加而帶來更多的管理層，使組織熵的上漲。
6. 可組合性：因爲各個微服務間不存在依賴關係，因此能夠根據用戶界面的狀況進行靈活的調整和複用，避免對單體應用進行總體的大規模調整。
7. 對可替代性的優化：因爲風險和領域更加獨立和隔離。所以，拋棄一個微服務並重寫的成本並就變的十分低廉。

Chris Richardson 的「微服務架構模式」

2017 年，Chris Richardson 使用 Microservices.io 域名開始推廣本身的微服務理念。他是這樣定義微服務的：

Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of loosely coupled services, which implement business capabilities. The microservice architecture enables the continuous delivery/deployment of large, complex applications. It also enables an organization to evolve its technology stack.

中文翻譯過來，大意以下：

微服務，也就是微服務架構。是一種用於把一個應用程序結構化爲一個實現業務功能的鬆散耦合的服務集合的架構風格。
微服務架構使得在大型、複雜的應用程序中實現持續交付和持續部署成爲可能。它使得組織能夠演進本身的技術棧。

在 Chris Richardson 採用了較爲簡單的架構定義和準確的目標定義相結合的方式來定義」微服務架構「：它一方面簡單的把微服務架構定義成一個實現業務功能的鬆散耦合的服務集合，另外一方面又以十分具體的目標和結果（持續交付/持續集成）來約束這樣一個鬆散耦合系統的效果：組織能夠演進本身的技術棧。

Chris Richardson 將「單體架構」和「微服務架構」看作兩種架構模式。而且在一樣的上下文中對兩者各自的優劣進行了比較。更加劇要的是，Chris Richardson 採用 AFK 擴展立方來拆分微服務從而回答了「如何作微服務」的問題。

值得注意的是，Chris Richardson 所採用的例子雖然在一樣的上下文中，但因爲特徵不一樣並不具有可比較性。所以，他採用了在」單體架構模式「（Pattern: Monolithic Architecture）的基礎上描述其侷限性的方法引出了」微服務架構模式「（Pattern: Microservice Architecture）。嚴格的說，Chris Richardson 的「單體架構模式「是一種對現狀的和舉例，並無給出其特徵和方法的描述，所以不能稱之爲模式。而」微服務架構模式「則又是一系列模式的總和，以下圖所示：

PatternsRelatedToMicroservices

從這個角度看，Chris Richardson 的這些模式並無突破 Sam Newman 在《微服務設計》中總結出的實踐。但相較於咱們所知道的微服務的優勢。Chris Richardson 也列出了微服務的缺點：

1. 開發者的 IDE 對分佈式系統的在線開發和調試相對於單體應用架構來講並不友好。
2. 測試更加困難。
3. 開發者必須實現跨服務的通訊機制。
4. 不採用分佈式事務來跨服務構建業務是十分困難的。
5. 須要進行跨團隊的協調工做。
6. 部署更加複雜。
7. 更多的內存消費，對於 Java 應用來講，獨立的部署意味着沒法共享 JVM 的內存管理。

相較於以前的微服務定義而言， Chris Richardson 的微服務體系比較完整，而不只僅是總結和列舉實踐。Chris Richardson 的」微服務架構模式」不光回答了「什麼是（What）微服務」，也回答了「爲何（Why）要用微服務」，「何時（When）用微服務」，「什麼場景（Where）下」以及「如何（How）實現微服務」的問題。

Chris Richardson 還編寫了一套微服務的指南，能夠在這裏 查看。

比」什麼是微服務「更重要的事

本文總結了微服務常見的 4 個定義。但比這些定義更重要的是你爲何要用微服務？你想從微服務中得到什麼益處？你是否瞭解爲了追求這些益處所帶來的代價？若是不先明確這些問題，在不理解微服務架構或者技術所帶來的的風險和成本。盲目的採用所謂的微服務，可能帶來的結果並不理想。

不過，在討論這些問題以前，坐下來統一一下對微服務的理解，會提高咱們討論和實踐微服務的效率。