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

第1層：硬件層

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

創(chuàng)新互聯(lián)主要從事成都網(wǎng)站設計、成都網(wǎng)站建設、網(wǎng)頁設計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務。立足成都服務定襄,10年網(wǎng)站建設經(jīng)驗,價格優(yōu)惠、服務專業(yè),歡迎來電咨詢建站服務:18980820575

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

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

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

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

第2層：通信層

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

RPC、端點和消息傳遞

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

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

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

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

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

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

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

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

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

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

第3層：應用平臺層

應用平臺層是微服務生態(tài)系統(tǒng)的第3層，這一層包含了所有獨立于微服務的內(nèi)部工具和服務。這一層所包含的集中式和服務跨越了整個生態(tài)系統(tǒng)，因為有了這些工具和服務，微服務開發(fā)團隊就可以把精力集中在微服務的開發(fā)上。

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

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

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

在一個已經(jīng)使用了微服務架構的公司里，給工程師團隊指派職責要十分謹慎。最簡單的做法是為微服務生態(tài)系統(tǒng)的每一個層組件一個工程子團隊。這些工程子團隊將負責處理它們所在層的所有相關事務：運維團隊負責第1層，基礎設施團隊負責第2層，應用平臺團隊負責第3層，微服務團隊負責第4層。

在這種組織結構里，工作在上層的工程師需要使用自助工具對下層的一些東西進行配置。例如，負責消息服務的團隊應該為其他開發(fā)者提供一個自助工具，當微服務團隊的開發(fā)者需要為他們的服務配置消息系統(tǒng)時，他們就可以使用這個工具，而無需過多地了解紛繁復雜的消息系統(tǒng)。

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

使用這些工具的第二個理由是，你不需要其他團隊的人來對你的服務和系統(tǒng)做任何關鍵性的改動，因為這些人可能會給你們帶來麻煩。對于底層（第1層、第2層和第3層）的服務來說，更是如此。讓他們在這些層上面做出改動，或者要求（更糟糕的是期待）他們成為某方面的專家有可能會釀成大禍。舉一個配置管理的例子：不具備相關專門知識的微服務團隊開發(fā)人員對系統(tǒng)配置做了一些變更，這有可能導致大規(guī)模的服務癱瘓，因為他們所做的變更有可能不只是影響到它們自己的服務。

開發(fā)周期

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

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

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

測試、構建、打包和發(fā)布

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

部署管道

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

日志和監(jiān)控

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

第4層：微服務層

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

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

另外有需要云服務器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。

網(wǎng)頁名稱：微服務生態(tài)的四層模型-創(chuàng)新互聯(lián)
文章轉載：http://aaarwkj.com/article14/codgde.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站收錄、虛擬主機、網(wǎng)站設計公司、外貿(mào)建站、網(wǎng)站制作、商城網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)