微服務(wù)規(guī)范資料

微服務(wù)規(guī)范

關(guān)于微服務(wù)........................................................................4

概念和定義....................................................................4

組件與服務(wù)....................................................................5

去中心化和集中架構(gòu)...........................................................6

環(huán)繞業(yè)務(wù)功能進彳拉且織.........................................................7

產(chǎn)品不是項目？...............................................................7

強化終端及弱化通道..........................................................7

分散窗里......................................................................8

分散數(shù)據(jù)宮里.................................................................8

基礎(chǔ)設(shè)施自動化..............................................................8

容5骷設(shè)計....................................................................8

t研改進......................................................................9

其它..........................................................................9

湖艮務(wù)與SOA...........................................................9

多語言，多選擇.........................................................10

實踐標(biāo)準(zhǔn)和強制標(biāo)準(zhǔn).....................................................10

原則............................................................................10

Availability：標(biāo)準(zhǔn)的目標(biāo)................................................10

Production-Readiness標(biāo)準(zhǔn)...............................................11

Stability..............................................................11

Reliability..........................................................11

Scalability...........................................................12

FaultTolerance......................................................12

Catastrophepreparedness.............................................12

Performance..........................................................13

Monitoring............................................................13

Documentation........................................................13

服務(wù)化架構(gòu)的演進歷史..........................................................14

歷史......................................................................14

MVC...................................................................14

RPC...................................................................14

SOA...................................................................14

微服務(wù)架構(gòu)...........................................................14

微服務(wù)架構(gòu)的開辟原則.....................................................15

微服務(wù)架構(gòu)的測試原則.....................................................16

微服務(wù)架構(gòu)的部署原則.....................................................17

微服務(wù)架構(gòu)的管理原則.....................................................17

微服務(wù)的接口原則.........................................................18

特征.........................................................................18

服務(wù)的業(yè)務(wù)要素必須惟一并不具有歧義......................................18

服務(wù)必須在空間和時間上具有惟一性和穩(wěn)定性...............................19

服務(wù)需要具備多態(tài)性.......................................................19

實踐.........................................................................19

微服務(wù)的粒度..............................................................19

微服務(wù)系統(tǒng)多大............................................................20

微服務(wù)規(guī)劃與設(shè)計..........................................................20

人員角色的變化............................................................20

挑戰(zhàn).........................................................................21

I礴........................................................................22

“輕量化”解決方案.....................................................22

安全性問題.............................................................23

系統(tǒng)間耦合問題.........................................................23

系統(tǒng)可靠性問題.........................................................23

全局事務(wù)一致性問題.....................................................23

異構(gòu)系統(tǒng)問題...........................................................25

組織需求與架構(gòu)選擇.........................................................25

微服務(wù)是未來嗎..............................................................26

附錄............................................................................26

關(guān)于微服務(wù)

概念和定義

簡單來說，服務(wù)的本質(zhì)就是行為(業(yè)務(wù)活動)的抽象。

對于SOA,推進結(jié)構(gòu)化信息標(biāo)準(zhǔn)組織(OASIS)和開放團體(OpenGroup)均給出了正式定

義。

OASIS將SOA定義為：

AparadigmfororganizingandutilizingdistributedcapabiIitiesthatmaybeunder

thecontrolofdifferentownershipdomains.Itprovidesauniformmeanstooffer,

discover,interactwithandusecapabiIitiestoproducedesiredeffectsconsistent

withmeasurabIepreconditionsandexpectations.

OpenGroup將SOA定義為：

Service-OrientedArchitecture(SOA)isanarchitecturaIstyIethatsupports

service-orientation.Service-orientationisawayofthinkingintermsofservices

andservice-baseddevelopmentandtheoutcomesofservices.

Aservice:

Isalogicalrepresentationofarepeatablebusinessactivitythat

hasaspecifiedoutcome.,checkcustomercredit,provideweatherdata,

consolidatedrillingreports)

IsseIf-containedMaybecomposedofotherservices

Isa“blackbox“toconsumersoftheservice

業(yè)界基本的認知是，SOA是一種架構(gòu)模式，是一種面向服務(wù)的思維方式。對于服務(wù)的定義，

OpenGroup認為服務(wù)是一種可重復(fù)的業(yè)務(wù)活動的邏輯上的描述，是一種自包含的、可組合

的“黑盒子”。

微服務(wù)在服務(wù)定義上，與傳統(tǒng)的S0A差別不大，在實現(xiàn)上強調(diào)應(yīng)用的顆粒度足夠小，固然小

到什么程度也是爭論的一個話題。在我看來，微服務(wù)“微”的并非服務(wù)，其實微的是應(yīng)用

（后面我們會談到，服務(wù)的顆粒度是和需求相關(guān)的，是不能隨意變大變小的）。

組件與服務(wù)

組件是指軟件中獨立的單元，它能獨立替代和獨立更新。

