微服務入門權威指南

大閒人柴毛毛發表於2018-03-20

微服務

本文將詳細闡述微服務的方方面面，帶領大家進入微服務的世界。本文篇幅較長，共計2.4w字。有基礎的同學可以選擇感興趣的章節閱讀。

轉載請與我聯絡！

本文將介紹如下內容：

微服務概述

1.1 易於擴充套件

1.2 部署簡單

1.3 技術異構性
資料庫的服務化切分

2.1 什麼是“分庫分表”？

2.2 資料庫擴充套件的幾種方式

2.3 分庫分表的幾種方式

2.4 引入分庫分表中介軟體後面臨的問題

2.5 現有分庫分表中介軟體的橫向對比
微服務架構中的分散式事務

3.1 什麼是事務？

3.2 事務的四大特性 ACID

3.3 事務的隔離級別

3.4 什麼是分散式事務？

3.5 CAP理論

3.6 BASE理論

3.7 酸鹼平衡

3.8 分散式事務協議

3.9 分散式事務的解決方案
服務部署

4.1 持續整合、持續部署、持續交付

4.2 微服務與持續整合

4.3 微服務構建物
參考文獻

1. 什麼是微服務？

我們首先給出微服務的定義，然後再對該定義給出詳細的解釋。

微服務就是一些可獨立執行、可協同工作的小的服務。

從概念中我們可以提取三個關鍵詞：可獨立執行、可協同工作、小。這三個詞高度概括了微服務的核心特性。下面我們就對這三個詞作詳細解釋。

可獨立執行

微服務是一個個可以獨立開發、獨立部署、獨立執行的系統或者程式。
可協同工作

採用了微服務架構後，整個系統被拆分成多個微服務，這些服務之間往往不是完全獨立的，在業務上存在一定的耦合，即一個服務可能需要使用另一個服務所提供的功能。這就是所謂的“可協同工作”。與單服務應用不同的是，多個微服務之間的呼叫時通過RPC通訊來實現，而非單服務的本地呼叫，所以通訊的成本相對要高一些，但帶來的好處也是可觀的。
小而美

微服務的思想是，將一個擁有複雜功能的龐大系統，按照業務功能，拆分成多個相互獨立的子系統，這些子系統則被稱為“微服務”。每個微服務只承擔某一項職責，從而相對於單服務應用來說，微服務的體積是“小”的。小也就意味著每個服務承擔的職責變少，根據單一職責原則，我們在系統設計時，要儘量使得每一項服務只承擔一項職責，從而實現系統的“高內聚”。

2. 微服務的優點

1. 易於擴充套件

在單服務應用中，如果目前效能到達瓶頸，無法支撐目前的業務量，此時一般採用叢集模式，即增加伺服器叢集的節點，並將這個單服務應用“複製”到所有的節點上，從而提升整體效能。然而這種擴充套件的粒度是比較粗糙的。如果只是系統中某一小部分存在效能問題，在單服務應用中，也要將整個應用進行擴充套件，這種方式簡單粗暴，無法對症下藥。而當我們使用了微服務架構後，如果某一項服務的效能到達瓶頸，那麼我們只需要增加該服務的節點數即可，其他服務無需變化。這種擴充套件更加具有針對性，能夠充分利用計算機硬體/軟體資源。而且只擴充套件單個服務影響的範圍較小，從而系統出錯的概率也就越低。

2. 部署簡單

對於單服務應用而言，所有程式碼均在一個專案中，從而導致任何微小的改變都需要將整個專案打包、釋出、部署，而這一系列操作的代價是高昂的。長此以往，團隊為了降低釋出的頻率，會使得每次釋出都伴隨著大量的修改，修改越多也就意味著出錯的概率也越大。當我們採用微服務架構以後，每個服務只承擔少數職責，從而每次只需要釋出發生修改的系統，其他系統依然能夠正常執行，波及範圍較小。此外，相對於單服務應用而言，每個微服務系統修改的程式碼相對較少，從而部署後出現錯誤的概率也相對較低。

3. 技術異構性

對於單服務應用而言，一個系統的所有模組均整合在一個專案中，所以這些模組只能選擇相同的技術。但有些時候，單一技術沒辦法滿足不同的業務需求。如對於專案的演算法團隊而言，函式試程式語言可能更適合演算法的開發，而對於業務開發團隊而言，類似於Java的強型別語言具有更高的穩定性。然而在單服務應用中只能互相權衡，選擇同一種語言，而當我們使用微服務結構後，這個問題就能夠引刃而解。我們將一個完整的系統拆分成了多個獨立的服務，從而每個服務都可以根據各自不同的特點，選擇最為合適的技術體系。

當然，並不是所有的微服務系統都具備技術異構性，要實現技術異構性，必須保證所有服務都提供通用介面。我們知道，在微服務系統中，服務之間採用RPC介面通訊，而實現RPC通訊的方式有很多。有一些RPC通訊方式與語言強耦合，如Java的RMI技術，它就要求通訊的雙方都必須採用Java語言開發。當然，也有一些RPC通訊方式與語言無關，如基於HTTP協議的REST。這種通訊方式對通訊雙方所採用的語言沒有做任何限制，只要通訊過程中傳輸的資料遵循REST規範即可。當然，與語言無關也就意味著通訊雙方沒有型別檢查，從而會提高出錯的概率。所以，究竟選擇與語言無關的RPC通訊方式，還是選擇與語言強耦合的RPC通訊方式，需要我們根據實際的業務場景合理地分析。

2. 資料庫的服務化切分

2.1 什麼是“分庫分表”？

隨著大資料時代的到來，業務系統的資料量日益增大，資料儲存能力逐漸成為影響系統效能的瓶頸。目前主流的關係型資料庫單表儲存上限為1000萬條記錄，而這一儲存能力顯然已經無法滿足大資料背景下的業務系統儲存要求了。隨著微服務架構、分散式儲存等概念的出現，資料儲存問題也漸漸迎來了轉機。而資料分片是目前解決海量資料持久化儲存與高效查詢的一種重要手段。資料分庫分表的過程在系統設計階段完成，要求系統設計人員根據系統預期的業務量，將未來可能出現瓶頸的資料庫、資料表按照一定規則拆分成多個庫、多張表。這些資料庫和資料表需要部署在不同的伺服器上，從而將資料讀寫壓力分攤至叢集中的各個節點，提升資料庫整體處理能力，避免出現讀寫瓶頸的現象。

目前資料分片的方式一共有兩種：離散分片和連續分片。

離散分片是按照資料的某一欄位雜湊取模後進行分片儲存。只要雜湊演算法選擇得當，資料就會均勻地分佈在不同的分片中，從而將讀寫壓力平均分配給所有分片，整體上提升資料的讀寫能力。然而，離散儲存要求資料之間有較強的獨立性，但實際業務系統並非如此，不同分片之間的資料往往存在一定的關聯性，因此在某些場景下需要跨分片連線查詢。由於目前所有的關係型資料庫出於安全性考慮，均不支援跨庫連線。因此，跨庫操作需要由資料分庫分表中介軟體來完成，這極大影響資料的查詢效率。此外，當資料儲存能力出現瓶頸需要擴容時，離散分片規則需要將所有資料重新進行雜湊取模運算，這無疑成為限制系統可擴充套件性的一個重要因素。雖然，一致性雜湊能在一定程度上減少系統擴容時的資料遷移，但資料遷移問題仍然不可避免。對於一個已經上線執行的系統而言，系統停止對外服務進行資料遷移的代價太大。

