第12章微服務化的測試平臺
最近幾年什麼架構模式最火爆？很多人會說是微服務，因為不少互聯網企業使用微服務架構創建了不少成功案例。微服務伴隨著各種新技術的誕生，也為測試本身提供了很大的挑戰。當然，測試平臺本身也在不斷進化，它也可以進化為基於微服務的平臺。
微服務架構的概念是，將功能分割成一個一個可以自治管理的模塊，模塊通過REST API或RPC對外提供服務，它隔離了功能模塊，極大地解耦了模塊之間的數據，並且可以通過負載均衡技術增加單個服務的性能，從而提高整個繫統的擴展能力。
在一些大型企業，自動化測試工具不再是每個部門自己的事情，而是會有專門的開發團隊提供自動化測試平臺的基本套件，比如某國際通信產品企業就有專門的團隊提供了基於Python的自動化測試平臺，並且提供了統一的部署和安裝方式，以及公共的代碼庫，方便不同團隊之間共享代碼，並且整個平臺是基於網絡運行的，測試者如果需要執行一個新的測試平臺，則隻需啟動一個新的Docker容器，然後在裡面執行測試用例。
在互聯網時代，各種大型產品不斷被開發，這對測試平臺本身的功能和性能也是極大的挑戰，可能傳統的基於網絡的共享自動化測試平臺也會因為單體架構而導致出現性能和維護上的問題。傳統的單體架構的最大問題是可用性低，大家肯定有所體會，即便是商業版本的一些缺陷管理工具或WIKI工具，也會時常出現問題導致無法訪問，並且伴隨著版本的升級，服務停止的時間增多。如果是共享的自動化測試平臺，這種服務停止狀態是無法被接受的，因為IT部門無法協調公司內所有部門的測試任務，這種無法提供服務的狀態會對一些部門的測試計劃產生極大的影響。
本章我們將探索性地討論和思考，對微服務化的自動化測試平臺進行一些初探，通過一些簡單的設計概念，逐漸將測試平臺向微服務轉化。
當然，本書不是介紹微服務及如何建立微服務的書，所以對於如何使用流行的微服務框架來建設微服務的基礎設施，不在本章的探討範圍之內，讀者可以自行查找一些書籍對微服務本身進行更深入的理解和學習。
通過本章你將基本了解：
· 什麼是微服務，以及為什麼要使用微服務架構。
· 如何將測試平臺轉化為微服務平臺。
12.1 軟件架構的演進
在講微服務架構的概念之前，我們先回顧一下軟件架構發展的歷史，了解一下各種架構模式的特點及痛點。這樣，我們可以更好地了解微服務產生的背景，以及所能解決的問題。
軟件從計算機誕生到現在，基本上經歷了如下幾個階段。
12.1.1 Monolith單體架構
在2.2.1節中，我們介紹了一些基本的Monolith架構的情況，下面來回顧一下，如圖2-1所示。
早期的軟件運行於單繫統中，功能比較單一，所有代碼都放在一個項目中，功能上沒有明確的邊界定義，可能會出現模塊之間直接進行函數調用的情況。這種情況當然在現代軟件設計中是完全不被允許的，這樣會破壞封裝性。不過在早期的軟件設計中，或者在現代軟件制作的PoC階段，這種從0到1的模式可以很快地將軟件的功能展現出來，並且方便調試。
傳統的單體架構中，所有功能都在一個服務內，功能模塊之間通過代碼級別的引用建立依賴關繫。
如果我們需要修改其中一個模塊的功能，就要考慮此模塊的依賴關繫，以防對其他功能產生影響。而且隨著功能越來越多，整個繫統會越來越龐大，最終發展到難以維護的地步。隨著業務的發展，繫統的訪問量增加，繫統性能和並發能力就會受到考驗。
單體架構的缺點主要體現在以下幾方面：
第一，擴展能力有限。比如我們在實現一個單體的管理繫統的時候，一開始用戶不多，進行的操作也不復雜，一臺計算機就能滿足其性能需求，但是隨著用戶增加，功能也越來越多，原來的計算機性能就不夠用了。此時我們就要通過對計算機進行升級來滿足其性能需求，但是到了後期，可能升級計算機硬件也無法進一步提升性能。
第二，有很強的耦合邏輯，修改繫統代碼要極其小心，我們經常會看到或聽到一些人說，某個組織的繫統，沒有人敢對代碼進行升級，因為誰都不知道，修改了這一塊代碼會影響多少其他代碼，其實這並不是笑話。
第三，繫統的升級非常麻煩。對於小型軟件，重新安裝就可以，但是大型的企業平臺，整個平臺下線就會有非常大的效率問題，這與高可用性是背道而馳的。並且一旦有一個問題需要被修復，整個項目就要被重新打包。
當然並不是說單體架構就一定不好，因為單體架構也在不斷發展，比如單體架構中的分層架構、前後端分離等，都是非常好的架構模式，甚至不管是分布式架構、SOA，還是微服務，都還有單體架構的思想在其中，甚至是這些方法的延續。
12.1.2 分布式架構和SOA
說到分布式我們不得不提SOA，Service-Oriented Architecture，其基本概念是通過代碼功能的分離，使得每個功能都可以作為一個服務單獨部署。並且服務和服務之間進行了充分的解耦，每個服務都有其明確的功能邊界，服務之間的相互調用則通過中立的契約來描述。
這樣，不同的服務可以由不同的平臺進行實現，比如對於需要高性能的服務可以使用C++來開發，而對於需要高速開發和快速功能迭代的，可以使用Python或Java。
分布式架構基於網絡的服務器架構集群，可以方便地進行流量負載均衡操作，並且當一個服務所部署的服務器出現性能瓶頸時，我們可以通過升級該服務器或者增加服務器集群來提升服務的性能。
12.1.3 微服務
其實微服務和SOA有類似之處，都是將模塊組件服務化，每個服務通過API對外提供特定的服務。但是微服務有其自身的特點，相較於SOA，它更加組件化，從而會生成更多的自治服務模塊。James Lewis和Martin Fowler對微服務架構的定義如下：
“微服務架構風格，簡單地說，是以實現一組微服務的方式來開發一個獨立的應用繫統的方法。其中每個小微服務都運行在自己的進程中，一般采用基於HTTP協議的資源 API這樣輕量的機制進行通信。
微服務圍繞業務功能進行構建，通過全自動化的方式進行獨立部署。可以使用不同的編程語言來編寫，也可以使用不同的數據存儲技術，並且進行最低限度的集中管理。也就是說，微服務的特點是每個服務需要運行在獨立的進程中，比如容器化的Docker，通過一繫列手段來進行管理。在服務崩潰的時候，可以通過重啟服務或分流將調用重定向到其他服務。
我們可以看到微服務所帶來的一些優點：
（1）微服務可以讓開發團隊分割成一個一個的小團隊（1 pizza team，一個pizza可以喂飽的人數的團隊），每個團隊負責自己微服務的開發，小團隊一般更便於管理，並具有更高的執行力。
（2）服務是高可用的，一個服務可以發起多個進程提供同樣的服務，並通過負載均衡算法決定調用哪個進程的服務，這樣在一個進程崩潰的時候，還有其他進程可以提供服務，從而不影響服務。
（3）橫向擴展能力強，一個服務如果遇到性能瓶頸，可以通過啟用更多的服務進程來達到提高並發的能力。
（4）灰度發布，微服務架構下的缺陷修復不再需要統一的版本控制，如果一個問題可以很簡單地修復，並且這個服務在繫統中運行了100個進程，那麼我們就可以先給10個進程做升級，然後看看實際運行過程中有沒有問題，即便產生了問題，也隻是影響了10%的流量，可以回退版本繼續修復。如果沒有問題我們可以再對另外90個進程作升級。這樣就可以對一些缺陷做到快速響應。
但是微服務也帶來了一些顯而易見的缺點：
（1）過於自治的服務導致聯調會產生巨大的溝通成本，特別是對於接口的定義如果頻繁變動，則會對繫統的整體功能影響比較大。
（2）數據一致性問題。在微服務的架構中，服務被拆成了一小塊一小塊，但是有些操作需要有事務的概念，在單體繫統中，我們可以通過事務鎖來解決數據的競爭，但是在微服務繫統中，由於服務不允許存在狀態，而一個事務包含多個微服務的調用又不可避免，所以就要花更多的力氣去解決數據一致性的問題。
（3）運維難度增加，在單體繫統或簡單的SOA繫統中，代碼集成和發布會比較容易。但是在微服務繫統中，一旦微服務展開太多，有些大型繫統甚至有成百上千的微服務需要部署，如何保證整個代碼集成（CI）到自動化部署（CD）也是一個巨大的挑戰。
但是無論如何，微服務依舊是大繫統中被證明有著相當潛力的架構模式。
