微服務(wù)生態(tài)的四層模型

微服務(wù)生態(tài)的四層模型

第1層：硬件層

硬件層是微服務(wù)生態(tài)的底層。這一層是服務(wù)器物理機(jī)所在的層，它們是所有微服務(wù)運(yùn)行的基礎(chǔ)。這些服務(wù)器被放置在數(shù)據(jù)中心的機(jī)架上，由供電系統(tǒng)供給電力，使用著昂貴的冷卻系統(tǒng)。它們有些是某些公司私有的，有些是從所謂的“云服務(wù)提供商”那里租來的，比如 AWS EC2、GCP、阿里云等。

是自己購買服務(wù)器還是選擇云服務(wù)器并不容易選擇，它需要考慮購買成本、可用性、可靠性和運(yùn)營(yíng)成本。

管理服務(wù)器是硬件層的職責(zé)之一。每臺(tái)服務(wù)器都需要安裝標(biāo)準(zhǔn)的操作系統(tǒng)。使用哪種操作系統(tǒng)并沒有一個(gè)標(biāo)準(zhǔn)答案，這完全取決于要構(gòu)建的應(yīng)用程序、構(gòu)建應(yīng)用程序所使用的語言以及構(gòu)建微服務(wù)所需要的軟件包和工具。主流的微服務(wù)生態(tài)系統(tǒng)一般會(huì)使用 Linux 的變形版本，比如 CentOS、Debian 或 Ubuntu，不過一個(gè)使用了 .NET 平臺(tái)的公司顯然會(huì)有不同的選擇。

操作系統(tǒng)的安裝和硬件資源的配置是服務(wù)器的第一個(gè)層。每個(gè)主機(jī)必須被配置好，而且在安裝好操作系統(tǒng)之后，必須提供一個(gè)配置管理工具（比如 Ansible、Chef 或 Puppet）來安裝應(yīng)用程序，并做好必要的配置。

對(duì)主機(jī)進(jìn)行主機(jī)級(jí)別的監(jiān)控（使用Nagios）是有必要的，而且需要記錄主機(jī)級(jí)別的日志。在主機(jī)出現(xiàn)異常（磁盤錯(cuò)誤、網(wǎng)絡(luò)或CPU過載）時(shí)就可以方便地對(duì)它們進(jìn)行診斷，有助于問題的解決。

第2層：通信層

通信層到生態(tài)系統(tǒng)的所有層，因?yàn)槲⒎?wù)之間的交互會(huì)在多個(gè)層上進(jìn)行，所以很難清晰地對(duì)通信層與其它層之間的邊界進(jìn)行定義。雖然難以清晰地定義它們之間的邊界，但是這個(gè)層所涉及的元素是很明確的。一般包含網(wǎng)絡(luò)、DNS、RPC和API端點(diǎn)、服務(wù)發(fā)現(xiàn)、服務(wù)注冊(cè)以及負(fù)載均衡。

RPC、端點(diǎn)和消息傳遞

微服務(wù)通過遠(yuǎn)程過程調(diào)用（RPC）或消息傳送與其他微服務(wù)進(jìn)行交互，這些調(diào)用通過網(wǎng)絡(luò)發(fā)送到其他微服務(wù)的API端點(diǎn)上（如果使用的是消息傳遞，消息會(huì)被發(fā)送到消息代理，消息代理會(huì)對(duì)這些消息進(jìn)行路由）?；驹硎沁@樣的：使用一個(gè)特定的協(xié)議，一個(gè)微服務(wù)把符合特定格式的數(shù)據(jù)通過網(wǎng)絡(luò)發(fā)送到另一個(gè)服務(wù)（或者是另一個(gè)微服務(wù)的API端點(diǎn)）或消息代理上（消息代理確保數(shù)據(jù)會(huì)被路由到其他微服務(wù)的API端點(diǎn)上）。

微服務(wù)有幾種通信方式，第一種是最常用的HTTP+REST/Thrift。如果使用的是這種方式，各個(gè)服務(wù)使用超文本傳輸協(xié)議（HTTP）進(jìn)行網(wǎng)絡(luò)交互，它們向特定的REST端點(diǎn)（使用各種HTTP方法，比如GET、POST等）或Thrift端點(diǎn)發(fā)送請(qǐng)求或從這些端點(diǎn)接收響應(yīng)。發(fā)送的數(shù)據(jù)一般是JSON（或protool buffer）格式。

