前言

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

彈性

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

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

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

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

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

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

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

技術(shù)多樣性

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

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

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

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

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

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

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

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

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

在同一系統(tǒng)中使用多種技術(shù)存在著一個問題：開發(fā)人員和系統(tǒng)管理員需要知道所有的（或一部分）相關(guān)技能。擁抱微服務的公司通?？梢员忠婚T核心技術(shù)（在本書中，我們將會使用 Node.js），并輔以一些其他技術(shù)（我們除了使用 Docker來管理部署之外，還可以采用 Capistrano或 Fabricator來管理發(fā)布）。

可替換性

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

public interface GeoIpService {

/**

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

**/

boolean isIn（String ip， String isoCode） throws

SOAPFaultException;

}

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

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

獨立性

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

為什么可替換性如此重要

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

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

易于部署

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

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

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

?微服務架構(gòu)中的基礎(chǔ)設(shè)施和配置應該盡可能自動化。在本書的后續(xù)部分中，我們將學習如何使用 Docker來部署微服務，以及這樣做相比于傳統(tǒng)部署技術(shù)會有怎樣的優(yōu)勢。