原文連結: https://dzone.com/articles/microservices-monoliths-and-noops
譯者：王旭敏，Nokia開發工程師，關注雲端計算、高效能及可用架構、容器等。
責編：魏偉，投稿和諮詢報道請郵件至[email protected]，另外，歡迎加入微服務技術交流群，微信搜尋“k15751091376”，群主拉入。

一個單體應用程式，通俗來說就是應用程式的全部功能被一起打包作為單個單元或應用程式。 這個單元可以是JAR、WAR、EAR，或其他一些歸檔格式，但其全部整合在一個單一的單元。 例如線上購物網站通常會包括客戶、產品、目錄、結帳等功能。 另一個例子是如下的movieplex。這樣的應用程式通常由節目預訂、新增/刪除的電影、票房收入、電影起租點和其他功能組成。在單體應用程式的情況下，所有這些功能的實現和打包在一起作為一個應用程式。

Movieplex7就是這樣一個典型的Java EE7的示例應用程式和主要特點如下：

當作為一個WAR打包這個應用程式將是這樣的：

歸檔包括形成使用者介面的一些網頁。實現業務邏輯、持久層、後臺支援層等類結構，最後還有資料庫連線定義，CDI配置等一些配置檔案。

更具體地，WAR的結構如下：

在這WAR檔案結構中，網頁在綠色框內，所有的類都是橙色框內，配置檔案是藍色的框內。
這個應用程式有點模組化實現，因為包內所有的類都通過不同的功能井然有序的被組織。網頁和配置檔案也遵循類似的模式。

單體應用程式的優點

這種型別應用程式有如下的一些優點:

1. 眾所周知的：這是當前的典型應用架構。它很容易概念化，所有的程式碼是在一個地方。現有的大部分工具、應用伺服器、框架和指令碼都是這種應用程式。
2. IDE友好: 大多數開發環境，像NetBeans、Eclipse、IntelliJ這些開發環境都是針對開發、部署、除錯這樣的單個應用而設計的。方便單步跟蹤程式碼，因為所有的程式碼都是在一起的。
3. 便於共享: 單個歸檔檔案包含所有功能，便於在團隊之間以及不同的部署階段之間共享。
4. 易於測試: 單體應用一旦部署，所有的服務或特性就都可以使用了，這簡化了測試過程，因為沒有額外的依賴，每項測試都可以在部署完成後立刻開始。
5. 容易部署: 非常便於部署，典型來說只需將單個歸檔檔案複製到單個目錄下即可。

單體應用缺陷

目前為止，單體應用已經很好地服務了我們，未來無疑還會繼續發揮重要作用。這裡還有像Etsy這樣的網站單月訪問使用者數達到六千萬以及15億頁面訪問量，也是基於一個大的單體應用構建部署的。他們把單體應用發揮到了極致，他們會每天部署一個龐大的單體應用多達50次。可惜的是，大多數公司不是這樣的。

但是，不管如何模組化，單體應用最終都會因為團隊壯大、成員變動、應用範圍擴充套件等出現問題。部署和維護任何一個跨越多年、多團隊的單體應用程式的程式碼庫就像是充滿bug的泥潭。軟體就是這麼發展的，尤其是當你面臨交付壓力時。

下面讓我們來看看單體應用的一些劣勢所在：

• 不夠靈活: 對應用程式做任何細微的修改都需要將整個應用程式重新構建、重新部署。考慮到某些使用者案例，只有某個功能的極少部分需要更新，例如：增加/刪除電影。這也將導致整個應用程式被重新編譯和部署，即使其他部分都沒有任何改動。這就意味著開發人員需要等到整個應用程式部署完成後才能看到變化。如果多個開發人員共同開發一個應用程式，那麼還要等待其他開發人員完成了各自的開發。這降低了團隊的靈活性和功能交付頻率。
• 妨礙持續交付: 單體應用可能會比較大，構建和部署時間也相應地比較長，假如任一改動都會導致程式需要被重新編譯部署的話，不利於頻繁部署，阻礙持續交付。在實際的移動應用開發中，使用者總是不停期待最新最cool的功能，這個問題會顯得尤為嚴重。
• 受技術棧限制: 對於這類應用，技術是在開發之前經過慎重評估後選定的，每個團隊成員都必須使用相同的開發語言、持久化儲存及訊息系統，而且要使用類似的工具，無法根據具體的場景做出其它選擇。但是這就像在圓孔裡裝方釘。 MySQL是否是適合的圖形儲存資料庫？是否Java是構建前端互動應用的最合適的語言？它通常不可能在沒有放棄或顯著重寫部分現有應用程式之前改變技術堆疊主線。
• 技術債務: “不壞不修（Not broken，don’t fix）”，這在軟體開發中非常常見，單體應用尤其如此。系統設計或寫好的程式碼難以修改，因為應用程式的其它部分可能會以意料之外的方式使用它。隨著時間推移、人員更迭，這必然會增加應用程式的技術債務。通常這樣的應用程式在歷經數年之後，維護和建立程式碼庫的已經是完全不同的團隊，這提高了應用程式的技術債務，使得它以後更難被重構。