第二種資料分片的方式即為連續分片，它能解決系統擴容時產生的資料遷移問題。這種方式要求資料按照時間或連續自增主鍵連續儲存。從而一段時間內的資料或相鄰主鍵的資料會被儲存在同一個分片中。當需要增加分片時，不會影響現有的分片。因此，連續分片能解決擴容所帶來的資料遷移問題。但是，資料的儲存時間和讀寫頻率往往呈正比，也就是大量的讀寫往往都集中在最新儲存的那一部分資料，這就會導致熱點問題，並不能起到分攤讀寫壓力的初衷。

2.2 資料庫擴充套件的幾種方式

資料庫擴充套件一共有四種分配方式，分別是：垂直分庫、垂直分表、水平分表、水平資料分片。每一種策略都有各自的適用場景。

垂直分庫

垂直分庫即是將一個完整的資料庫根據業務功能拆分成多個獨立的資料庫，這些資料庫可以執行在不同的伺服器上，從而提升資料庫整體的資料讀寫效能。這種方式在微服務架構中非常常用。微服務架構的核心思想是將一個完整的應用按照業務功能拆分成多個可獨立執行的子系統，這些子系統稱為“微服務”，各個服務之間通過RPC介面通訊，這樣的結構使得系統耦合度更低、更易於擴充套件。垂直分庫的理念與微服務的理念不謀而合，可以將原本完整的資料按照微服務拆分系統的方式，拆分成多個獨立的資料庫，使得每個微服務系統都有各自獨立的資料庫，從而可以避免單個資料庫節點壓力過大，影響系統的整體效能，如下圖所示。
垂直分表

垂直分表如果一張表的欄位非常多，那麼很有可能會引起資料的跨頁儲存，這會造成資料庫額外的效能開銷，而垂直分表可以解決這個問題。垂直分表就是將一張表中不常用的欄位拆分到另一張表中，從而保證第一章表中的欄位較少，避免出現資料庫跨頁儲存的問題，從而提升查詢效率。而另一張表中的資料通過外來鍵與第一張表進行關聯，如下圖所示。
水平分表

如果一張表中的記錄數過多（超過1000萬條記錄），那麼會對資料庫的讀寫效能產生較大的影響，雖然此時仍然能夠正確地讀寫，但讀寫的速度已經到了業務無法忍受的地步，此時就需要使用水平分表來解決這個問題。水平分表是將一張含有很多記錄數的表水平切分，拆分成幾張結構相同的表。舉個例子，假設一張訂單表目前儲存了2000萬條訂單的資料，導致資料讀寫效率極低。此時可以採用水平分表的方式，將訂單表拆分成100張結構相同的訂單表，分別叫做order_1、order_2……、order_100。然後可以根據訂單所屬使用者的id進行雜湊取模後均勻地儲存在這100張表中，從而每張表中只儲存了20萬條訂單記錄，極大提升了訂單的讀寫效率，如下圖所示。當然，如果拆分出來的表都儲存在同一個資料庫節點上，那麼當請求量過大的時候，畢竟單臺伺服器的處理能力是有限的，資料庫仍然會成為系統的瓶頸，所以為了解決這個問題，就出現了水平資料分片的解決方案。
水平分庫分表

水平資料分片與資料分片區別在於：水平資料分片首先將資料表進行水平拆分，然後按照某一分片規則儲存在多臺資料庫伺服器上。從而將單庫的壓力分攤到了多庫上，從而避免因為資料庫硬體資源有限導致的資料庫效能瓶頸，如下圖所示。

2.3 分庫分表的幾種方式

目前常用的資料分片策略有兩種，分別是連續分片和離散分片。

離散分片

離散分片是指將資料打散之後均勻地儲存在邏輯表的各個分片中，從而使的對同一張邏輯表的資料讀取操作均勻地落在不同庫的不同表上，從而提高讀寫速度。離散分片一般以雜湊取模的方式實現。比如：一張邏輯表有4個分片，那麼在讀寫資料的時候，中介軟體首先會取得分片欄位的雜湊值，然後再模以4，從而計算出該條記錄所在的分片。在這種方法中，只要雜湊演算法選的好，那麼資料分片將會比較均勻，從而資料讀寫就會比較均勻地落在各個分片上，從而就有較高的讀寫效率。但是，這種方式也存在一個最大的缺陷——資料庫擴容成本較高。採用這種方式，如果需要再增加分片，原先的分片演算法將失效，並且所有記錄都需要重新計算所在分片的位置。對於一個已經上線的系統來說，行級別的資料遷移成本相當高，而且由於資料遷移期間系統仍在執行，仍有新資料產生，從而無法保證遷移過程資料的一致性。如果為了避免這個問題而停機遷移，那必然會對業務造成巨大影響。當然，如果為了避免資料遷移，在一開始的時候就分片較多的分片，那需要承擔較高的費用，這對於中小公司來說是無法承受的。
連續分片

連續分片指的是按照某一種分片規則，將某一個區間內的資料儲存在同一個分片上。比如按照時間分片，每個月生成一張物理表。那麼在讀寫資料時，直接根據當前時間就可以找到資料所在的分片。再比如可以按照記錄ID分片，這種分片方式要求ID需要連續遞增。由於Mysql資料庫單表支援最大的記錄數約為1000萬，因此我們可以根據記錄的ID，使得每個分片儲存1000萬條記錄，當目前的記錄數即將到達儲存上限時，我們只需增加分片即可，原有的資料無需遷移。連續分片的一個最大好處就是方便擴容，因為它不需要任何的資料遷移。但是，連續分片有個最大的缺點就是熱點問題。連續分片使得新插入的資料集中在同一個分片上，而往往新插入的資料讀寫頻率較高，因此，讀寫操作都會集中在最新的分片上，從而無法體現資料分片的優勢。

2.4 引入分庫分表中介軟體後面臨的問題

跨庫操作

在關係型資料庫中，多張表之間往往存在關聯，我們在開發過程中需要使用JOIN操作進行多表連線。但是當我們使用了分庫分表模式後，由於資料庫廠商處於安全考慮，不允許跨庫JOIN操作，從而如果需要連線的兩張表被分到不同的庫中後，就無法使用SQL提供的JOIN關鍵字來實現表連線，我們可能需要在業務系統層面，通過多次SQL查詢，完成資料的組裝和拼接。這一方面會增加業務系統的複雜度，另一方面會增加業務系統的負載。因此，當我們使用分庫分表模式時，需要根據具體的業務場景，合理地設定分片策略、設定分片欄位，這將會在本文的後續章節中介紹。
分散式事務

我們知道，資料庫提供了事務的功能，以保證資料一致性。然而，這種事務只是針對單資料庫而言的，資料庫廠商並未提供跨庫事務。因此，當我們使用了分庫分表之後，就需要我們在業務系統層面實現分散式事務。關於分散式事務的詳細內容，可以參考筆者的另一篇文章《常用的分散式事務解決方案》。

2.5 現有分庫分表中介軟體的橫向對比