微服務(wù)架構(gòu)也使用組件庫，但是它把軟件拆分成服務(wù)，并認為這是主要的組織形式。

我們把組件庫定義為程序中相互關(guān)系、并使用內(nèi)存中調(diào)用的組件，把服務(wù)定義為進程間使用

如Web請求服務(wù)或者遠程調(diào)用來相互通信的組件。（這種定義的方式與其它面向?qū)ο蟪绦蛑?/p>

服務(wù)對象的概念是不一樣的。）

把服務(wù)當(dāng)成組件（而不是組件庫）一個主要的原因是服務(wù)可以獨立的部署“如果你的應(yīng)用由

多個組件庫組成并跑在一個進程中，那末任何組件的變更都將導(dǎo)致整體應(yīng)用的重新發(fā)布。但

是如果由許多服務(wù)構(gòu)成的應(yīng)用，你可以想像的到每一個服務(wù)的變更僅需要發(fā)布相應(yīng)的服務(wù)。

當(dāng)然，這也不是絕對的，比如導(dǎo)致服務(wù)接口的變更的更新就需要相應(yīng)服務(wù)的變化，但優(yōu)秀

微服務(wù)構(gòu)架，會盡量避免這種服務(wù)間的耦合并完善服務(wù)的交互接口。

把服務(wù)當(dāng)成組件的另一個考慮是這將擁有更新清晰的接口。許多開辟語言并沒有良好的定義

公共接口的機制。通常惟獨文檔和規(guī)范說明，讓用戶避免組件間會導(dǎo)致組件耦合的過度的依

賴。無非服務(wù)由是是通過明確的遠程接口調(diào)用，這個問題就很容易解決了。

使用服務(wù)也有它的不足之處。遠程調(diào)用比進制內(nèi)部調(diào)用更消耗性能，而且遠程的API比較粗

糙，難以使用。如果由于對組件的職責(zé)進行變更，影響到跨進程間的交互，那末這操作起來

也比較艱難。

第一個可能的特性，我們看到每一個服務(wù)是運行在獨立的進程上的。注意，這只是第一個可

能的特性。服務(wù)也可以由多個進程組成，它們是同時開辟和部署的，例如服務(wù)可能用到一

個應(yīng)用進制和一種數(shù)據(jù)稟。

去中心化和集中架構(gòu)

SOA發(fā)展過程中既有無中心架構(gòu)，也有集中架構(gòu)，前者用于互聯(lián)網(wǎng)企業(yè)間的交互，后者在企

業(yè)內(nèi)部使用。

切當(dāng)?shù)闹vSOA沒有“去中心化”架構(gòu)，惟獨“無中心化”架構(gòu)。

架構(gòu)是為了實現(xiàn)特定的目標(biāo)的，而這目標(biāo)源于需求和現(xiàn)實，那末”無中心化”架構(gòu)就是SOA

在互聯(lián)網(wǎng)環(huán)境下的必然的架構(gòu)選擇。其實也沒得可選，因為SOA要解決企業(yè)間的通過互聯(lián)網(wǎng)

相互訪問的需求，而互聯(lián)網(wǎng)是一個自由的無政府環(huán)境，根本就不存在一個共同認可的架構(gòu)中

心節(jié)點。兩者對照如下：

去（無）中心集中

組織形態(tài)無政府有政府

組織能力不可能建立中心節(jié)點可以建立中心節(jié)點

協(xié)議約束必須統(tǒng)一協(xié)議可以不統(tǒng)一協(xié)議（成本低）

安全策略必須統(tǒng)一安全策略安全策略多樣化

管控能力無法做到統(tǒng)一管控組織需要并可以做到統(tǒng)一管控

其實無論是去中心還是集中架構(gòu)，都是組織需要而非技術(shù)需要，需求決定技術(shù)架構(gòu)。在企業(yè)

內(nèi)部，無論任何架構(gòu)都要滿足組織對管控的需求，而這種需求必須由一個統(tǒng)一的中心節(jié)點來

提供，所以SOA化在組織內(nèi)部大多數(shù)是以ESB作為基礎(chǔ)來實現(xiàn)的。

環(huán)繞業(yè)務(wù)功能進行組織

微服務(wù)更傾向于環(huán)繞業(yè)務(wù)功能對服務(wù)結(jié)構(gòu)進行劃分、拆解。

這樣的服務(wù)，是針對業(yè)務(wù)領(lǐng)域有著關(guān)完整實現(xiàn)的軟件，它包含使用接口、持久存儲、以及對

旬的交互。因此團隊?wèi)?yīng)該是跨職能的，包含完整的開辟技術(shù)：用戶體驗、數(shù)據(jù)庫、以及項目

管理。

大型的整體型應(yīng)用也可以按照業(yè)務(wù)功能進行模塊化的，盡管這種例子不常見。固然，我們敦