第二種通信方式是消息傳遞。消息傳遞是異步（非阻塞）的，不過相對(duì)復(fù)雜。消息傳遞的工作原理是這樣的：一個(gè)微服務(wù)把數(shù)據(jù)（消息）通過網(wǎng)絡(luò)（HTTP或其他）發(fā)送給一個(gè)消息代理，消息代理會(huì)把消息路由到其他微服務(wù)上。

消息傳遞也有幾種模式，最流行的兩種分別是發(fā)布訂閱以及請(qǐng)求和響應(yīng)。如果使用的是發(fā)布和訂閱模式，客戶端會(huì)訂閱一個(gè)主題，它將從主題上收到發(fā)布者發(fā)布的任何一個(gè)消息。請(qǐng)求和響應(yīng)模式就更直接了，客戶端發(fā)送一個(gè)請(qǐng)求到一個(gè)服務(wù)（或消息代理）上，這個(gè)服務(wù)會(huì)對(duì)這個(gè)請(qǐng)求作出響應(yīng)。有些消息中間件同時(shí)支持兩種模式，比如ApacheKafka。

消息傳遞有幾個(gè)缺點(diǎn)需要注意。消息傳遞不會(huì)比HTTP+REST具備更強(qiáng)的伸縮性，如果你的系統(tǒng)對(duì)伸縮性有要求的話一定要清楚這一點(diǎn)。消息傳遞對(duì)變更不友好，因?yàn)樗羌惺降?，這樣會(huì)導(dǎo)致消息隊(duì)列和消息代理變成整個(gè)生態(tài)系統(tǒng)的故障點(diǎn)。它的異步特性在并發(fā)環(huán)境里會(huì)導(dǎo)致競(jìng)賽條件，如果沒有處理好，還會(huì)出現(xiàn)無限循環(huán)。在使用消息傳遞時(shí)，如果能夠處理好上述這些問題，他會(huì)變得跟同步解決方案同樣穩(wěn)定和高效。

服務(wù)發(fā)現(xiàn)、服務(wù)注冊(cè)和負(fù)載均衡

在單體應(yīng)用架構(gòu)里，所有的業(yè)務(wù)流量都被發(fā)送給負(fù)載均衡器，然后被分發(fā)到應(yīng)用服務(wù)器上。而在微服務(wù)架構(gòu)里，業(yè)務(wù)流量被路由到大量不同的應(yīng)用程序上，然后再被分發(fā)給部署了特定微服務(wù)的服務(wù)器。為了能夠高效地實(shí)現(xiàn)上述場(chǎng)景，微服務(wù)架構(gòu)需要在通信層實(shí)現(xiàn)三項(xiàng)技術(shù)：服務(wù)發(fā)現(xiàn)、服務(wù)注冊(cè)和負(fù)載均衡。

一般來說，如果微服務(wù)A需要向微服務(wù)B發(fā)起請(qǐng)求，那么微服務(wù)A需要知道微服務(wù)B的IP地址和端口。微服務(wù)的通信層需要知道這些微服務(wù)的IP地址和端口，才能正確地路由這些請(qǐng)求。這個(gè)問題可以通過服務(wù)發(fā)現(xiàn)（比如etcd、Consul、Hyperbahn 或 Zookeeper）來解決，服務(wù)發(fā)現(xiàn)可以確保請(qǐng)求會(huì)被路由到它們本該去的地方，而且只會(huì)被路由到正常運(yùn)行的實(shí)例上（這非常重要）。服務(wù)發(fā)現(xiàn)需要用到服務(wù)注冊(cè)，服務(wù)注冊(cè)中記錄了生態(tài)系統(tǒng)里所有微服務(wù)的IP地址和端口。