Cobar實現資料庫的透明分庫，讓開發人員能夠在無感知的情況下操縱資料庫叢集，從而簡化資料庫的程式設計模型。然而Cobar僅實現了分庫功能，並未實現分表功能。分庫可以解決單庫IO、CPU、記憶體的瓶頸，但無法解決單表資料量過大的問題。此外，Cobar是一個獨立執行的系統，它處在應用系統與資料庫系統之間，因此增加了額外的部署複雜度，增加了運維成本。
為了解決上述問題，Cobar還推出了一個Cobar-Client專案，它只是一個安裝在應用程式的Jar包，並不是一個獨立執行的系統，一定程度上降低了系統的複雜度。但和Cobar一樣，仍然只支援分庫，並不支援分表，也不支援讀寫分離。
MyCat是基於Cobar二次開發的資料庫中介軟體，和Cobar相比，它增加了讀寫分離的功能，並修復了Cobar的一些bug。但是，MyCat和Cobar一樣，都是一套需要獨立部署的系統，因此會增加部署的複雜度，提高了後期系統運維的成本。

3. 微服務架構中的分散式事務

眾所周知，資料庫能實現本地事務，也就是在同一個資料庫中，你可以允許一組操作要麼全都正確執行，要麼全都不執行。這裡特別強調了本地事務，也就是目前的資料庫只能支援同一個資料庫中的事務。但現在的系統往往採用微服務架構，業務系統擁有獨立的資料庫，因此就出現了跨多個資料庫的事務需求，這種事務即為“分散式事務”。那麼在目前資料庫不支援跨庫事務的情況下，我們應該如何實現分散式事務呢？本文首先會為大家梳理分散式事務的基本概念和理論基礎，然後介紹幾種目前常用的分散式事務解決方案。廢話不多說，那就開始吧～

3.1 什麼是事務？

事務由一組操作構成，我們希望這組操作能夠全部正確執行，如果這一組操作中的任意一個步驟發生錯誤，那麼就需要回滾之前已經完成的操作。也就是同一個事務中的所有操作，要麼全都正確執行，要麼全都不要執行。

3.2 事務的四大特性 ACID

說到事務，就不得不提一下事務著名的四大特性。

原子性

原子性要求，事務是一個不可分割的執行單元，事務中的所有操作要麼全都執行，要麼全都不執行。
一致性

一致性要求，事務在開始前和結束後，資料庫的完整性約束沒有被破壞。
隔離性

事務的執行是相互獨立的，它們不會相互干擾，一個事務不會看到另一個正在執行過程中的事務的資料。
永續性

永續性要求，一個事務完成之後，事務的執行結果必須是持久化儲存的。即使資料庫發生崩潰，在資料庫恢復後事務提交的結果仍然不會丟失。

注意：事務只能保證資料庫的高可靠性，即資料庫本身發生問題後，事務提交後的資料仍然能恢復；而如果不是資料庫本身的故障，如硬碟損壞了，那麼事務提交的資料可能就丟失了。這屬於『高可用性』的範疇。因此，事務只能保證資料庫的『高可靠性』，而『高可用性』需要整個系統共同配合實現。

3.3 事務的隔離級別

這裡擴充套件一下，對事務的隔離性做一個詳細的解釋。

在事務的四大特性ACID中，要求的隔離性是一種嚴格意義上的隔離，也就是多個事務是序列執行的，彼此之間不會受到任何干擾。這確實能夠完全保證資料的安全性，但在實際業務系統中，這種方式效能不高。因此，資料庫定義了四種隔離級別，隔離級別和資料庫的效能是呈反比的，隔離級別越低，資料庫效能越高，而隔離級別越高，資料庫效能越差。

3.3.1 事務併發執行會出現的問題

我們先來看一下在不同的隔離級別下，資料庫可能會出現的問題：

更新丟失

當有兩個併發執行的事務，更新同一行資料，那麼有可能一個事務會把另一個事務的更新覆蓋掉。當資料庫沒有加任何鎖操作的情況下會發生。
髒讀

一個事務讀到另一個尚未提交的事務中的資料。該資料可能會被回滾從而失效。如果第一個事務拿著失效的資料去處理那就發生錯誤了。
不可重複讀

不可重複度的含義：一個事務對同一行資料讀了兩次，卻得到了不同的結果。它具體分為如下兩種情況：
- 虛讀：在事務1兩次讀取同一記錄的過程中，事務2對該記錄進行了修改，從而事務1第二次讀到了不一樣的記錄。
- 幻讀：事務1在兩次查詢的過程中，事務2對該表進行了插入、刪除操作，從而事務1第二次查詢的結果發生了變化。

不可重複讀與髒讀的區別？髒讀讀到的是尚未提交的資料，而不可重複讀讀到的是已經提交的資料，只不過在兩次讀的過程中資料被另一個事務改過了。

3.3.2 資料庫的四種隔離級別

資料庫一共有如下四種隔離級別：

Read uncommitted 讀未提交

在該級別下，一個事務對一行資料修改的過程中，不允許另一個事務對該行資料進行修改，但允許另一個事務對該行資料讀。因此本級別下，不會出現更新丟失，但會出現髒讀、不可重複讀。
Read committed 讀提交

在該級別下，未提交的寫事務不允許其他事務訪問該行，因此不會出現髒讀；但是讀取資料的事務允許其他事務的訪問該行資料，因此會出現不可重複讀的情況。
Repeatable read 重複讀

在該級別下，讀事務禁止寫事務，但允許讀事務，因此不會出現同一事務兩次讀到不同的資料的情況（不可重複讀），且寫事務禁止其他一切事務。
Serializable 序列化

該級別要求所有事務都必須序列執行，因此能避免一切因併發引起的問題，但效率很低。

隔離級別越高，越能保證資料的完整性和一致性，但是對併發效能的影響也越大。對於多數應用程式，可以優先考慮把資料庫系統的隔離級別設為Read Committed。它能夠避免髒讀取，而且具有較好的併發效能。儘管它會導致不可重複讀、幻讀和第二類丟失更新這些併發問題，在可能出現這類問題的個別場合，可以由應用程式採用悲觀鎖或樂觀鎖來控制。

3.4 什麼是分散式事務？

到此為止，所介紹的事務都是基於單資料庫的本地事務，目前的資料庫僅支援單庫事務，並不支援跨庫事務。而隨著微服務架構的普及，一個大型業務系統往往由若干個子系統構成，這些子系統又擁有各自獨立的資料庫。往往一個業務流程需要由多個子系統共同完成，而且這些操作可能需要在一個事務中完成。在微服務系統中，這些業務場景是普遍存在的。此時，我們就需要在資料庫之上通過某種手段，實現支援跨資料庫的事務支援，這也就是大家常說的“分散式事務”。

這裡舉一個分散式事務的典型例子——使用者下單過程。當我們的系統採用了微服務架構後，一個電商系統往往被拆分成如下幾個子系統：商品系統、訂單系統、支付系統、積分系統等。整個下單的過程如下：

使用者通過商品系統瀏覽商品，他看中了某一項商品，便點選下單
此時訂單系統會生成一條訂單
訂單建立成功後，支付系統提供支付功能
當支付完成後，由積分系統為該使用者增加積分

上述步驟2、3、4需要在一個事務中完成。對於傳統單體應用而言，實現事務非常簡單，只需將這三個步驟放在一個方法A中，再用Spring的@Transactional註解標識該方法即可。Spring通過資料庫的事務支援，保證這些步驟要麼全都執行完成，要麼全都不執行。但在這個微服務架構中，這三個步驟涉及三個系統，涉及三個資料庫，此時我們必須在資料庫和應用系統之間，通過某項黑科技，實現分散式事務的支援。

3.5 CAP理論

