傳統(tǒng)的應(yīng)用結(jié)構(gòu)通常是單體應(yīng)用输虱。有統(tǒng)一的數(shù)據(jù)庫(kù)、UI層脂凶、控制層和邏輯層宪睹，雖然有分模塊愁茁，但是在代碼層面都是聚集在一起的。如果是一個(gè)簡(jiǎn)單應(yīng)用亭病，這不是什么問(wèn)題鹅很，但是隨著業(yè)務(wù)越來(lái)越復(fù)雜，應(yīng)用也變得越來(lái)越復(fù)雜罪帖、逐漸變成一頭大“怪獸”促煮，維護(hù)和后續(xù)開(kāi)發(fā)變得越來(lái)越困難，牽一發(fā)則動(dòng)全身整袁。交付周期越來(lái)越長(zhǎng)菠齿，交付風(fēng)險(xiǎn)越來(lái)越高，應(yīng)用本身也變得越來(lái)越難理解坐昙，新人對(duì)它的學(xué)習(xí)周期也會(huì)非常長(zhǎng)绳匀。
在這個(gè)背景下， 微服務(wù)架構(gòu)應(yīng)用而生炸客。如同我在前一篇學(xué)習(xí)筆記中記錄的：微服務(wù)不是被發(fā)明出來(lái)的疾棵，而是從現(xiàn)實(shí)世界中總結(jié)出來(lái)的一種趨勢(shì)。
微服務(wù)架構(gòu)就是把整個(gè)應(yīng)用按照業(yè)務(wù)拆分成獨(dú)立的應(yīng)用嚷量。它具備如下特征：
每個(gè)應(yīng)用可獨(dú)立開(kāi)發(fā)陋桂、部署和擴(kuò)容，甚至有獨(dú)立的數(shù)據(jù)庫(kù)蝶溶；
每個(gè)應(yīng)用的職責(zé)單一嗜历、松耦合，和其他應(yīng)用通過(guò)遠(yuǎn)程接口調(diào)用抖所，沒(méi)有代碼依賴(lài)梨州；
每個(gè)應(yīng)用的開(kāi)發(fā)、查錯(cuò)和變更速度快（基于以上原因）田轧，它能更快地響應(yīng)業(yè)務(wù)需求暴匠，提高敏捷性；
由于采取去中心化架構(gòu)，每個(gè)應(yīng)用可以采取完全不同的技術(shù)棧以及不同的開(kāi)發(fā)語(yǔ)言，在技術(shù)選型上自由度大茶行。
這個(gè)世界上是沒(méi)有“銀彈”的采郎。微服務(wù)架構(gòu)降低了每個(gè)微服務(wù)應(yīng)用的復(fù)雜性，卻增加了整個(gè)架構(gòu)的復(fù)雜性倍靡。其實(shí)只要業(yè)務(wù)是復(fù)雜的，系統(tǒng)的整體復(fù)雜度就不會(huì)降低，只是體現(xiàn)在不同的層面上而已瀑志。微服務(wù)架構(gòu)大大增加了集成測(cè)試、部署、監(jiān)控等方面的復(fù)雜性劈猪。所幸諸如契約測(cè)試昧甘、容器和Spring Cloud框架等技術(shù)的出現(xiàn)大大降低了解決這些問(wèn)題的難度。
所謂的契約測(cè)試是基于消費(fèi)者驅(qū)動(dòng)契約測(cè)試的理念的战得、API之間的集成測(cè)試充边，涉及彼此獨(dú)立的不同系統(tǒng)和依賴(lài)，相當(dāng)復(fù)雜和昂貴常侦，會(huì)大大拖慢交付進(jìn)度痛黎。API存在提供者和消費(fèi)者兩個(gè)角色。提供API的一方稱(chēng)為提供者刮吧，調(diào)用API的一方稱(chēng)為消費(fèi)者湖饱。在開(kāi)發(fā)時(shí)，雙方根據(jù)消費(fèi)者的驗(yàn)收條件擬定一份契約杀捻，契約放在一個(gè)雙方都可以訪問(wèn)的公共區(qū)域井厌，雙方通過(guò)運(yùn)行這份契約來(lái)測(cè)試彼此是否滿(mǎn)足要求。這個(gè)手段可以使雙方的開(kāi)發(fā)過(guò)程解耦致讥，解除測(cè)試的依賴(lài)關(guān)系仅仆，而且實(shí)現(xiàn)像單元測(cè)試那樣得快速和穩(wěn)定。目前有Pact和Spring Cloud Contrac兩個(gè)框架支持契約測(cè)試垢袱。在微服務(wù)架構(gòu)下墓拜，應(yīng)用之間都是通過(guò)Restful API互相調(diào)用，契約測(cè)試解決了微服務(wù)集成測(cè)試難的問(wèn)題请契。