促一個大型的團隊將一個構(gòu)建成整體型的應(yīng)用依照業(yè)務(wù)功能進行拆分。我們能看到主要問題

在于，這種組件形式會導(dǎo)致不少的上下文依賴。如果在大量的模塊邊界上都存在這種大量的

調(diào)用，對于團隊的每一個成員來說，短期內(nèi)是很難記住的。此外，我們發(fā)現(xiàn)模塊化方式需要

大量的規(guī)范去強制執(zhí)行，固然，大量明確的拆分也讓服務(wù)組件在團隊的邊界中更加清晰。

產(chǎn)品不是項目？

開辟組應(yīng)該負責(zé)產(chǎn)品的整個生命周期。

一個常見的證明是：Amazon的“你編譯，你運維(youbuiId,yourunit)M的理念，它

要求開辟團隊對軟件產(chǎn)品的整個生命周期負責(zé)。這要求開辟者每天都關(guān)注軟件產(chǎn)品的運行情

況，并與用戶聯(lián)系的更密切，同時承擔(dān)一些售后支持。

強化終端及弱化通道

微服務(wù)傾向于做如下的選擇：強化終端及弱化通道。微服務(wù)的應(yīng)用致力松耦合和高內(nèi)聚：采

用單獨的業(yè)務(wù)邏輯，表現(xiàn)的更像經(jīng)典Unix意義上的過濾器一樣，接受請求、處理業(yè)務(wù)邏輯、

返回響應(yīng)。它們更喜歡簡單的REST風(fēng)格，而不是復(fù)雜的協(xié)議，如WS或者BPEL或者集中式

框架。

分散管理

集中管理的一種好處是在單一平臺上進行標(biāo)準(zhǔn)化。經(jīng)瞼表明這種趨勢的好處在縮小，因為并

不是所有的問題都相同，而且解決方案并非萬能的。我們更加傾向于采用適當(dāng)?shù)墓ぞ呓鉀Q

適當(dāng)?shù)膯栴}，整體式的應(yīng)用在一定程度上比多語言環(huán)境更有優(yōu)勢，但也適合所有的情況。

也許分散管理普及于亞馬遜“編譯它，運維它”的理念。團隊為他們開辟的軟件負全部責(zé)任，

也包含7*24小時的運行。全責(zé)任的方式并不常見，但是我們確實發(fā)現(xiàn)越來越多的公司在他

們的團隊中所推廣。

分散數(shù)據(jù)管理

當(dāng)對概念模式下決心進行分散管理時，微服務(wù)也決定著分散數(shù)據(jù)管理。當(dāng)整體式的應(yīng)用使用

單一邏輯數(shù)據(jù)庫對數(shù)據(jù)持久化時，企業(yè)通常選擇在應(yīng)用的范圍內(nèi)使用一個數(shù)據(jù)庫，這些決定

也受廠商的商業(yè)權(quán)限模式驅(qū)動。微服務(wù)讓每一個服務(wù)管理自己的數(shù)據(jù)庫：無論是相同數(shù)據(jù)庫

的不同實例，或者是不同的數(shù)據(jù)庫系統(tǒng)。這種方法叫PoIygIotPersistenceo你可以把

這種方法用在整體架構(gòu)中，但是它更常見于微服務(wù)架構(gòu)中。

微服務(wù)音分散數(shù)據(jù)現(xiàn)任意味著管理數(shù)據(jù)更新。處理數(shù)據(jù)更新的常用方法是使用事務(wù)來保證不

同的資源修改數(shù)據(jù)庫的一致性。這種方法通常在整體架閡中使用。

基礎(chǔ)設(shè)施自動化

我們發(fā)現(xiàn)使用微服務(wù)的團隊更加依賴于基礎(chǔ)設(shè)施的自動化。

容錯性設(shè)計

使用服務(wù)作為組件的一個結(jié)果在于應(yīng)用需要有能容忍服務(wù)的故障的設(shè)計。

任務(wù)服務(wù)可能因為供應(yīng)商的不可靠而故障，客戶端需要盡可能的優(yōu)化這種場景的響應(yīng)。跟整

體構(gòu)架相比，這是一個缺點，因為它帶來的額外的復(fù)雜性。這將讓微服務(wù)團隊時刻的想到服

務(wù)故障的情況下用戶的體驗。

由于服務(wù)可以隨時故障，快速故障檢測，乃至，自動恢復(fù)變更非常重要。微服務(wù)應(yīng)用把實時

的監(jiān)控放在應(yīng)用的各個階段中，檢測構(gòu)架元素（每秒數(shù)據(jù)庫的接收的請求數(shù)）和業(yè)務(wù)相關(guān)的

指標(biāo)（把分鐘接收的定單數(shù)）O監(jiān)控系統(tǒng)可以提供一種早期故障告警系統(tǒng)，讓開辟團隊跟進

并調(diào)查。

設(shè)計改進