CAP理論說的是：在一個分散式系統中，最多隻能滿足C、A、P中的兩個需求。

CAP的含義：

C：Consistency 一致性

同一資料的多個副本是否實時相同。
A：Availability 可用性

可用性：一定時間內 & 系統返回一個明確的結果則稱為該系統可用。
P：Partition tolerance 分割槽容錯性

將同一服務分佈在多個系統中，從而保證某一個系統當機，仍然有其他系統提供相同的服務。

CAP理論告訴我們，在分散式系統中，C、A、P三個條件中我們最多隻能選擇兩個。那麼問題來了，究竟選擇哪兩個條件較為合適呢？

對於一個業務系統來說，可用性和分割槽容錯性是必須要滿足的兩個條件，並且這兩者是相輔相成的。業務系統之所以使用分散式系統，主要原因有兩個：

提升整體效能

當業務量猛增，單個伺服器已經無法滿足我們的業務需求的時候，就需要使用分散式系統，使用多個節點提供相同的功能，從而整體上提升系統的效能，這就是使用分散式系統的第一個原因。
實現分割槽容錯性

單一節點或多個節點處於相同的網路環境下，那麼會存在一定的風險，萬一該機房斷電、該地區發生自然災害，那麼業務系統就全面癱瘓了。為了防止這一問題，採用分散式系統，將多個子系統分佈在不同的地域、不同的機房中，從而保證系統高可用性。

這說明分割槽容錯性是分散式系統的根本，如果分割槽容錯性不能滿足，那使用分散式系統將失去意義。

此外，可用性對業務系統也尤為重要。在大談使用者體驗的今天，如果業務系統時常出現“系統異常”、響應時間過長等情況，這使得使用者對系統的好感度大打折扣，在網際網路行業競爭激烈的今天，相同領域的競爭者不甚列舉，系統的間歇性不可用會立馬導致使用者流向競爭對手。因此，我們只能通過犧牲一致性來換取系統的可用性和分割槽容錯性。這也就是下面要介紹的BASE理論。

3.6 BASE理論

CAP理論告訴我們一個悲慘但不得不接受的事實——我們只能在C、A、P中選擇兩個條件。而對於業務系統而言，我們往往選擇犧牲一致性來換取系統的可用性和分割槽容錯性。不過這裡要指出的是，所謂的“犧牲一致性”並不是完全放棄資料一致性，而是犧牲強一致性換取弱一致性。下面來介紹下BASE理論。

BA：Basic Available 基本可用
- 整個系統在某些不可抗力的情況下，仍然能夠保證“可用性”，即一定時間內仍然能夠返回一個明確的結果。只不過“基本可用”和“高可用”的區別是：
  - “一定時間”可以適當延長當舉行大促時，響應時間可以適當延長
  - 給部分使用者返回一個降級頁面給部分使用者直接返回一個降級頁面，從而緩解伺服器壓力。但要注意，返回降級頁面仍然是返回明確結果。
S：Soft State：柔性狀態同一資料的不同副本的狀態，可以不需要實時一致。
E：Eventual Consisstency：最終一致性同一資料的不同副本的狀態，可以不需要實時一致，但一定要保證經過一定時間後仍然是一致的。

3.7 酸鹼平衡

ACID能夠保證事務的強一致性，即資料是實時一致的。這在本地事務中是沒有問題的，在分散式事務中，強一致性會極大影響分散式系統的效能，因此分散式系統中遵循BASE理論即可。但分散式系統的不同業務場景對一致性的要求也不同。如交易場景下，就要求強一致性，此時就需要遵循ACID理論，而在註冊成功後傳送簡訊驗證碼等場景下，並不需要實時一致，因此遵循BASE理論即可。因此要根據具體業務場景，在ACID和BASE之間尋求平衡。

3.8 分散式事務協議

下面介紹幾種實現分散式事務的協議。

3.8.1 兩階段提交協議 2PC

分散式系統的一個難點是如何保證架構下多個節點在進行事務性操作的時候保持一致性。為實現這個目的，二階段提交演算法的成立基於以下假設：

該分散式系統中，存在一個節點作為協調者(Coordinator)，其他節點作為參與者(Cohorts)。且節點之間可以進行網路通訊。
所有節點都採用預寫式日誌，且日誌被寫入後即被保持在可靠的儲存裝置上，即使節點損壞不會導致日誌資料的消失。
所有節點不會永久性損壞，即使損壞後仍然可以恢復。

1. 第一階段（投票階段）：

協調者節點向所有參與者節點詢問是否可以執行提交操作(vote)，並開始等待各參與者節點的響應。
參與者節點執行詢問發起為止的所有事務操作，並將Undo資訊和Redo資訊寫入日誌。（注意：若成功這裡其實每個參與者已經執行了事務操作）
各參與者節點響應協調者節點發起的詢問。如果參與者節點的事務操作實際執行成功，則它返回一個"同意"訊息；如果參與者節點的事務操作實際執行失敗，則它返回一個"中止"訊息。

2. 第二階段（提交執行階段）：

當協調者節點從所有參與者節點獲得的相應訊息都為"同意"時：

協調者節點向所有參與者節點發出"正式提交(commit)"的請求。
參與者節點正式完成操作，並釋放在整個事務期間內佔用的資源。
參與者節點向協調者節點傳送"完成"訊息。
協調者節點受到所有參與者節點反饋的"完成"訊息後，完成事務。

如果任一參與者節點在第一階段返回的響應訊息為"中止"，或者協調者節點在第一階段的詢問超時之前無法獲取所有參與者節點的響應訊息時：

協調者節點向所有參與者節點發出"回滾操作(rollback)"的請求。
參與者節點利用之前寫入的Undo資訊執行回滾，並釋放在整個事務期間內佔用的資源。
參與者節點向協調者節點傳送"回滾完成"訊息。
協調者節點受到所有參與者節點反饋的"回滾完成"訊息後，取消事務。

不管最後結果如何，第二階段都會結束當前事務。

二階段提交看起來確實能夠提供原子性的操作，但是不幸的事，二階段提交還是有幾個缺點的：

執行過程中，所有參與節點都是事務阻塞型的。當參與者佔有公共資源時，其他第三方節點訪問公共資源不得不處於阻塞狀態。
參與者發生故障。協調者需要給每個參與者額外指定超時機制，超時後整個事務失敗。（沒有多少容錯機制）
協調者發生故障。參與者會一直阻塞下去。需要額外的備機進行容錯。（這個可以依賴後面要講的Paxos協議實現HA）
二階段無法解決的問題：協調者再發出commit訊息之後當機，而唯一接收到這條訊息的參與者同時也當機了。那麼即使協調者通過選舉協議產生了新的協調者，這條事務的狀態也是不確定的，沒人知道事務是否被已經提交。

為此，Dale Skeen和Michael Stonebraker在“A Formal Model of Crash Recovery in a Distributed System”中提出了三階段提交協議（3PC）。

3.8.2 三階段提交協議 3PC

與兩階段提交不同的是，三階段提交有兩個改動點。

引入超時機制。同時在協調者和參與者中都引入超時機制。
在第一階段和第二階段中插入一個準備階段。保證了在最後提交階段之前各參與節點的狀態是一致的。

也就是說，除了引入超時機制之外，3PC把2PC的準備階段再次一分為二，這樣三階段提交就有CanCommit、PreCommit、DoCommit三個階段。

1. CanCommit階段