在微服務(wù)架構(gòu)里，在對(duì)微服務(wù)進(jìn)行橫向擴(kuò)展和重新部署時(shí)（比如使用了像Apache Mesos再這樣的硬件抽象層），端口和IP地址會(huì)發(fā)生變化。在這種情況下，可以考慮為每個(gè)微服務(wù)分配一個(gè)靜態(tài)端口。

除非你的所有微服務(wù)都部署在同一個(gè)實(shí)例上（一般不太可能），否則需要在通信層使用負(fù)載均衡。簡(jiǎn)單地說，負(fù)載均衡可以做到：如果你有10個(gè)微服務(wù)實(shí)例，負(fù)載均衡器（軟件或硬件）可以確保業(yè)務(wù)流量（均衡地）分發(fā)到所有的實(shí)例上。在微服務(wù)生態(tài)系統(tǒng)里，只要涉及請(qǐng)求轉(zhuǎn)發(fā)，都需要用到負(fù)載均衡器，這意味著一個(gè)大型的微服務(wù)生態(tài)系統(tǒng)將包含多層負(fù)載均衡。常見的負(fù)載均衡器有 Amazon Web Services Elastic Load Balancer、Netflix 的 Eureka 和 Nginx。

第3層：應(yīng)用平臺(tái)層

應(yīng)用平臺(tái)層是微服務(wù)生態(tài)系統(tǒng)的第3層，這一層包含了所有獨(dú)立于微服務(wù)的內(nèi)部工具和服務(wù)。這一層所包含的集中式和服務(wù)跨越了整個(gè)生態(tài)系統(tǒng)，因?yàn)橛辛诉@些工具和服務(wù)，微服務(wù)開發(fā)團(tuán)隊(duì)就可以把精力集中在微服務(wù)的開發(fā)上。

一個(gè)好的應(yīng)用平臺(tái)需要為開發(fā)者提供一套內(nèi)部的自助工具，包括標(biāo)準(zhǔn)化的開發(fā)流程、集中式的自動(dòng)化構(gòu)建和發(fā)布系統(tǒng)、自動(dòng)化測(cè)試、標(biāo)準(zhǔn)化和集中式的部署方案以及集中式的日志和微服務(wù)級(jí)別的監(jiān)控。這些元素的細(xì)節(jié)此處不進(jìn)行探討，不過我們也會(huì)簡(jiǎn)要地介紹其中的幾個(gè)元素，闡述一些基本的概念。

內(nèi)部自助開發(fā)工具

有很多東西可以被納入內(nèi)部自助開發(fā)工具的范疇，它們是否可以被歸納為這類工具不僅取決于開發(fā)者對(duì)工具的需求，還要考慮基礎(chǔ)設(shè)施和生態(tài)系統(tǒng)的整體抽象度和復(fù)雜性。決定使用哪一種工具，首先要對(duì)責(zé)任領(lǐng)域進(jìn)行切分，然后對(duì)開發(fā)者所要完成的任務(wù)進(jìn)行評(píng)估，以便設(shè)計(jì)、構(gòu)建和維護(hù)他們的服務(wù)。

在一個(gè)已經(jīng)使用了微服務(wù)架構(gòu)的公司里，給工程師團(tuán)隊(duì)指派職責(zé)要十分謹(jǐn)慎。最簡(jiǎn)單的做法是為微服務(wù)生態(tài)系統(tǒng)的每一個(gè)層組件一個(gè)工程子團(tuán)隊(duì)。這些工程子團(tuán)隊(duì)將負(fù)責(zé)處理它們所在層的所有相關(guān)事務(wù)：運(yùn)維團(tuán)隊(duì)負(fù)責(zé)第1層，基礎(chǔ)設(shè)施團(tuán)隊(duì)負(fù)責(zé)第2層，應(yīng)用平臺(tái)團(tuán)隊(duì)負(fù)責(zé)第3層，微服務(wù)團(tuán)隊(duì)負(fù)責(zé)第4層。

在這種組織結(jié)構(gòu)里，工作在上層的工程師需要使用自助工具對(duì)下層的一些東西進(jìn)行配置。例如，負(fù)責(zé)消息服務(wù)的團(tuán)隊(duì)?wèi)?yīng)該為其他開發(fā)者提供一個(gè)自助工具，當(dāng)微服務(wù)團(tuán)隊(duì)的開發(fā)者需要為他們的服務(wù)配置消息系統(tǒng)時(shí)，他們就可以使用這個(gè)工具，而無需過多地了解紛繁復(fù)雜的消息系統(tǒng)。