微服務(wù)實踐者，通常有不斷改進設(shè)計的背景，他們把服務(wù)分解成進一步的工具。這些工具可

以讓應(yīng)用開辟者在不改變速度情況下，控制都他們的應(yīng)用的需求變更。變更控制不意味首減

少變更，而是使用適當(dāng)?shù)姆绞胶凸ぞ?，讓它更加頻繁，至少，很好讓它變得可控。

不論如何，當(dāng)你試圖軟件系統(tǒng)拆分成組件時，你將面臨著如何拆分的問題。那末我們的決定

拆分我們應(yīng)用的原則是什么呢首要的因素，組件可以被獨立替換和更新的，這意味著我們尋

找的關(guān)鍵在于，我們要想象著重寫一個組件而不影響它們之前的協(xié)作關(guān)系。事實上，許多的

微服務(wù)小組給它進一步的預(yù)期：服務(wù)應(yīng)該能夠報廢的，而不是要長久的發(fā)展的。

其它

微服務(wù)與SOA

常時候我們談的所謂“SOA”時，它與我們談?wù)摰娘L(fēng)格不一至，因為它通常是指在整體風(fēng)格

應(yīng)用中的ESBo

我們發(fā)現(xiàn)面向服務(wù)的風(fēng)格是這么的拙劣：從試圖使用ESB隱藏復(fù)雜性，到使用多年才認識

到發(fā)費數(shù)百美元卻沒產(chǎn)生任務(wù)價值這樣的失敗，到集中管理模式抑制變更。而且這些問題往

往很難發(fā)現(xiàn)。

多語言，多選擇

整體構(gòu)架通常意味著使用單一的語言，這也限制著使用技術(shù)的數(shù)量。

實踐標(biāo)準(zhǔn)和強制標(biāo)準(zhǔn)

微服務(wù)團隊傾向于避免這種通常由企業(yè)架構(gòu)隊伍定制的僵硬的強制標(biāo)準(zhǔn)，但是它們卻非常樂

于甚至推廣這些開放的標(biāo)準(zhǔn)，如HTTP、ATOM、其它微規(guī)范。

原則

AvaiIabiIity：標(biāo)準(zhǔn)的目標(biāo)

衡量微服務(wù)是否成功的一個最通用的方法就是可用性(Availability)

計算可用性的指標(biāo)也很簡單：

uptime(正常服務(wù)時間)、downtime(宕機時間)、以及總運行時間(uptime+downtime)。

盡管可用性指標(biāo)很實用，但是它并非衡量微服務(wù)的一個標(biāo)準(zhǔn)，而是這些標(biāo)準(zhǔn)要達到的目標(biāo)。

之所以不是一個標(biāo)準(zhǔn)法則，是因為它不能指導(dǎo)我們?nèi)绾伍_辟微服務(wù)。

計算可用性普通使用幾個9來表示。

99%:允許宕機的時間為天/年

%：允許宕機的時間為小時/年

%：允許宕機的時間為分鐘/年

%：允許宕機的時間為分鐘/年

Production-Readiness標(biāo)準(zhǔn)

Production-Readiness暗地里隱含的含義是：產(chǎn)品或者服務(wù)值得信賴，它們可以滿足產(chǎn)交

互。

們需要準(zhǔn)確的衡量。標(biāo)準(zhǔn)化如果沒有可操作的原則也是沒故意義的，作者提出了衡量服務(wù)是

否是產(chǎn)品級的八個原則：？

stability?、?reliabiIityv?scalabiIity?x?fauIt-toIerance?>?catastrophe-prepar

edness?>?performance?x

monitoring?v?document2tion?,它們一起為微服務(wù)提供了高可用性，但是單一的原則并不

能保證微服務(wù)的可用性。

StabiIity

微服務(wù)架構(gòu)的采用為開辟者提供了很大的自由度，他們可以每天增加和發(fā)布新特性，修改

bug,用新技術(shù)代替舊技術(shù)，可以重寫或者棄用過時的微服務(wù)。

一個穩(wěn)定的微服務(wù)應(yīng)該是這樣子的：它的開辟、發(fā)布、新技術(shù)/新特性的增加、Bug的修改、

服務(wù)的住手使用以及服務(wù)的棄用都不應(yīng)該影響大的微服務(wù)生態(tài)系統(tǒng)的穩(wěn)定性。

為了避免開辟過程、發(fā)布過程、更改住手棄用時浮現(xiàn)問題，我們需要在每一個過程子細考慮,

執(zhí)行到位，不會影響其它服務(wù)。

Reliability

穩(wěn)定性并非惟一影響微服務(wù)可用性的因素，微服務(wù)必須保障可靠性(Reliability)。一個

可靠的微服務(wù)值得它的client所信任，以及它的依賴和整個生態(tài)圈。

穩(wěn)定性和解決微服務(wù)的改變帶來的副作用相關(guān)，而可靠性是和信任相關(guān)，這兩個原則密不可