3PC的CanCommit階段其實和2PC的準備階段很像。協調者向參與者傳送commit請求，參與者如果可以提交就返回Yes響應，否則返回No響應。

事務詢問

協調者向參與者傳送CanCommit請求。詢問是否可以執行事務提交操作。然後開始等待參與者的響應。
響應反饋

參與者接到CanCommit請求之後，正常情況下，如果其自身認為可以順利執行事務，則返回Yes響應，並進入預備狀態。否則反饋No

2. PreCommit階段

協調者根據參與者的反應情況來決定是否可以記性事務的PreCommit操作。根據響應情況，有以下兩種可能。假如協調者從所有的參與者獲得的反饋都是Yes響應，那麼就會執行事務的預執行。

傳送預提交請求

協調者向參與者傳送PreCommit請求，並進入Prepared階段。
事務預提交

參與者接收到PreCommit請求後，會執行事務操作，並將undo和redo資訊記錄到事務日誌中。
響應反饋

如果參與者成功的執行了事務操作，則返回ACK響應，同時開始等待最終指令。

假如有任何一個參與者向協調者傳送了No響應，或者等待超時之後，協調者都沒有接到參與者的響應，那麼就執行事務的中斷。

傳送中斷請求

協調者向所有參與者傳送abort請求。
中斷事務

參與者收到來自協調者的abort請求之後（或超時之後，仍未收到協調者的請求），執行事務的中斷。

3. doCommit階段 該階段進行真正的事務提交，也可以分為以下兩種情況。

該階段進行真正的事務提交，也可以分為以下兩種情況。

3.1 執行提交

傳送提交請求

協調接收到參與者傳送的ACK響應，那麼他將從預提交狀態進入到提交狀態。並向所有參與者傳送doCommit請求。
事務提交

參與者接收到doCommit請求之後，執行正式的事務提交。並在完成事務提交之後釋放所有事務資源。
響應反饋

事務提交完之後，向協調者傳送Ack響應。
完成事務

協調者接收到所有參與者的ack響應之後，完成事務。

3.2 中斷事務 協調者沒有接收到參與者傳送的ACK響應（可能是接受者傳送的不是ACK響應，也可能響應超時），那麼就會執行中斷事務。

傳送中斷請求

協調者向所有參與者傳送abort請求
事務回滾

參與者接收到abort請求之後，利用其在階段二記錄的undo資訊來執行事務的回滾操作，並在完成回滾之後釋放所有的事務資源。
反饋結果

參與者完成事務回滾之後，向協調者傳送ACK訊息
中斷事務

協調者接收到參與者反饋的ACK訊息之後，執行事務的中斷。

3.9 分散式事務的解決方案

分散式事務的解決方案有如下幾種：

全域性訊息
基於可靠訊息服務的分散式事務
TCC
最大努力通知

3.9.1 方案1：全域性事務（DTP模型）

全域性事務基於DTP模型實現。DTP是由X/Open組織提出的一種分散式事務模型——X/Open Distributed Transaction Processing Reference Model。它規定了要實現分散式事務，需要三種角色：

AP：Application 應用系統

它就是我們開發的業務系統，在我們開發的過程中，可以使用資源管理器提供的事務介面來實現分散式事務。
TM：Transaction Manager 事務管理器
- 分散式事務的實現由事務管理器來完成，它會提供分散式事務的操作介面供我們的業務系統呼叫。這些介面稱為TX介面。
- 事務管理器還管理著所有的資源管理器，通過它們提供的XA介面來同一排程這些資源管理器，以實現分散式事務。
- DTP只是一套實現分散式事務的規範，並沒有定義具體如何實現分散式事務，TM可以採用2PC、3PC、Paxos等協議實現分散式事務。
RM：Resource Manager 資源管理器
- 能夠提供資料服務的物件都可以是資源管理器，比如：資料庫、訊息中介軟體、快取等。大部分場景下，資料庫即為分散式事務中的資源管理器。
- 資源管理器能夠提供單資料庫的事務能力，它們通過XA介面，將本資料庫的提交、回滾等能力提供給事務管理器呼叫，以幫助事務管理器實現分散式的事務管理。
- XA是DTP模型定義的介面，用於向事務管理器提供該資源管理器(該資料庫)的提交、回滾等能力。
- DTP只是一套實現分散式事務的規範，RM具體的實現是由資料庫廠商來完成的。

有沒有基於DTP模型的分散式事務中介軟體？

DTP模型有啥優缺點？

3.9.2 方案2：基於可靠訊息服務的分散式事務

這種實現分散式事務的方式需要通過訊息中介軟體來實現。假設有A和B兩個系統，分別可以處理任務A和任務B。此時系統A中存在一個業務流程，需要將任務A和任務B在同一個事務中處理。下面來介紹基於訊息中介軟體來實現這種分散式事務。

在系統A處理任務A前，首先向訊息中介軟體傳送一條訊息
訊息中介軟體收到後將該條訊息持久化，但並不投遞。此時下游系統B仍然不知道該條訊息的存在。
訊息中介軟體持久化成功後，便向系統A返回一個確認應答；
系統A收到確認應答後，則可以開始處理任務A；
任務A處理完成後，向訊息中介軟體傳送Commit請求。該請求傳送完成後，對系統A而言，該事務的處理過程就結束了，此時它可以處理別的任務了。但commit訊息可能會在傳輸途中丟失，從而訊息中介軟體並不會向系統B投遞這條訊息，從而系統就會出現不一致性。這個問題由訊息中介軟體的事務回查機制完成，下文會介紹。
訊息中介軟體收到Commit指令後，便向系統B投遞該訊息，從而觸發任務B的執行；
當任務B執行完成後，系統B向訊息中介軟體返回一個確認應答，告訴訊息中介軟體該訊息已經成功消費，此時，這個分散式事務完成。

上述過程可以得出如下幾個結論：

訊息中介軟體扮演者分散式事務協調者的角色。
系統A完成任務A後，到任務B執行完成之間，會存在一定的時間差。在這個時間差內，整個系統處於資料不一致的狀態，但這短暫的不一致性是可以接受的，因為經過短暫的時間後，系統又可以保持資料一致性，滿足BASE理論。

上述過程中，如果任務A處理失敗，那麼需要進入回滾流程，如下圖所示：

若系統A在處理任務A時失敗，那麼就會向訊息中介軟體傳送Rollback請求。和傳送Commit請求一樣，系統A發完之後便可以認為回滾已經完成，它便可以去做其他的事情。
訊息中介軟體收到回滾請求後，直接將該訊息丟棄，而不投遞給系統B，從而不會觸發系統B的任務B。

此時系統又處於一致性狀態，因為任務A和任務B都沒有執行。

上面所介紹的Commit和Rollback都屬於理想情況，但在實際系統中，Commit和Rollback指令都有可能在傳輸途中丟失。那麼當出現這種情況的時候，訊息中介軟體是如何保證資料一致性呢？——答案就是超時詢問機制。

系統A除了實現正常的業務流程外，還需提供一個事務詢問的介面，供訊息中介軟體呼叫。當訊息中介軟體收到一條事務型訊息後便開始計時，如果到了超時時間也沒收到系統A發來的Commit或Rollback指令的話，就會主動呼叫系統A提供的事務詢問介面詢問該系統目前的狀態。該介面會返回三種結果：

提交

若獲得的狀態是“提交”，則將該訊息投遞給系統B。
回滾