使用這些集中式的自助工具是由原因的。在一個(gè)多元化的微服務(wù)生態(tài)系統(tǒng)里，一個(gè)團(tuán)隊(duì)的普通工程師對(duì)其他團(tuán)隊(duì)的系統(tǒng)和服務(wù)并不了解（或知之甚少），他們也不可能稱為面面俱到的專家。每個(gè)開發(fā)人員只對(duì)自己負(fù)責(zé)的部分比較了解，但從整個(gè)生態(tài)系統(tǒng)來看，這些開發(fā)人員組合在一起就無所不知了。為生態(tài)系統(tǒng)的每一部分構(gòu)建易用的用戶界面，為開發(fā)人員提供相關(guān)的培訓(xùn)，以便教會(huì)他們?nèi)绾问褂眠@些工具，而不是試圖讓每個(gè)開發(fā)人員了解這些工具和服務(wù)紛繁復(fù)雜的內(nèi)部細(xì)節(jié)。把所有的事情放到一個(gè)黑匣子里，然后提供詳細(xì)的說明文檔。

使用這些工具的第二個(gè)理由是，你不需要其他團(tuán)隊(duì)的人來對(duì)你的服務(wù)和系統(tǒng)做任何關(guān)鍵性的改動(dòng)，因?yàn)檫@些人可能會(huì)給你們帶來麻煩。對(duì)于底層（第1層、第2層和第3層）的服務(wù)來說，更是如此。讓他們?cè)谶@些層上面做出改動(dòng)，或者要求（更糟糕的是期待）他們成為某方面的專家有可能會(huì)釀成大禍。舉一個(gè)配置管理的例子：不具備相關(guān)專門知識(shí)的微服務(wù)團(tuán)隊(duì)開發(fā)人員對(duì)系統(tǒng)配置做了一些變更，這有可能導(dǎo)致大規(guī)模的服務(wù)癱瘓，因?yàn)樗麄兯龅淖兏锌赡懿恢皇怯绊懙剿鼈冏约旱姆?wù)。

開發(fā)周期

開發(fā)人員在對(duì)已有微服務(wù)進(jìn)行修改或構(gòu)建新的微服務(wù)時(shí)，對(duì)開發(fā)流程進(jìn)行流水線化、標(biāo)準(zhǔn)化和自動(dòng)化可以大幅提升開發(fā)效率。有些東西需要被放在微服務(wù)生態(tài)系統(tǒng)的第3層，讓穩(wěn)定可靠的開發(fā)成為可能。

首先是集中式的版本控制系統(tǒng)，這個(gè)系統(tǒng)保存了所有代碼，允許對(duì)代碼進(jìn)行跟蹤、版本管理和搜索。這個(gè)可以通過一些工具來實(shí)現(xiàn)，比如 GitHub 或者自有的 git 或 svn 代碼倉庫，可以將這些倉庫和一些協(xié)作工具集成起來，比如 Phabrictor，以簡(jiǎn)化代碼的維護(hù)和審查工作。

其次是穩(wěn)定高效地開發(fā)環(huán)境?？偹苤谖⒎?wù)生態(tài)系統(tǒng)里實(shí)現(xiàn)一個(gè)這樣的開發(fā)環(huán)境是很困難的，因?yàn)槲⒎?wù)之間的依賴太過復(fù)雜。不過它們都是最基本的因素，我們無法避免。一些工程組織傾向于本地完成開發(fā)工作（在開發(fā)人員的電腦上），不過這樣會(huì)導(dǎo)致糟糕的部署，因?yàn)殚_發(fā)人員并不清楚他們修改的代碼是如何被部署到生產(chǎn)環(huán)境的。最穩(wěn)定可靠的構(gòu)建開發(fā)環(huán)境的方式是為生產(chǎn)環(huán)境創(chuàng)建一個(gè)鏡像（不是為了預(yù)生產(chǎn)，也不是為了收集反饋，更不是為了生產(chǎn)），這個(gè)鏡像包含所有復(fù)雜的依賴關(guān)系鏈。