分。每一個穩(wěn)定性的需求都帶來可靠性的需求。

在路由routing和服務(wù)發(fā)現(xiàn)的處理中，為了保證可靠性，healthcheck應(yīng)該是準(zhǔn)確的，

request和response應(yīng)該送達、錯誤處理應(yīng)該子細的被處理。

SeaIabiIity

微服務(wù)的業(yè)務(wù)處理很少是恒定的，成功的微服務(wù)總能平穩(wěn)地處理業(yè)務(wù)量的增大。不能規(guī)模擴

展的微服務(wù)在業(yè)務(wù)量增大的情況下會增加服務(wù)的延遲、低可用性，極限情況下還可能導(dǎo)致意

外事故或者停機。

一個可擴展的微服務(wù)可以同時對付大量的任務(wù)或者請求。

可擴展的微服務(wù)應(yīng)該能應(yīng)對驀地爆發(fā)的請求，比如秒殺，防止服務(wù)整體垮掉

從整個微服務(wù)系統(tǒng)考慮可擴展性，當(dāng)服務(wù)業(yè)務(wù)量超過它的預(yù)期的時候應(yīng)該報警。服務(wù)擴展的

時候也會要求它的依賴能滿足擴展的需求。

微服務(wù)的數(shù)據(jù)存儲也必須滿足可規(guī)模擴展。

FaultTolerance

每一個微服務(wù)都應(yīng)該是容錯的和提供災(zāi)備。

容錯和災(zāi)備的微服務(wù)應(yīng)該能夠承受內(nèi)部錯誤和外部錯誤。內(nèi)部錯誤可能是微服務(wù)自己導(dǎo)致，

例如內(nèi)部代碼的導(dǎo)致的未捕獲的錯誤，外部錯誤可能是數(shù)據(jù)中心的停電、錯誤的配置等。

Catastrophepreparedness

災(zāi)備

Performance

scalabiIity談?wù)摰氖欠?wù)能處理多少請求(howmany),而性能performance談?wù)摰氖俏?/p>

服務(wù)處理這些請求的性能(howwell)o

一個高性能的微服務(wù)處理處理請求很快，任務(wù)處理很高效，正確地使用資源。

Monitoring

另一個保障微服務(wù)可用性的原則就是正確的服務(wù)監(jiān)控。好的監(jiān)控要包括三大組件：

1.所有重要的正確的日志和相關(guān)信息

2.使用圖形化的顯示(dashboard)

3.關(guān)鍵指標(biāo)的告警

所有關(guān)鍵的監(jiān)控指標(biāo)，比如硬件的使用率、數(shù)據(jù)庫的連接、響應(yīng)時間、API的狀態(tài)等，應(yīng)該

圖形化的顯示，可以直觀的觀察到服務(wù)的狀態(tài)。

告警信息應(yīng)該傳達給負責(zé)的工程師，為監(jiān)控指標(biāo)設(shè)置合適的閾值.

告警信息應(yīng)該實用，并且可以處理，通常會有對應(yīng)的處理文檔。

Documentation

微服務(wù)的架構(gòu)會帶來技術(shù)債，減少它的辦法就是文檔。

最好的文檔包含微服務(wù)的所有的基礎(chǔ)知識：架構(gòu)圖、入手和開辟手冊、請求流的細節(jié)、API、

告警的運維手冊等。

服務(wù)化架構(gòu)的演進歷史

歷史

MVC

RPC

RPC需要解決模塊之間跨進程通信的問題，不同的團隊開辟不同的模塊，通過一個RPC框架

實現(xiàn)遠程調(diào)用，RPC框架幫業(yè)務(wù)把通信細節(jié)給屏蔽掉，但是RPC框架也有自身的缺點。

RPC本身不負責(zé)服務(wù)化，例如：服務(wù)的自動發(fā)現(xiàn)不管、服務(wù)的應(yīng)用和發(fā)布不管、服務(wù)的運維

和管理也不管。沒有透明化、服務(wù)化的能力，對整個應(yīng)用層的侵入還是比較深的。

SOA

SOA服務(wù)化架構(gòu)，企業(yè)級資產(chǎn)重用和異構(gòu)系統(tǒng)間的集成而接，SOA架構(gòu)的現(xiàn)狀：在傳統(tǒng)企業(yè)

IT領(lǐng)域，主要是解決異構(gòu)系統(tǒng)之間的互通和粗粒度的標(biāo)準(zhǔn)化(WebService)?；ヂ?lián)網(wǎng)領(lǐng)域，

提供一套高效支撐應(yīng)用快速開辟迭代的服務(wù)化架構(gòu)。例如各個互聯(lián)網(wǎng)公司自研或者開源的分

布式服務(wù)框架。

微服務(wù)架構(gòu)

微服務(wù)（MSA）是一種架構(gòu)風(fēng)格，旨在通過將功能分解到各個離散的服務(wù)中以實現(xiàn)對解決方