若獲得的狀態是“回滾”，則直接將條訊息丟棄。
處理中

若獲得的狀態是“處理中”，則繼續等待。

訊息中介軟體的超時詢問機制能夠防止上游系統因在傳輸過程中丟失Commit/Rollback指令而導致的系統不一致情況，而且能降低上游系統的阻塞時間，上游系統只要發出Commit/Rollback指令後便可以處理其他任務，無需等待確認應答。而Commit/Rollback指令丟失的情況通過超時詢問機制來彌補，這樣大大降低上游系統的阻塞時間，提升系統的併發度。

下面來說一說訊息投遞過程的可靠性保證。當上遊系統執行完任務並向訊息中介軟體提交了Commit指令後，便可以處理其他任務了，此時它可以認為事務已經完成，接下來訊息中介軟體**一定會保證訊息被下游系統成功消費掉！**那麼這是怎麼做到的呢？這由訊息中介軟體的投遞流程來保證。

訊息中介軟體向下遊系統投遞完訊息後便進入阻塞等待狀態，下游系統便立即進行任務的處理，任務處理完成後便向訊息中介軟體返回應答。訊息中介軟體收到確認應答後便認為該事務處理完畢！

如果訊息在投遞過程中丟失，或訊息的確認應答在返回途中丟失，那麼訊息中介軟體在等待確認應答超時之後就會重新投遞，直到下游消費者返回消費成功響應為止。當然，一般訊息中介軟體可以設定訊息重試的次數和時間間隔，比如：當第一次投遞失敗後，每隔五分鐘重試一次，一共重試3次。如果重試3次之後仍然投遞失敗，那麼這條訊息就需要人工干預。

有的同學可能要問：訊息投遞失敗後為什麼不回滾訊息，而是不斷嘗試重新投遞？

這就涉及到整套分散式事務系統的實現成本問題。我們知道，當系統A將向訊息中介軟體傳送Commit指令後，它便去做別的事情了。如果此時訊息投遞失敗，需要回滾的話，就需要讓系統A事先提供回滾介面，這無疑增加了額外的開發成本，業務系統的複雜度也將提高。對於一個業務系統的設計目標是，在保證效能的前提下，最大限度地降低系統複雜度，從而能夠降低系統的運維成本。

不知大家是否發現，上游系統A向訊息中介軟體提交Commit/Rollback訊息採用的是非同步方式，也就是當上遊系統提交完訊息後便可以去做別的事情，接下來提交、回滾就完全交給訊息中介軟體來完成，並且完全信任訊息中介軟體，認為它一定能正確地完成事務的提交或回滾。然而，訊息中介軟體向下遊系統投遞訊息的過程是同步的。也就是訊息中介軟體將訊息投遞給下游系統後，它會阻塞等待，等下游系統成功處理完任務返回確認應答後才取消阻塞等待。為什麼這兩者在設計上是不一致的呢？

首先，上游系統和訊息中介軟體之間採用非同步通訊是為了提高系統併發度。業務系統直接和使用者打交道，使用者體驗尤為重要，因此這種非同步通訊方式能夠極大程度地降低使用者等待時間。此外，非同步通訊相對於同步通訊而言，沒有了長時間的阻塞等待，因此係統的併發性也大大增加。但非同步通訊可能會引起Commit/Rollback指令丟失的問題，這就由訊息中介軟體的超時詢問機制來彌補。

那麼，訊息中介軟體和下游系統之間為什麼要採用同步通訊呢？

非同步能提升系統效能，但隨之會增加系統複雜度；而同步雖然降低系統併發度，但實現成本較低。因此，在對併發度要求不是很高的情況下，或者伺服器資源較為充裕的情況下，我們可以選擇同步來降低系統的複雜度。我們知道，訊息中介軟體是一個獨立於業務系統的第三方中介軟體，它不和任何業務系統產生直接的耦合，它也不和使用者產生直接的關聯，它一般部署在獨立的伺服器叢集上，具有良好的可擴充套件性，所以不必太過於擔心它的效能，如果處理速度無法滿足我們的要求，可以增加機器來解決。而且，即使訊息中介軟體處理速度有一定的延遲那也是可以接受的，因為前面所介紹的BASE理論就告訴我們了，我們追求的是最終一致性，而非實時一致性，因此訊息中介軟體產生的時延導致事務短暫的不一致是可以接受的。

3.9.3 方案3：最大努力通知（定期校對）

最大努力通知也被稱為定期校對，其實在方案二中已經包含，這裡再單獨介紹，主要是為了知識體系的完整性。這種方案也需要訊息中介軟體的參與，其過程如下：

上游系統在完成任務後，向訊息中介軟體同步地傳送一條訊息，確保訊息中介軟體成功持久化這條訊息，然後上游系統可以去做別的事情了；
訊息中介軟體收到訊息後負責將該訊息同步投遞給相應的下游系統，並觸發下游系統的任務執行；
當下遊系統處理成功後，向訊息中介軟體反饋確認應答，訊息中介軟體便可以將該條訊息刪除，從而該事務完成。

上面是一個理想化的過程，但在實際場景中，往往會出現如下幾種意外情況：

訊息中介軟體向下遊系統投遞訊息失敗
上游系統向訊息中介軟體傳送訊息失敗

對於第一種情況，訊息中介軟體具有重試機制，我們可以在訊息中介軟體中設定訊息的重試次數和重試時間間隔，對於網路不穩定導致的訊息投遞失敗的情況，往往重試幾次後訊息便可以成功投遞，如果超過了重試的上限仍然投遞失敗，那麼訊息中介軟體不再投遞該訊息，而是記錄在失敗訊息表中，訊息中介軟體需要提供失敗訊息的查詢介面，下游系統會定期查詢失敗訊息，並將其消費，這就是所謂的“定期校對”。

如果重複投遞和定期校對都不能解決問題，往往是因為下游系統出現了嚴重的錯誤，此時就需要人工干預。

對於第二種情況，需要在上游系統中建立訊息重發機制。可以在上游系統建立一張本地訊息表，並將 任務處理過程 和 向本地訊息表中插入訊息 這兩個步驟放在一個本地事務中完成。如果向本地訊息表插入訊息失敗，那麼就會觸發回滾，之前的任務處理結果就會被取消。如果這量步都執行成功，那麼該本地事務就完成了。接下來會有一個專門的訊息傳送者不斷地傳送本地訊息表中的訊息，如果傳送失敗它會返回重試。當然，也要給訊息傳送者設定重試的上限，一般而言，達到重試上限仍然傳送失敗，那就意味著訊息中介軟體出現嚴重的問題，此時也只有人工干預才能解決問題。

對於不支援事務型訊息的訊息中介軟體，如果要實現分散式事務的話，就可以採用這種方式。它能夠通過重試機制+定期校對實現分散式事務，但相比於第二種方案，它達到資料一致性的週期較長，而且還需要在上游系統中實現訊息重試釋出機制，以確保訊息成功釋出給訊息中介軟體，這無疑增加了業務系統的開發成本，使得業務系統不夠純粹，並且這些額外的業務邏輯無疑會佔用業務系統的硬體資源，從而影響效能。

因此，儘量選擇支援事務型訊息的訊息中介軟體來實現分散式事務，如RocketMQ。

3.9.4 方案4：TCC（兩階段型、補償型）

TCC即為Try Confirm Cancel，它屬於補償型分散式事務。顧名思義，TCC實現分散式事務一共有三個步驟：

