微服務(wù)架構(gòu)目前已經(jīng)越來越成為行業(yè)的熱門詞匯，它把一種特定的軟件應(yīng)用的設(shè)計(jì)方法描述為能夠獨(dú)立部署的服務(wù)的套件。盡管缺乏對(duì)這一架構(gòu)類型的準(zhǔn)確定義，但是在業(yè)務(wù)能力、自動(dòng)化部署、智能端點(diǎn)、語言和數(shù)據(jù)的去中心化控制等方面，已經(jīng)形成了某些普遍特征。中培偉業(yè)《微服務(wù)架構(gòu)設(shè)計(jì)最佳實(shí)踐》曾老師在這里介紹了微服務(wù)架構(gòu)的九大特征。

通過服務(wù)實(shí)現(xiàn)組件化

曾老師指出，我們已經(jīng)在軟件行業(yè)浸淫多年，一直期望能夠通過拼插組件的方式來構(gòu)建系統(tǒng)，而不是采用我們?cè)谖锢硎澜缋锍Ｒ姷姆绞健Ｔ谶^去的幾十年里，我們已經(jīng)見證了多數(shù)語言平臺(tái)的公共庫的匯編已經(jīng)取得了長足的進(jìn)步。

圍繞業(yè)務(wù)能力組織

要把大型應(yīng)用拆分為零件，管理人員通常聚焦在技術(shù)層面，拆分成 UI 組、服務(wù)器端邏輯組和數(shù)據(jù)庫團(tuán)組。當(dāng)這些組被這樣垂直分割，非常簡單的改動(dòng)就會(huì)導(dǎo)致跨組項(xiàng)目，而這需要時(shí)間和預(yù)算批準(zhǔn)。聰明的團(tuán)隊(duì)會(huì)圍繞這點(diǎn)進(jìn)行優(yōu)化，兩害相權(quán)取其輕——強(qiáng)化邏輯到任意有訪問權(quán)限的應(yīng)用。

產(chǎn)品而非項(xiàng)目

大多數(shù)我們常見的應(yīng)用開發(fā)會(huì)使用項(xiàng)目模式：交付軟件的部分然后再考慮組合完整。完成后的軟件被交付到維護(hù)機(jī)構(gòu)，構(gòu)建此項(xiàng)目的團(tuán)隊(duì)不被解散。

微服務(wù)的支持者則易于避免此模式，傾向于「在產(chǎn)品的整個(gè)生命周期里，開發(fā)團(tuán)隊(duì)?wèi)?yīng)該擁有此項(xiàng)目」。這一靈感來自于亞馬遜的「你構(gòu)建，你運(yùn)行」概念。在亞馬遜，開發(fā)團(tuán)隊(duì)對(duì)生產(chǎn)環(huán)境中的軟件負(fù)有全部責(zé)任。這讓開發(fā)者每日都能了解自己的軟件如何在生產(chǎn)環(huán)境運(yùn)行，增強(qiáng)與用戶的接觸，也能承擔(dān)部分支持職責(zé)。

智能終端和啞管道

要在不同進(jìn)程之間構(gòu)建通信結(jié)構(gòu)，我們已經(jīng)見過許多產(chǎn)品和方案，它們強(qiáng)調(diào)在通信機(jī)制內(nèi)部注入智能，其中優(yōu)秀案例如 ESB(企業(yè)服務(wù)總線)。ESB 產(chǎn)品包含復(fù)雜的設(shè)施，用于信息路由、編排、轉(zhuǎn)化，以及應(yīng)用業(yè)務(wù)規(guī)則。

去中心化治理

中心化治理的一大后果就是單一技術(shù)平臺(tái)的標(biāo)準(zhǔn)化傾向。經(jīng)驗(yàn)顯示這一方式非常狹隘——每個(gè)問題各有特色，而「馬斯洛的錘子」并非萬能。我們更喜歡針對(duì)工作使用正確的工具，在特定情境下，一體化應(yīng)用能夠發(fā)揮不同語言的優(yōu)勢(shì)。這并不常見。

去中心化數(shù)據(jù)管理

去中心化數(shù)據(jù)管理的方式多種多樣。在最為抽象的層級(jí)，這意味著各個(gè)系統(tǒng)之間關(guān)于世界的概念模型大相徑庭。在大型企業(yè)進(jìn)行整合時(shí)，這一現(xiàn)象很常見。對(duì)客戶的看法，銷售人員的視角與支持人員的視角不同。銷售認(rèn)為可稱為「客戶」的某些方面，支持人員卻并不認(rèn)同。他們可能只是具有一些在語言描述上差異很細(xì)微的不同屬性。

使用諸如這樣的事務(wù)有助于保持一致，但是帶來了顯著的短時(shí)耦合，對(duì)跨多個(gè)服務(wù)產(chǎn)生問題。分布式事務(wù)因難以實(shí)施而聞名，隨之而來，微服務(wù)架構(gòu)強(qiáng)調(diào)了服務(wù)之間的事務(wù)和諧，明確了一致性只可能為最終一致性，各種問題通過補(bǔ)償運(yùn)算來解決。

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

基礎(chǔ)設(shè)施自動(dòng)化已經(jīng)在過去的幾年里取得了巨大的進(jìn)步。云特別是 AWS 的進(jìn)化格外地降低了構(gòu)建、部署和運(yùn)行微服務(wù)時(shí)的復(fù)雜度。

許多采用微服務(wù)構(gòu)建的產(chǎn)品或系統(tǒng)是由在持續(xù)交付和其前身——持續(xù)集成方面經(jīng)驗(yàn)豐富的團(tuán)隊(duì)構(gòu)建的。使用這種方法構(gòu)建軟件的團(tuán)隊(duì)需要大量使用基礎(chǔ)設(shè)施自動(dòng)化技術(shù)。

為故障而生

把服務(wù)用作組件的一個(gè)結(jié)果是應(yīng)用在設(shè)計(jì)之初就要能容忍技術(shù)故障。任何服務(wù)調(diào)用可能會(huì)由于供應(yīng)商的不可用而失敗，而客戶端需要盡可能優(yōu)雅地做出響應(yīng)。與一體化設(shè)計(jì)相比，由于引入了額外的復(fù)雜性來處理，這是一大不足。其結(jié)果是微服務(wù)團(tuán)隊(duì)不斷反省服務(wù)故障如何影響用戶體驗(yàn)。 Netflix 的 Simian Army 通過測(cè)試應(yīng)用的彈性和監(jiān)控，減少了工作日的服務(wù)故障，甚至數(shù)據(jù)中心的故障。

進(jìn)化的設(shè)計(jì)

微服務(wù)從業(yè)者通常具有進(jìn)化設(shè)計(jì)的背景，把服務(wù)分解視作一個(gè)長遠(yuǎn)的工具，讓應(yīng)用開發(fā)者們能夠控制應(yīng)用內(nèi)的改動(dòng)，無需讓改動(dòng)慢下來。改動(dòng)控制并不一定意味著減少——借助正確的態(tài)度和工具，你能夠經(jīng)常快速、有節(jié)制地修改軟件。