案的解耦。它有如下幾個特征：

小，且只干一件事情。

獨立部署和生命周期管理。

異構(gòu)性

輕量級通信，RPC或者RestfuL

微服務(wù)架構(gòu)的拆分原則

微服務(wù)架構(gòu)的實施過程中，首先遇到的最大的難題，就是它的拆分原則。

微服務(wù)拆分原則：環(huán)繞業(yè)務(wù)功能進行垂直和水平拆分。大小粒度是難點，也是團隊爭論的焦

點。

拆分原則：

功能完整性、職責(zé)單一性。

粒度適中，團隊可接受。

迭代演進，非一蹴而就。

API的版本兼容性優(yōu)先考慮。

微服務(wù)架構(gòu)的開辟原則

以前單體架構(gòu)的時候，大家需要什么，往往喜歡自己寫什么，這其實是沒有太嚴重的依賴問

題。但是到了微服務(wù)時代，微服務(wù)是一個團隊或者一個小組提供的，這個時候一定沒有辦法

在某一個時刻同時把所有的服務(wù)都提供出來，“需求實現(xiàn)滯后”是必然存在的。

一個好的實踐策略就是接口先行,語言中立，服務(wù)提供者和消鑄者解耦，并行開辟.捺升產(chǎn)

能。無論有多少個服務(wù)，首先需要把接口識別和定義出來，然后雙方基于接口進行契約驅(qū)動

開辟，利用Mock服務(wù)提供者和消費者，互相解耦，并行開辟，實現(xiàn)依賴解耦。

采用契約驅(qū)動開辟，如果需求不穩(wěn)定或者時常變化，就會面臨一個接口契約頻繁變更的問題。

對于服務(wù)提供者，不能因為耽心接口孌更而遲遲不對外提供接口，對于消費者要擁抱變更，

而不是抱怨和抵觸。要解決這個問題，一種比較好的實踐就是管理+技術(shù)雙管齊下：

允許接口變更，但是對變更的頻度要做嚴格管控。

提供全在線的API文檔服務(wù)（例如SwaggerUI）,將離線的API文檔轉(zhuǎn)成全在線、互

動式的API文檔服務(wù),

API變更的主動通知機制，要讓所有消費該API的消費者能夠及時感知到API的變更。

契約驅(qū)動測試，用于對兼容性做回歸測試。

微服務(wù)架構(gòu)的測試原則

微服務(wù)的測試包括單元測試、接口測試、集成測試和行為測試等，其中最重要的就是契約測

試：

用微服務(wù)框架提供的Mock機制，可以分別生成摹擬消費者的客戶端測試樁和提供者的服務(wù)

端測試樁，雙方可以基于Mock測試樁對微服務(wù)的接口契約進行測試，雙方都不需要等待對

方功能代碼開辟完成，實現(xiàn)了并行開辟和測試，提高了微服務(wù)的構(gòu)建效率?；诮涌诘钠跫s

測試還能快速的發(fā)現(xiàn)不兼容的接口變更，例如修改字段類型、刪除字段等。

微服務(wù)架構(gòu)的部署原則

微服務(wù)的部署原則：獨立部署和生命周期管理、基礎(chǔ)設(shè)施自動化。

需要有一套類似于CI/CD的流水線來做基礎(chǔ)設(shè)施自動化，具體可以參考Netflix開源的微服

務(wù)持續(xù)交付流水線Spinnaker：

微服務(wù)架構(gòu)的管理原則

微服務(wù)部署上線之后，最重要的工作就是服務(wù)管理。微服務(wù)管理原則：線上管理、實時動態(tài)

生效。

微服務(wù)常用的管理策略：

流量控制：動態(tài)、靜態(tài)流控制。

服務(wù)降級。

超M控制。

優(yōu)先級調(diào)度。

流量遷移。

調(diào)用鏈跟蹤和分析。

服務(wù)路由。

服務(wù)上線審批、下線通知。

SLA策略控制。

微服務(wù)的接口原則

微服務(wù)的接口兼容性原則：技術(shù)保障'管理協(xié)同。

制定并嚴格執(zhí)行《微服務(wù)前向兼容性規(guī)范》，避免發(fā)生不兼容修改或者私自修改不通知

周邊的情況。

接口兼容性技術(shù)保障：例如Thrift的IDL,支持新增、修改和刪除字段、字段定義位

置無關(guān)性，碼流支持亂序等。

持續(xù)交付流水線的每日構(gòu)建和契約化驅(qū)動測試，能夠快速識別和發(fā)現(xiàn)不兼容。

特征

服務(wù)的業(yè)務(wù)要素必須惟一并不具有歧義

通過引入服務(wù)元數(shù)據(jù)的概念來描述業(yè)務(wù)要素，服務(wù)元數(shù)據(jù)的引入是實現(xiàn)業(yè)務(wù)與技術(shù)分離的重