Try：嘗試待執行的業務
- 這個過程並未執行業務，只是完成所有業務的一致性檢查，並預留好執行所需的全部資源
Confirm：執行業務
- 這個過程真正開始執行業務，由於Try階段已經完成了一致性檢查，因此本過程直接執行，而不做任何檢查。並且在執行的過程中，會使用到Try階段預留的業務資源。
Cancel：取消執行的業務
- 若業務執行失敗，則進入Cancel階段，它會釋放所有佔用的業務資源，並回滾Confirm階段執行的操作。

下面以一個轉賬的例子來解釋下TCC實現分散式事務的過程。

假設使用者A用他的賬戶餘額給使用者B發一個100元的紅包，並且餘額系統和紅包系統是兩個獨立的系統。

Try
- 建立一條轉賬流水，並將流水的狀態設為交易中
- 將使用者A的賬戶中扣除100元（預留業務資源）
- Try成功之後，便進入Confirm階段
- Try過程發生任何異常，均進入Cancel階段
Confirm
- 向B使用者的紅包賬戶中增加100元
- 將流水的狀態設為交易已完成
- Confirm過程發生任何異常，均進入Cancel階段
- Confirm過程執行成功，則該事務結束
Cancel
- 將使用者A的賬戶增加100元
- 將流水的狀態設為交易失敗

在傳統事務機制中，業務邏輯的執行和事務的處理，是在不同的階段由不同的部件來完成的：業務邏輯部分訪問資源實現資料儲存，其處理是由業務系統負責；事務處理部分通過協調資源管理器以實現事務管理，其處理由事務管理器來負責。二者沒有太多互動的地方，所以，傳統事務管理器的事務處理邏輯，僅需要著眼於事務完成（commit/rollback）階段，而不必關注業務執行階段。

TCC全域性事務必須基於RM本地事務來實現全域性事務

TCC服務是由Try/Confirm/Cancel業務構成的，其Try/Confirm/Cancel業務在執行時，會訪問資源管理器（Resource Manager，下文簡稱RM）來存取資料。這些存取操作，必須要參與RM本地事務，以使其更改的資料要麼都commit，要麼都rollback。

這一點不難理解，考慮一下如下場景：

假設圖中的服務B沒有基於RM本地事務（以RDBS為例，可通過設定auto-commit為true來模擬），那麼一旦[B:Try]操作中途執行失敗，TCC事務框架後續決定回滾全域性事務時，該[B:Cancel]則需要判斷[B:Try]中哪些操作已經寫到DB、哪些操作還沒有寫到DB：假設[B:Try]業務有5個寫庫操作，[B:Cancel]業務則需要逐個判斷這5個操作是否生效，並將生效的操作執行反向操作。

不幸的是，由於[B:Cancel]業務也有n（0<=n<=5）個反向的寫庫操作，此時一旦[B:Cancel]也中途出錯，則後續的[B:Cancel]執行任務更加繁重。因為，相比第一次[B:Cancel]操作，後續的[B:Cancel]操作還需要判斷先前的[B:Cancel]操作的n（0<=n<=5）個寫庫中哪幾個已經執行、哪幾個還沒有執行，這就涉及到了冪等性問題。而對冪等性的保障，又很可能還需要涉及額外的寫庫操作，該寫庫操作又會因為沒有RM本地事務的支援而存在類似問題。。。可想而知，如果不基於RM本地事務，TCC事務框架是無法有效的管理TCC全域性事務的。

反之，基於RM本地事務的TCC事務，這種情況則會很容易處理：[B:Try]操作中途執行失敗，TCC事務框架將其參與RM本地事務直接rollback即可。後續TCC事務框架決定回滾全域性事務時，在知道“[B:Try]操作涉及的RM本地事務已經rollback”的情況下，根本無需執行[B:Cancel]操作。

換句話說，基於RM本地事務實現TCC事務框架時，一個TCC型服務的cancel業務要麼執行，要麼不執行，不需要考慮部分執行的情況。

TCC事務框架應該提供Confirm/Cancel服務的冪等性保障

一般認為，服務的冪等性，是指標對同一個服務的多次(n>1)請求和對它的單次(n=1)請求，二者具有相同的副作用。

在TCC事務模型中，Confirm/Cancel業務可能會被重複呼叫，其原因很多。比如，全域性事務在提交/回滾時會呼叫各TCC服務的Confirm/Cancel業務邏輯。執行這些Confirm/Cancel業務時，可能會出現如網路中斷的故障而使得全域性事務不能完成。因此，故障恢復機制後續仍然會重新提交/回滾這些未完成的全域性事務，這樣就會再次呼叫參與該全域性事務的各TCC服務的Confirm/Cancel業務邏輯。

既然Confirm/Cancel業務可能會被多次呼叫，就需要保障其冪等性。那麼，應該由TCC事務框架來提供冪等性保障？還是應該由業務系統自行來保障冪等性呢？個人認為，應該是由TCC事務框架來提供冪等性保障。如果僅僅只是極個別服務存在這個問題的話，那麼由業務系統來負責也是可以的；然而，這是一類公共問題，毫無疑問，所有TCC服務的Confirm/Cancel業務存在冪等性問題。TCC服務的公共問題應該由TCC事務框架來解決；而且，考慮一下由業務系統來負責冪等性需要考慮的問題，就會發現，這無疑增大了業務系統的複雜度。

4. 服務部署

當我們完成業務程式碼的開發後，就需要進入部署階段。在部署過程中，我們將會引入持續整合、持續交付、持續部署，並且闡述如何在微服務中使用他們。

4.1 持續整合、持續部署、持續交付

在介紹這三個概念之前，我們首先來了解下使用了這三個概念之後的軟體開發流程，如下圖所示：

首先是程式碼的開發階段，當程式碼完成開發後需要提交至程式碼倉庫，此時需要對程式碼進行編譯、打包，打包後的產物被稱為“構建物”，如：對Web專案打包之後生成的war包、jar包就是一種構建物。此時的構建物雖然沒有語法錯誤，但其質量是無法保證的，必須經過一系列嚴格的測試之後才能具有部署到生產環境的資格。我們一般會給系統分配多套環境，如開發環境、測試環境、預發環境、生產環境。每套環境都有它測試標準，當構建物完成了一套環境的測試，並達到交付標準時，就會自動進入下一個環境。構建物依次會經過這四套環境，構建物每完成一套環境的驗證，就具備交付給下一套環境的資格。當完成預發環境的驗證後，就具備的上線的資格。

測試和交付過程是相互伴隨的，每一套環境都有各自的測試標準。如在開發環境中，當程式碼提交後需要通過編譯、打包生成構建物，在編譯的過程中會對程式碼進行單元測試，如果有任何測試用例沒通過，整個構建流程就會被中止。此時開發人員需要立即修復問題，並重新提交程式碼、重新編譯打包。

當單元測試通過之後，構建物就具備了進入測試環境的資格，此時它會被自動部署到測試環境，進行新一輪的測試。在測試環境中，一般需要完成介面測試和人工測試。介面測試由自動化指令碼完成，這個過程完成後還需要人工進行功能性測試。人工測試完成後，需要手動觸發進入下一個階段。

此時構建物將會被部署到預發環境。預發環境是一種“類生產環境”，它和生產環境的伺服器配置需要保持高度一致。在預發環境中，一般需要對構建物進行效能測試，瞭解其效能指標是否能滿足上線的要求。當通過預發驗證後，構建物已經具備了上線的資格，此時它可以隨時上線。

