微服務概述 1.1 易於擴展 1.2 部署簡單 1.3 技術異構性資料庫的服務化切分 2.1 什麼是“分庫分表”？ 2.2 資料庫擴展的幾種方式 2.3 分庫分表的幾種方式 2.4 引入分庫分表中間件後面臨的問題 2.5 現有分庫分表中間件的橫向對比微服務架構中的分散式事務 3.1 什麼是事務？ ...

微服務概述

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修複的成本也就越大。所以持續集成能夠儘早發現問題，並能夠及時修複問題，這對於軟體的質量是非常重要的

淺談“微服務”