要手段。通過服務(wù)元數(shù)據(jù)的全局惟一性來保證業(yè)務(wù)要素的全局惟一性

元數(shù)據(jù)全局惟一，所以決定了要素一致的服務(wù)是相同的

服務(wù)必須在空間和時間上具有惟一性和穩(wěn)定性

服務(wù)要素元數(shù)據(jù)化后，元數(shù)據(jù)的時空惟一性就決定了服務(wù)在時空上也是惟一的。當(dāng)任意兩個

服務(wù)，如果其定義中引用的所有元數(shù)據(jù)集合徹底一致的時候，無論這兩個服務(wù)的結(jié)構(gòu)上有什

么差異，這兩個服務(wù)都是同一個服務(wù)。

服務(wù)的時空穩(wěn)定性是指，服務(wù)的一旦被嚴肅的定義出來，那末在任何使用環(huán)境中'任何時刻

其已經(jīng)明確的業(yè)務(wù)要素不會被改變，任何要素的改變意味著一個新的服務(wù)被定義。比如打球

含有兩個要素：人和球，無論在任何時間任何地點打球都需要這兩個要素；假設(shè)某個場景需

要去掉球這個要素，那末需要定義一個新的服務(wù)，這個服務(wù)可以惟獨人這個要素，但新的服

務(wù)可能就是打架了。

服務(wù)需要具備多態(tài)性

服務(wù)多態(tài)性是指，服務(wù)可以在運行時刻動態(tài)的轉(zhuǎn)變?yōu)榇送庖粋€服務(wù)的特性。

實踐

微服務(wù)的粒度

微服務(wù)拆分遵循了兩個緯度，一個是業(yè)務(wù)服務(wù)分級化、目前定為二級（0、1、2）,。級服

務(wù)為最核心，而越是核心

的業(yè)務(wù)拆分的職責(zé)越單一和正交化，實現(xiàn)功能的最小集，足夠的簡單單一對于確保穩(wěn)定、性

能和控制變更都有莫大益處，

邊際成本遞減效應(yīng)明顯。

微服務(wù)系統(tǒng)多大

被報導(dǎo)的最大團隊遵循亞馬遜TowPizaa團隊理念（比如，一個團隊吃兩個比薩就可以了。）,

這意味著不超過20號（一打）人。我們發(fā)現(xiàn)最小配置是半打的團隊支撐起一打的服務(wù)。

微服務(wù)規(guī)劃與設(shè)計

當(dāng)我們開始考慮到底需要拆除哪些服務(wù)時，與城市規(guī)劃有些類似。首先一個城市會化成幾個

大的片區(qū)，

每一個片區(qū)承擔(dān)著城市發(fā)展所需要不同功能職責(zé)（商業(yè)、居住、工業(yè)、科技等）。惟獨大

的片區(qū)劃分是不夠的，

僅僅完成為了頂層設(shè)計，微服務(wù)化的設(shè)計需進一步深入到這個片區(qū)到底是否需要安置一個“

購物中心”或者“學(xué)?！敝?，

微服務(wù)化設(shè)計完成后，每一個微服務(wù)的契約與主要職責(zé)就應(yīng)該像“購物中心”或者“學(xué)?！?/p>

這樣的描述那末明確了。

微服務(wù)功能職責(zé)僅僅是服務(wù)契約中的一部份，另一部份則是非功能規(guī)約。例如一個“購物

中心”的確定則隱含對

周圍的交通流量提出了要求，否則過于擁堵的交通壓力會影響“購物中心”功能的可用性。

因此當(dāng)設(shè)計一個微服務(wù)的契約時，我們需要描述清晰它提供的功能職責(zé)、承諾的響應(yīng)時間分

布、承載的最大流量（TPS）等設(shè)計要素。

人員角色的變化

按微服務(wù)拆分系統(tǒng)后，按照“服務(wù)即產(chǎn)品”的思路，人員角色將發(fā)生變化。

普通工程師從僅僅開辟功能到開辟、運營服務(wù)，工作性質(zhì)的轉(zhuǎn)變將帶來思路和關(guān)注點的變化。

每一個服務(wù)至少有一個工程師作為負責(zé)人，固然能力更強的人可能會負責(zé)更多的服務(wù)。

大量拆分的微服務(wù)帶來開辟人員交集的減少，對于大規(guī)模的團隊并行開辟好處明顯。

而服務(wù)負責(zé)制對個人能力要求更高，自驅(qū)動和自學(xué)習(xí)能力更強的人會得到更多的成長機會，

個人成長路線的發(fā)展也打開了空間。

這時團隊的構(gòu)成會變得類似NBA球隊的組成，工程師的角色類似球員，架構(gòu)師或者技術(shù)經(jīng)

理類似主教練，而部門經(jīng)理則是球隊經(jīng)理。