上述過程涵蓋了持續整合、持續交付、持續部署，那麼下面我們就從理論角度來介紹這三個概念。

4.1.1 持續整合

“整合”指的是修改後/新增的程式碼向程式碼倉庫合併的過程，而“持續整合”指的是程式碼高頻率合併。這樣有什麼好處呢？大家不妨想一想，如果我們整合程式碼的頻率變高了，那麼每次整合的程式碼量就會變少，由於每次整合的時候都會進行單元測試，從而當出現問題的時候問題出現的範圍就被縮小的，這樣就能快速定位到出錯的地方，尋找問題就更容易了。此外，頻繁整合能夠使問題儘早地暴露，這樣解決問題的成本也就越低。因為在軟體測試中有這樣一條定律，時間和bug修復的成本成正比，也就是時間越長，bug修復的成本也就越大。所以持續整合能夠儘早發現問題，並能夠及時修復問題，這對於軟體的質量是非常重要的。

4.1.2 持續部署

“持續部署”指的是當存在多套環境時，當構建物成完上一套環境的測試後，自動部署到下一套環境並進行一系列的測試，直到構建物滿足上線的要求為止。

4.1.3 持續交付

當系統通過了所有的測試之後，就具備了部署到生產環境的資格，這個過程也就被稱為“交付”。“持續交付”指的是每個版本的構建物都具有上線的資格，這就要求每當程式碼庫中有新的版本後，都需要自動觸發構建、測試、部署、交付等一系列流程，當構建物在某個階段的測試未通過時，就需要開發人員立即解決這個問題，並重新構建，從而保證每個版本的構建物都具備上線的資格，可以隨時部署到生產環境中。

4.2 微服務與持續整合

當我們瞭解了持續整合後，下面來介紹微服務如何與持續整合相整合。當我們對系統進行了微服務化後，原本單一的系統被拆分成多個課獨立執行的微服務。單服務系統的持續整合較為簡單，程式碼庫、構建和構建物之間都是一對一的關係。然而，當我們將系統微服務化後，持續整合就變得複雜了。下面介紹兩種在微服務中使用持續整合的方法，分別是單庫多構建和多庫多構建，並依次介紹這兩種方式的優缺點及使用場景。

4.2.1 單庫多構建

“單庫”指的是單個程式碼倉庫，即整個系統的多個模組的程式碼均由一個程式碼倉庫維護。“多構建”指的是持續整合平臺中的構建專案會有多個，每個構建都會生成一個構建物，如下如所示：

在這種持續整合的模式中，整個專案的所有程式碼均在同一個程式碼倉庫中維護。但在持續整合平臺中，每一項服務都有各自獨立的構建，從而持續整合平臺能夠為每一項服務產出各自的構建物。

這種持續整合的模式在微服務架構中顯然是不合理的。首先，一個系統的可能會有很多服務構成，如果將這些服務的程式碼均在同一個程式碼倉庫中維護，那麼一個程式設計師在開發服務A程式碼的時候很有可能會因為疏忽，修改了服務B的程式碼，此時服務B構建之後就會存在安全隱患，如果這個問題在服務B上線前被發現，那麼還好，但無疑增加了額外的工作量；但如果這個問題及其隱諱，導致之前的測試用例沒有覆蓋到，從而服務B會帶著這個問題進入生產環境，這可能會給企業帶來巨大的損失。所以，在微服務架構中，儘量選擇多庫多構建模式來實現持續整合，它將帶來更大的安全性。

雖然這種模式不合理，但它也有存在的必要性，當我們在專案建設初期的時候，這種模式會給我們帶來更多的便利性。因為專案在建設初期，服務之間的邊界往往是比較模糊的，而且需要經過一段時間的演化才能夠構建出穩定的邊界。所以如果在專案建設初期直接使用微服務架構，那麼服務邊界頻繁地調整會極大增加系統開發的複雜度，你要知道，在多個系統之間調整邊界比在單個系統的多個模組之間調整邊界的成本要高很多。所以在專案建設初期，我們可以使用單服務結構，服務內部採用模組作為未來各個微服務的邊界，當系統演化出較為清晰、穩定的邊界後再將系統拆分成多個微服務。此時程式碼在同一個程式碼倉庫中維護是合理的，這也符合敏捷開發中快速迭代的理念。

4.2.2 多庫多構建

當系我們的系統擁有了穩定、清晰的邊界後，就可以將系統向微服務架構演進。與此同時，持續整合模式也可以從單庫多構建向多庫多構建演進。

在多庫多構建模式中，每項服務都有各自獨立的程式碼倉庫，程式碼倉庫之間互不干擾。開發團隊只需關注屬於自己的某幾項服務的程式碼倉庫即可。每一項服務都有各自獨立的構建。這種方式邏輯清晰，維護成本較低，而且能避免單庫多構建模式中出現的影響其他服務的問題。

4.3 微服務構建物

持續整合平臺對原始碼編譯、大包後生成的產物稱為“構建物”。根據打包的粒度不同，可以將構建物分為如下三種：平臺構建物、作業系統構建物和映象構建物。

4.3.1 平臺構建物

平臺構建物指的是由某一特定平臺生成的構建物，比如JVM平臺生成的Jar包、War包，Python生成的egg等都屬於平臺構建物。但平臺構建物執行需要部署在特定的容器中，如war需要執行在Servlet容器中，而Servlet容器又依賴的JVM環境。所以若要部署平臺構建物，則需要先給它們提供好執行所需的環境。

4.3.2 作業系統構建物

作業系統構建物是將系統打包成一個作業系統可執行程式，，如CentOS的RPM包、Windows的MSI包等。這些安裝包可以在作業系統上直接安裝執行。但和平臺構建物相同的是，作業系統構建物往往也需要依賴於其他環境，所以也需要在部署之前搭建好安裝包所需的依賴。此外，配置作業系統構建物的複雜度較大，構建的成本較高，所以一般不使用這種方式，這裡僅作介紹。

4.3.3 映象構建物

平臺構建物和作業系統構建物都有一個共同的缺點就是需要安裝構建物執行的額外依賴，增加部署複雜度，而映象構建物能很好地解決這個問題。

我們可以把映象理解成一個小型作業系統，這個作業系統中包含了系統執行所需的所有依賴，並將系統也部署在這個“作業系統”中。這樣當持續整合平臺構建完這個映象後，就可以直接執行它，無需任何依賴的安裝，從而極大簡化了構建的複雜度。但是，映象往往比較龐大，構建映象的過程也較長，從而當我們將生成的映象從持續整合伺服器釋出到部署伺服器的時間將會很長，這無疑降低了部署的效率。不過好在Docker的出現解決了這一問題。持續整合平臺在構建過程中並不需要生成一個映象，而只需生成一個映象的Dockerfile檔案即可。Dockerfile檔案用命令定義了映象所包含的內容，以及映象建立的過程。從而持續整合伺服器只需將這個體積較小的映象檔案釋出到部署伺服器上即可。然後部署伺服器會通過docker build命令基於這個Dockerfile檔案建立映象，並建立該映象的容器，從而完成服務的部署。

相對於平臺構建物和作業系統構建物而言，映象構建物在部署時不需要安裝額外的環境依賴，它把環境依賴的配置都在持續整合平臺構建Dockerfile檔案時完成，從而簡化了部署的過程。