什麼是微服務?

而隨著業務需求的快速發展變化，敏捷性、靈活性和可擴充套件性需求不斷增長，迫切需要一種更加快速高效的軟體交付方式。

進一步認識微服務!

微服務就是一種可以滿足這種需求的軟體架構風格。單體應用被分解成多個更小的服務，每個服務有自己的歸檔檔案，單獨部署，然後共同組成一個應用程式。這裡的“微”不是針對程式碼行數而言，而是說服務的範圍限定到單個功能。

我們都一直在使用微服務幾年了。 想想一個簡單的移動應用程式可以告訴你酒店的收視率，找出你所在目的地的天氣，預訂酒店，找到到酒店的方向，找到附近的餐廳，等等。這些應用程式有可能使用不同的服務，如Yelp的，谷歌地圖，雅虎天氣API等來完成這些任務。每個功能都能夠有效地執行作為一個獨立的服務，並在這個單一的移動應用程式組織在一起。移動應用的爆炸，以及它們不斷增長的業務需求的支援也被Forrester的四層綜合平臺所強調，並且服務也是一個關鍵組成部分。

讓我們看看什麼是微服務基於應用的特性。

微服務的特徵

讓我們看看使用微服務構建的應用程式的特徵。

• 領域驅動設計: 應用程式功能分解可以通過Eric Evans在《領域驅動設計》中明確定義的規則實現，領域驅動設計不是分解應用程式的唯一方法，但肯定是很常用的一種；每個團隊負責與一個領域或業務功能相關的全部開發；團隊遵循全棧開發方法擁有全系列的開發人員，具備使用者介面、業務邏輯和持久化儲存等方面的開發技能。
• 單一職責原則: 每個服務應該負責該功能的一個單獨的部分，這是SOLID原則之一，Unix工具程式很好地證明這一原則的重要性。
• 明確釋出介面: 每個服務都會發佈一個定義明確的介面，而且保持不變；服務消費者只關心介面，而對於被消費的服務沒有任何執行依賴；服務之間就業務模型、API、負載或其他契約達成一致並使用符合契約的方式進行通訊。介面可能會產生新版本，但介面的老版本可以繼續使用，且新服務保持後續相容。不可以通過改變契約破壞相容性。
• 獨立部署、升級、擴充套件和替換: 每個服務都可以單獨部署及重新部署而不影響整個系統。這使得服務很容易升級，例如增加更多的功能點。每個服務都可以沿著《Art of Scalability》一書定義的X軸（水平復制）和Z軸（面向查詢的分割，資料分割槽）進行獨立擴充套件；由於其他服務僅依賴釋出的介面，只要釋出相同的契約，服務實現甚至是底層技術棧都可以修改。
• 可以異構/採用多種語言: 每個服務的實現細節都與其它服務無關，這使得服務之間能夠解耦，團隊可以針對每個服務選擇最合適的開發語言、持久化儲存、工具和方法；一個需要在關係型資料庫儲存資料的服務可以選擇MySQL，另一個需要儲存文件的服務可以選擇MongoDB。不同的團隊可以根據自己的需求選擇Java EE、NodeJS、Python、Vert.x或其他對本團隊最有效的技術。
• 輕量級通訊: 服務通訊使用輕量級的通訊協議，例如在HTTP上承載的REST。由於REST本質是同步的，可能會有某些潛在的瓶頸。另一個可選機制是使用支援非同步訊息的釋出/訂閱機制。任何符合需求的訊息協議，例如AMQP、STOMP、MQTT或WebSocket，都可以使用。簡單訊息實現，例如ActiveMQ，提供了可靠的非同步組構尤其適用於這種用途。每個開發團隊可以根據服務的具體需求對同步還是非同步訊息做適宜的選擇，當然也可以混用。類似的，不同的服務會選擇特別的協議，但是團隊建立服務時仍然保有極大的自由度和獨立性。

