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

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

曾老師指出，我們已經(jīng)在軟件行業(yè)浸淫多年，一直期望能夠通過拼插組件的方式來構(gòu)建系統(tǒng)，而不是采用我們在物理世界里常見的方式。在過去的幾十年里，我們已經(jīng)見證了多數(shù)語言平臺的公共庫的匯編已經(jīng)取得了長足的進(jìn)步。

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

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

產(chǎn)品而非項目

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

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

智能終端和啞管道

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

去中心化治理

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

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

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

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

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

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

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

為故障而生

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

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

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