測(cè)試、構(gòu)建、打包和發(fā)布

開發(fā)過程中的測(cè)試、構(gòu)建、打包和發(fā)布應(yīng)該盡量被標(biāo)準(zhǔn)化和集中化。在開發(fā)結(jié)束之后，當(dāng)有代碼變更被提交，需要運(yùn)行相關(guān)的測(cè)試用例，然后自動(dòng)構(gòu)建和打包即將發(fā)布的新版本。這個(gè)時(shí)候，持續(xù)集成工具就可以派上用場(chǎng)，一些現(xiàn)成的解決方案（比如Jenkins）不僅功能齊全而且使用方便。這些工具可以讓整個(gè)過程自動(dòng)化，幾乎不留給人類任何犯錯(cuò)的機(jī)會(huì)。

部署管道

在經(jīng)過了開發(fā)、測(cè)試、構(gòu)建、打包和發(fā)布這些步驟之后，部署管道是新代碼走向生產(chǎn)環(huán)境的另一個(gè)流程。在一個(gè)微服務(wù)生態(tài)系統(tǒng)里，部署會(huì)在很短的時(shí)間內(nèi)變得極其復(fù)雜，每天上百個(gè)部署都是很平常的事。開發(fā)團(tuán)隊(duì)需要為開發(fā)構(gòu)建工具，并對(duì)開發(fā)過程進(jìn)行標(biāo)準(zhǔn)化。

日志和監(jiān)控

所有的微服務(wù)都應(yīng)該把它們的請(qǐng)求和響應(yīng)相關(guān)的重要信息記錄到日志里。因?yàn)槲⒎?wù)變更的速度太快，如果系統(tǒng)發(fā)生了錯(cuò)誤，重建當(dāng)時(shí)的系統(tǒng)狀態(tài)變得很困難，導(dǎo)致代碼的缺陷難以重現(xiàn)。使用微服務(wù)級(jí)別的日志可以幫助開發(fā)人員更好地了解他們的服務(wù)在過去某個(gè)時(shí)刻或當(dāng)前時(shí)刻的狀態(tài)。在微服務(wù)級(jí)別對(duì)微服務(wù)的關(guān)鍵度量指標(biāo)進(jìn)行監(jiān)控也是出于同樣的目的：實(shí)時(shí)準(zhǔn)確的監(jiān)控可以幫助開發(fā)人員了解服務(wù)的狀態(tài)和健康狀況。

第4層：微服務(wù)層

微服務(wù)生態(tài)系統(tǒng)的頂層是微服務(wù)層。這一層是微服務(wù)以及微服務(wù)所有相關(guān)事物所在的層，它與底下的基礎(chǔ)設(shè)施層完全分離，比如硬件、部署、服務(wù)發(fā)現(xiàn)、負(fù)載均衡和通信。微服務(wù)層唯一沒有被分離的是使用自助工具所做的配置。

在軟件工程里，應(yīng)用的配置一般會(huì)被集中化，針對(duì)某個(gè)工具或某些工具（配置管理、資源隔離或部署工具）的配置可以和這些工具保存在一起。例如，應(yīng)用程序的自定義部署配置一般會(huì)和部署工具的代碼保存在一起，而不是和應(yīng)用程序的代碼保存在一起。這種方式對(duì)單體應(yīng)用架構(gòu)或小型的微服務(wù)生態(tài)系統(tǒng)來說是沒有問題的，但在包含了大量微服務(wù)和內(nèi)部工具（每個(gè)工具都有自定義的配置）的大型微服務(wù)生態(tài)系統(tǒng)里，這種方式就會(huì)造成混亂：處在上層的微服務(wù)團(tuán)隊(duì)需要修改處在下層的工具代碼，他們會(huì)經(jīng)常忘記哪些地方包含了配置信息（或者不包含）。為了解決這個(gè)問題，可以把與微服務(wù)相關(guān)的配置放在微服務(wù)代碼庫里，然后開放給下層的工具和系統(tǒng)訪問。