球員只管打好球，教練負責(zé)球員訓(xùn)練,培養(yǎng)與戰(zhàn)術(shù)安排，經(jīng)理則掌握著人事權(quán)，控制著球員

的薪水升遷，招聘到優(yōu)秀的球員。

挑戰(zhàn)

“除非有必要，我們不要創(chuàng)造新的概念”，這就是著名的奧卡姆剃刀定律“如無必要，勿

增實體”。

單體應(yīng)用的架構(gòu)(monolithic)

不少應(yīng)用的架構(gòu)都是在公司初創(chuàng)的時候設(shè)計的，所以那時候追求的是“糙快猛”。隨著公司

的發(fā)展，應(yīng)用需要擴大規(guī)模，增加更多的功能，這時候開辟人員會發(fā)現(xiàn)他們被應(yīng)用最初的架

構(gòu)所制約，比如語言的選擇、可用的庫、開辟工具、回歸測試工具等。對應(yīng)用的重構(gòu)都不得

不受限于初始架構(gòu)的制約。顯然，初始架構(gòu)的選擇決定了應(yīng)用的未來。

期望的服務(wù)：自由的語言、自由的數(shù)據(jù)庫、自由的開辟工具，他們是自己的王，自由的君主。

時常聽到的微服務(wù)設(shè)計的一個原則就是：一個微服務(wù)就二一件事情-只干一件事情一把一件事

情干好，用你所想建你所要，確保它們工作即可。

是不是太理想化了當(dāng)你擁有成百上千的微服務(wù)甚至上萬人微服務(wù)在運行的時候，它們之間必

須尢縫的交互，不應(yīng)該有質(zhì)量低下的服務(wù)影響整個微服務(wù)的整體，或者說影響產(chǎn)品的性能和

功能。如果要保證產(chǎn)品的整體性能和功能工作的非常好，就需要有一定的標(biāo)準(zhǔn)，它的每一個

部份也得遵循這樣的標(biāo)準(zhǔn)。

問題

其實，當(dāng)系統(tǒng)架構(gòu)演化為微服務(wù)架構(gòu)以后，系統(tǒng)所面臨的新問題變得和微服務(wù)解決掉的問題

幾乎一樣多：

“輕■化”解決方案

越來越多的人標(biāo)榜自己的東西是輕量級的，看來輕量級就是簡單甚至粗糙的代名詞。

傳統(tǒng)SOA架構(gòu)下，解決企業(yè)內(nèi)部系統(tǒng)間應(yīng)用交互問題主要的方式就是采用ESB進行連接。但

在微服務(wù)架構(gòu)下，由于ESB“過重”，會導(dǎo)致頻繁的系統(tǒng)間交互效率大大降低，所以微服務(wù)

架構(gòu)回歸了去中心化的點對點調(diào)用方式。但是系統(tǒng)拆分帶來的問題，是不是能簡單的用輕量

點對點通訊就能解決了呢

安全性問題

在“大”應(yīng)用拆分之前，應(yīng)用的安全性是整個大應(yīng)用統(tǒng)一考慮的，比如身份認證、權(quán)限、防

篡改、防抵賴、加密等等。

那末，是不是大服務(wù)拆成微服務(wù)之后，這些黑客就消失了呢這個想法顯然是無法接受的.事

實上被拆分后的微服務(wù)由于維護能力和專業(yè)能力不夠，使用技術(shù)雜亂等等原因，使得黑客更

容易得手。

一個不設(shè)防的微服務(wù)，對于內(nèi)部黑客來說，只要從瀏覽器摹擬一個服務(wù)請求，就可以輕松的

進行危（wei）險的操作。這種“輕量”我認為無異于掩耳盜鈴。

系統(tǒng)間耦合問題

“系統(tǒng)之間的耦合，從來沒有像今天一樣多”。對于微服務(wù)架構(gòu)而言，原本系統(tǒng)內(nèi)部對象之

間的交互行為，被簡單粗暴的暴露到系統(tǒng)之間來。

如果只是簡單的把系統(tǒng)拆開，那末原本存在于系統(tǒng)內(nèi)部的強耦合性會更加突出的表現(xiàn)出來，

這導(dǎo)致微服務(wù)的應(yīng)用開辟并不比傳統(tǒng)應(yīng)用更簡單，相反的還會引入諸如事務(wù)一致性等原來不

存在的問題。

系統(tǒng)可靠性問題

微服務(wù)架構(gòu)引入了一個新的可靠性問題

但是當(dāng)大服務(wù)被拆分成4個微應(yīng)用之后，如果業(yè)務(wù)X的人口在A系統(tǒng)，而出錯點在D系統(tǒng)，

由于各系統(tǒng)都是獨立的A并不知道D出了問題（即便知道也不知道怎么處理），對于管理者

來說簡單的隔離D可能是惟一能夠做到的，于是會造成一連串的連鎖反應(yīng)，而且系統(tǒng)間訪