Netflix是微服務的一個典型應用，這裡有幾篇文章介紹他們對微服務的應用。對於他們架構中微服務應用影響的更廣泛的介紹在這裡netflix.github.io.

微服務的優點

• 易於開發、理解和維護: 微服務中的程式碼僅限於業務的某一功能，因此更易於理解。IDE可以很輕鬆載入小的程式碼庫，且使開發者保持高效。
• 比單體應用啟動快: 微服務的範圍比單體應用小得多，應此會有較小的打包檔案。其結果就是，更快的部署和啟動使開發者保持高效。
• 區域性修改很容易部署: 每個服務獨立於其他服務進行部署。服務的任何區域性修改，例如更改底層實現使服務效能獲得提升，無需同同其他組進行協調。其結果就是，保持了微服務敏捷性，同時也有利於持續整合和持續交付。
• 可獨立擴充套件: 每個服務可以根據需求給予X軸（克隆）和Z軸（分割槽）進行獨立擴充套件。對於單體應用而言，這一點很難做到，且擴充套件必須一起部署。
• 改善故障隔離: 一個應為異常的服務，例如記憶體溢位或資料庫連線沒有關閉，僅影響所提供的服務而不是整個應用，增強了故障隔離能力。這個能力使得每次錯誤不會使整個應用程式宕機，僅僅是其中一小片。
• 不會受限於任何技術棧: 開發者可以自由選擇對所開發服務最適合的開發語言和技術棧。即使組織可能受限於某些技術選型時，你也不會因過去的技術決策而導致不利。這同樣賦予你用更先進的技術和語言重寫這些服務的能力。這也給予了選擇技術、工具、和平臺的自由。

微服務看上去像一枚銀彈，可以解決許多軟體開發方面的問題。這看上去很美好，但並不易於實現。微服務會極大地增加運維工作量，InfoWorld在一篇文章中明確指出：

使用微服務，一些技術債務勢必從開發轉到運維，因此，你最好有一個一流的開發運維團隊。這是非常關鍵的，像現在你的一個單體應用被多個微服務所分離，它們必須互相通訊。每個微服務可以是使用不同的平臺，棧，永續性儲存，因而將具有不同的監控和管理的要求。然後，每個服務可以獨立地在X軸和Z軸上擴充套件。每個服務可以一天內被重新多次部署。

微服務和NoOps

微服務對基礎設施提出了一些額外的需求。通常，我們將它們總稱為NoOps，本質上講，就是一組服務，提供一個更好的應用程式部署流程並確保其執行。

• 服務複製: 每個服務都需要複製，一般使用X軸克隆或Z軸分割槽。是否每個服務都需要建立邏輯可擴充套件？例如，Kubernetes提供了基於Replication Controller非常簡便的方式來複制服務。
• 服務發現: 可能需要多個服務協作提供一個應用的功能。這需要服務能夠發現其他服務。在雲環境下尤其棘手，因為其上的服務都是短暫的，很有可能擴充套件或縮減。服務解析是所有其他服務都需要的基礎功能。服務需要向中央註冊中心註冊，其他服務需要查詢註冊來解析依賴關係。Netflix Eureka, Etcd, Zookeeper 等都是這一領域的可選方案（更多細節）。
• 服務恢復: 不管測試工作做得多努力，軟體故障終會發生。關鍵問題不是如何避免故障而是如何解決故障，對於微服務這樣的分散式服務尤其突出。對於服務很重要的一點是能夠自動糾正故障，確保使用者體驗不受影響。Michael Nygard的書引入了斷路器的模式來處理軟體的彈性。Netflix’s Hystrix 提供這種設計模式的實現（更多細節）。
• 服務監控: 分佈系統最重要的一個方面就是服務監控和日誌。這使得我們可以採取任意積極的行動，例如：一個服務消耗了預料外的資源。

重構成微服務

微服務並不意味著你可以拋棄現有的程式。在大多數情況下，我們還無法做到拋棄它們。因此，我們要構建一種方法，依據它使用微服務重構現有的應用程式。雖然我們仍需要在某個階段上引入單體程式，直到它準備好被重構。就像Distributed big balls of mud所強調的:

假如你甚至不能構建一個單體程式，你真的覺得微服務就是你問題的答案？重構可能是微不足道的，但在長期而言，它的好處在Infoworld的文章中已經被顯著闡明瞭:

使用微服務重構一個單體應用可以一次性償還所有的技術債務。一個整體的功能分解是非常重要的，否則重構就成了一個分散式的單體應用而不是相反的一系列微服務為基礎的應用集合。