微服務架構的前世今生
單體架構
在傳統IT行業的軟體系統設計大多都是各種獨立子系統的堆砌，這也就是所說的單體架構，其本身擴展性差，可靠性低，維護成本高。單體架構在初期系統規模比較小的情況下尚且能夠較好的支撐，但是隨著系統規模的擴大，它暴露出來的問題也越來越多，主要有以下幾點：
- 複雜性逐漸變高，問題修復和新功能開發難度和成本高，引入新問題的可能性變大。同時，任意模塊的缺陷都可能會影響整個系統，可靠性低。
- 隨著人員流動，加之複雜性高，新的問題很難被發現和解決，久而久之，問題逐漸變多，變難、變大，技術債務逐漸上升。
- 隨著模塊不斷集成，部署速度逐漸變慢
- 想進行整體的技術創新基本不可能，阻礙技術創新
- 垂直和水平的可擴展性差
SOA架構
隨後，引入了SOA服務化（面向服務的架構，它將應用程式的不同功能單元（服務）進行拆分，並通過這些服務之間定義良好的接口和契約聯繫起來)。但是，由於 SOA 早期均使用了ESB總線模式，這種總線模式與某種技術棧是強綁定的，如，J2EE。這又使得很多企業的遺留系統很難對接，切換時間太長，對接成本太高，新系統穩定性的收斂也需要一些時間。最終 SOA 看起來很美，但卻成為了企業級奢侈品，中小公司都望而生畏。
SOA服務化思想下的微服務架構
微服務是在 SOA 上做的升華，微服務最早由Martin Fowler與James Lewis於2014年共同提出，微服務架構風格是一種使用一套小服務來開發單個應用的方式途徑，每個服務運行在自己的進程中，並使用輕量級機制通信，通常是HTTP Rest API的方式（告別ESB服務總線），這些服務基於業務能力構建，並能夠通過自動化部署機制來獨立部署，這些服務使用不同的程式語言實現，以及不同數據存儲技術，並保持最低限度的集中式管理。
簡單講，微服務不再強調傳統SOA架構裡面比較重的ESB服務總線，同時將SOA的思想延伸到單個業務系統內部實現真正的組件化。微服務架構強調的一個重點是「業務需要徹底的組件化和服務化」。
從微服務的概念可以看出它有如下好處：
- 每個服務可以獨立開發，易於開發，提高開發人員的生產效率
- 局部修改容易部署
- 技術棧不受限
- 單個服務支持獨立部署和發布，可以進行快速疊代部署，更快的交付時間
- 更有利於業務的擴展，可伸縮性強
不斷演進的分層測試
冰淇淋測試模型
模型的特點如下
- 單元測試投入很少
- 較少的服務接口測試投入
- 測試的主要投入在UI測試
在這種模型下，一般測試介入較晚，大量測試集中在集成測試階段開展UI測試。持續集成的可行性較低，往往以手工測試為主，測試周期相對較長。
同時，在這種模型下的UI自動化測試，往往自動化測試開發、維護成本較高，但適當的UI自動化測試是有必要的。
由於大部分測試實在集成階段開展，問題修復的成本較高，難以覆蓋代碼或接口級別的異常，容易造成一定的漏測，同時修復問題引入新問題的可能性也較高。
幾乎大多數團隊都使用過冰淇淋模型，但隨著類敏捷、DevOps開發模式的應用發展，現在已逐漸退出歷史舞台。
金字塔測試模型
對於單體架構而言，金字塔測試模型是一個比較理想的模型。
模型特點如下：
- 測試的主要投入在單元測試
- 有一定的服務接口測試投入
- UI測試投入很少
金字塔測試模型的優勢不言而喻，不過由於該模型對測試人員的開發能力要求很高，同時單元測試意味著要維護大量的代碼級單測用例，其成本往往無法被測試人員接受，然而對研發人員而言，考慮到開發進度等因素，似乎變得更不可接受，因此這種模式往往難以應用。
不過測試金字塔模式，讓測試人員對服務接口測試引起了注意，使得大家認識到接口測試的對質量保障、測試效率的作用，接口自動化測試逐漸興起，與UI自動化測試並駕齊驅。
橄欖球測試模型
對於微服務架構而言，橄欖球測試模型是非常理想的模型。
模型特點如下：
- 單元測試投入相對較少
- 測試的主要投入在服務接口測試
- UI測試投入相對較少
橄欖球測試模型提倡高度的接口自動化，對測試人員的代碼能力有一定要求。能夠提前介入測試，而無需等開發工作全部完成。微服務之間的溝通交流本就是通過各種HTTP Rest API 接口實現，所以接口可以說是微服務架構系統的核心，橄欖球模型正是把核心放在了接口測試上面。
由於單元測試用例在金字塔測試模型中的體現效果並不是很好，加之需要額外的測試技術棧，大家對單元測試的理解、掌握不一，因此橄欖球測試模型弱化了單元測試投入。
UI測試由於測試介入的時間較晚以及開發、維護、擴展成本較高，因此所以這裡也相對弱化UI。
同時，基於微服務架構特點，服務間的依賴、連通性我們可以借鑑契約測試的思想。
契約測試其實是為了測試服務間連接或者接口間調用的正確性，為了驗證生產者提供者的服務功能是否真正的滿足了消費者的需求。有點測試前移的意思，把原本要通過集成測試才能驗證的內容前移到了單元測試、接口測試階段，實現了更輕量、高效的服務驗證。
契約測試
契約測試 ，又稱之為 消費者驅動的契約測試(Consumer-Driven Contracts，簡稱CDC)，根據 消費者驅動契約 ，我們可以將服務分為消費者端和生產者端，而消費者驅動的契約測試的核心思想在於是從消費者業務實現的角度出發，由消費者自己會定義需要的數據格式以及交互細節，並驅動生成一份契約文件。然後生產者根據契約文件來實現自己的邏輯，並在持續集成環境中持續驗證。
契約測試解決能解決什麼問題？
- 通過使用契約測試，接口調用雙方基於契約就可以並行開發，同時使得消費者和生產者之間測試解耦，通過契約作為共同遵守的中間標準，驗證生產者提供的內容是否滿足消費者的期望，不再需要等到客戶端和服務端聯調才能發現問題，聯調的成本可以減低到幾乎為零。
- 作為消費者驅動的方式，數據契約也是由消費者來決定的，消費者需要什麼數據，生產者就給什麼樣的數據，驗證生產者提供的數據是否是消費者所需要的。
- 測試前移，將本來需要在集成測試中體現的問題前移，及早的發現問題。