前言

在過去40 年里，軟件開發的世界日新月異，微服務日趨流行。本文為我們揭示了微服務的五大關鍵好處，看它們是如何幫助我們提升軟件質量并適應新的業務需求。

彈性

維基百科將彈性定義為系統處理變化的能力。我對彈性的理解是在問題被解決后系統從異常狀態（短暫的硬件故障以及意料之外的高網絡延遲等）或壓力期中優雅恢復，同時又不會影響系統性能的能力。

這雖然聽上去很簡單，但是在構建面向微服務軟件的時候，問題源會由于系統的分布式特性而被放大，有時很難（甚至不可能）防止所有的異常情況。

彈性是從錯誤中優雅恢復的能力。但它同樣也為系統帶來了新的復雜度：如果一個微服務出現了問題，我們能否防止系統的常規故障？理想情況下，我們應該以這樣一種方式來構建服務：僅對服務響應進行降級而非讓系統出現常規故障，即使這樣做也并不容易。

如今，各大公司的一個通病是系統存在可伸縮性問題。如果你之前曾與某個單塊軟件打過交道，我確信你在伴隨公司的成長過程中，必定會在某些時刻遭遇到容量問題。

通常，這些問題并不涉及應用的每一層次或所有子系統。往往只有個別子系統或服務會明顯慢于其余部分，一旦沒有處理好容量問題就會導致整個應用發生故障。下圖描述了我們是如何對微服務進行擴展（擴展成兩個郵件服務）的，同時又不牽扯系統的其余部分：

讓我們來看一個關于車險的場景，用于計算指定風險因素列表報價的服務便是該類問題的一個例子。通過擴展整個應用來滿足對某個特定部分的需求是否有意義？如果你腦海中的答案是“否”，那么你離擁抱微服務更近了一步。微服務可以讓你僅僅按需擴展系統的一部分，從而只加大系統特定部分的處理能力。讓我們來看一個關于車險的場景，用于計算指定風險因素列表報價的服務便是該類問題的一個例子。通過擴展整個應用來滿足對某個特定部分的需求是否有意義？如果你腦海中的答案是“否”，那么你離擁抱微服務更近了一步。微服務可以讓你僅僅按需擴展系統的一部分，從而只加大系統特定部分的處理能力。

如果該保險系統是一個面向微服務的系統，那么我們只需要創建更多的微服務實例來負責計算就能解決報價計算需求過旺的問題。請記住，擴展服務會給運維團隊增加開銷。

技術多樣性

軟件的世界每幾個月就會更新換代。新語言進入業界成為某類系統事實標準的節奏片刻未停。幾年前， Ruby onRails面世并在 2013年成為在各種新項目中使用昀多的 Web框架。Golang（由 Google創建的一門語言）因其結合了強大的性能與優雅簡潔的語法而成為當前的一種趨勢，任何只要擁有一門編程語言經驗的人都可以在幾天內學會它。

在過去，我也曾使用 Python和 Java成功編寫過微服務。

尤其是 Java，自從 Spring Boot發布之后，它成為在編寫敏捷微服務方面相當有吸引力的技術棧。

Django是一款強大且可用于編寫微服務的 Python框架，與 Ruby on Rails非常相似。通過它我們可以自動化地進行數據庫遷移，并可以非常輕松地完成創建 CRUD（創建、讀取、更新及刪除）服務的工作。

Node.js利用了著名語言 JavaScript的優勢，創建了一個新的服務端技術棧，從而改變了工程師們編寫新軟件的方式。

那么，將這些技術都結合起來會有什么問題嗎？平心而論，這是一個優勢：我們可以選擇合適的工具來做相對應的工作。

只要待集成的技術是標準化的，面向微服務的架構便可以幫你實現這一點。正如我們在上文中已經了解到的，一個微服務是非常小的，并且是一個自主運維的軟件中的獨立部分。

下圖展示了微服務是如何隱藏數據的存取邏輯的，兩個服務在存取數據方面共用同一個通信點，從而能很好地互相解耦（一個服務實現發生變化時并不涉及任何其他服務）：

此前我們曾討論到性能的問題。通常，系統的某些部分會比其他部分承受更多的壓力。通過利用當代的多核 CPU進行并行（并發）編程可以解決其中的一些性能問題。然而， Node.js并不是一門適合執行并行任務的語言。針對那些處于壓力之下的微服務來說，我們可以選擇一門更加適合的語言來進行開發，比如 Erlang，從而可以以一種更加優雅的方式來管理并發。這樣做，花不了你兩周的時間。

在同一系統中使用多種技術存在著一個問題：開發人員和系統管理員需要知道所有的（或一部分）相關技能。擁抱微服務的公司通常可以秉持一門核心技術（在本書中，我們將會使用 Node.js），并輔以一些其他技術（我們除了使用 Docker來管理部署之外，還可以采用 Capistrano或 Fabricator來管理發布）。

可替換性

可替換性是指替換系統中某個組件而不影響系統行為的一種能力。當我們在討論軟件的時候，可替換性往往是與低耦合密不可分的。在編寫微服務的時候不能將內部邏輯暴露給調用服務，服務實現對客戶端來說是透明的，客戶端了解的只有接口。讓我們來看看下面的例子，該接口是用 Java編寫的，僅需通過觀察接口就能識別出它存在著什么問題。

public interface GeoIpService {

/**

*檢查IP是否屬于指定ISO代碼所對應的國家

**/

boolean isIn（String ip， String isoCode） throws

SOAPFaultException;

}

初看該接口可以發現它是自描述的。它將檢查特定 IP是否屬于特定的國家，一旦服務出現重大問題會拋出 SOAPFaultException。

如果我們構建客戶端來消費該接口，需要考慮到服務的上述邏輯，捕獲并處理 SoapFaultException。這等同于將服務內部實現的細節暴露給了外部世界，從而很難再替換掉 GeoIpService接口。同樣的，事實上我們創建的某個服務如果關聯了應用邏輯的某個部分則表明創建了一個限界上下文：即一個高內聚的服務或服務集（通過集合所轄服務的協同工作可以達成一個目標）。

獨立性

不管我們怎么努力，人類的大腦都不擅長解決復雜問題。人類大腦昀有效的運作模式是同一時間只做一件事情，所以我們可以將復雜問題拆解成更小的問題。面向微服務的架構應該也遵從這一方式：所有服務應該都是獨立的，它們通過接口進行交互。除了協定確認接口這一環節之外，不同的工程師團隊可以在無須交流的情況下完成對服務的開發。一家采用了微服務的公司可以根據業務的需求來調整工程師團隊的規模，從而能敏捷地響應業務的高峰期或靜默期。

為什么可替換性如此重要

在前面的一個小節中，我們討論了該如何確定微服務的合理規模。按照普遍的經驗而言，一個團隊應該能在一個 sprint內完成一個微服務的重寫和部署。這樣做的背后的根本原因就是技術債務。

我會將技術債務定義為在一個既定計劃的周期內，初始技術設計與預期交付功能之間的偏差。某些方面的犧牲或錯誤假設會導致編寫的軟件非常糟糕，這樣的軟件需要全盤重構或重寫。在前面的例子中，接口在暴露給外部世界時明確表明必須使用 SOAP來調用 Web服務。一旦需要將客戶端代碼改造成 REST客戶端，REST客戶端根本無法處理 SOAP異常。

易于部署

微服務應當易于部署。作為軟件開發者，我們知道在軟件的部署過程中很多事情都可能會出現問題。正如前面所提到的，微服務是非常易于部署的，原因如下：

?少量的業務邏輯（從經驗上來說是只需兩周即可完成從無到有的編寫）導致更易于部署。

?微服務是自治的工作單元，所以升級一個服務對于復雜系統來說是一個局部可控的問題。無須重新部署整個系統。

?微服務架構中的基礎設施和配置應該盡可能自動化。在本書的后續部分中，我們將學習如何使用 Docker來部署微服務，以及這樣做相比于傳統部署技術會有怎樣的優勢。