基于微服務(wù)架構(gòu)的基礎(chǔ)設(shè)施設(shè)計

摘要：本文首先分析傳統(tǒng)的單體架構(gòu)進而解釋微服務(wù)架構(gòu)以及分布式環(huán)境下四層架構(gòu)，詳細分析了遷移需解決的關(guān)鍵問題如服務(wù)間通信機制、數(shù)據(jù)最終一致性等；然后分析了分布式系統(tǒng)核心問題和DevOps基本原則，以此為設(shè)計依據(jù)提出微服務(wù)架構(gòu)基礎(chǔ)設(shè)施總體設(shè)計，并且對其關(guān)鍵組件如服務(wù)注冊與發(fā)現(xiàn)、持續(xù)交付平臺、服務(wù)網(wǎng)關(guān)的實施提出具體方案；最后針對微服務(wù)架構(gòu)基礎(chǔ)設(shè)施在運維管理中的應(yīng)用場景進行了探討，說明了微服務(wù)架構(gòu)設(shè)計思想優(yōu)于單體架構(gòu)設(shè)計思想。

關(guān)鍵詞：軟件工程；微服務(wù)；服務(wù)注冊與發(fā)現(xiàn)；持續(xù)交付

中圖分類號：TP311.5 文獻標識碼：A DOI：10.3969/j.issn.1003 6970.2016.05.023

本文著錄格式：蔣勇.基于微服務(wù)架構(gòu)的基礎(chǔ)設(shè)施設(shè)計卟軟件，2016，37（5）：93-97

0.引言

理論上任何業(yè)務(wù)系統(tǒng)如果長期存在的話，隨著此系統(tǒng)業(yè)務(wù)變更、功能增加必然會不斷演變，在一個更大的分布式環(huán)境中，這種改變尤其明顯，那么就需要架構(gòu)分析設(shè)計時更多的考慮系統(tǒng)所處的生態(tài)環(huán)境建設(shè)，這樣才能使得整個系統(tǒng)不斷進化。隨著虛擬化技術(shù)的發(fā)展以及docker容器實踐逐漸完善，微服務(wù)架構(gòu)的設(shè)計思想逐漸浮出水面，形成分布式環(huán)境下新的最重要的設(shè)計思想。文獻對分布式環(huán)境下資源及應(yīng)用平臺進行了研究，但對于應(yīng)用自身依賴的基礎(chǔ)設(shè)施建設(shè)沒有討論。本文將詳細探討如何基于微服務(wù)架構(gòu)進行基礎(chǔ)設(shè)施建設(shè)的設(shè)計與分析。

1.從分布式單體架構(gòu)到微服務(wù)架構(gòu)遷移

1.1分布式單體架構(gòu)

分布式單體架構(gòu)指的是在分布式環(huán)境下直接部署運行一個整體開發(fā)的應(yīng)用，由整體應(yīng)用來提供系統(tǒng)所需的服務(wù)，它在技術(shù)上通常采用分層實現(xiàn)，大致分為表現(xiàn)層、應(yīng)用層、數(shù)據(jù)層，它有天然的優(yōu)勢：它是模塊獨立無關(guān)的，各層之間是技術(shù)分離的；它有統(tǒng)一的技術(shù)棧和開發(fā)標準；它通常在一個進程中運行，模塊相互之間協(xié)同消耗極小。

但是，在分布式環(huán)境下，隨著系統(tǒng)功能的增加，系統(tǒng)越來越復(fù)雜，單體架構(gòu)存在一些必然的缺陷：首先，由于整個系統(tǒng)是一個完整整體，必須重復(fù)部署多個才能提高系統(tǒng)性能，而往往系統(tǒng)瓶頸僅僅由于其中某一個或幾個功能過載產(chǎn)生，這就極大浪費了運行環(huán)境資源；其次，由于系統(tǒng)功能的變更和演變，某一個功能的變化可能影響其它功能的正常結(jié)果，也帶來重新部署和運維管理的復(fù)雜性，持續(xù)集成變得極為困難；最后，由于整個系統(tǒng)采用統(tǒng)一的技術(shù)棧和開發(fā)標準，必然使得技術(shù)本身的多樣性受到限制，造成解決問題的方法和開發(fā)方式存在一定的局限性，當整合外部服務(wù)、開放內(nèi)部服務(wù)時也帶來一些技術(shù)實現(xiàn)的復(fù)雜性。

由此可知，在分布式環(huán)境下原有的整體開發(fā)的單體架構(gòu)有必要改進、變化。

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

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

微服務(wù)架構(gòu)是一種新的軟件體系設(shè)計模式，它并沒有形成統(tǒng)一、嚴格的定義，但是基于其分布式環(huán)境應(yīng)用的場景，卻擁有一些共同的特征：比如開發(fā)敏捷性、持續(xù)交付、可伸縮性、最終一致性等。

微服務(wù)架構(gòu)建議將大型復(fù)雜的單體架構(gòu)應(yīng)用劃分為一組微小的服務(wù)，每個微服務(wù)根據(jù)其負責的具體業(yè)務(wù)職責提煉為單一的業(yè)務(wù)功能；每個服務(wù)可以很容易地部署并發(fā)布到生產(chǎn)環(huán)境里隔離和獨立的進程內(nèi)部，它可以很容易地擴展和變更；對于一個具體的服務(wù)來說可以采用任何適用的語言和工具來快速實現(xiàn)；服務(wù)之間基于基礎(chǔ)設(shè)施互相協(xié)同工作。

1.2.2分布式四層架構(gòu)定義

由美國視頻服務(wù)企業(yè)netflix提出的“engagement platform”支持分布式的四層架構(gòu)，是目前采用微服務(wù)架構(gòu)的最成功實踐，它能很好的適用于大規(guī)模應(yīng)用運行環(huán)境，滿足更高的性能要求。分析理想的分布式四層架構(gòu)如圖1所示。

分布式四層架構(gòu)的每層功能如下：

1）顯示層：這一層主要是把系統(tǒng)提供的各類服務(wù)展現(xiàn)給用戶，支持用戶通過界面與系統(tǒng)進行友好的交互，也支持管理員通過界面對系統(tǒng)進行監(jiān)控管理。

2）分發(fā)層：這一層主要針對用戶或者其它系統(tǒng)發(fā)出的請求進行預(yù)處理，并根據(jù)策略決定路由到何處去進行處理，從而達到分發(fā)控制的目的，并且根據(jù)請求峰值采取負載均衡擴展策略或者相應(yīng)熔斷限流策略。

3）聚合層：這一層負責提供基于各類原子基礎(chǔ)服務(wù)的集成、編排、組合，并且包含各類數(shù)據(jù)的清洗、采集、轉(zhuǎn)換；提供可以動態(tài)變更策略的服務(wù)訪問控制功能（如授權(quán)機制、角色分配、緩存、數(shù)據(jù)一致性等）；提供輕量級的通信機制或者采用統(tǒng)一默認調(diào)用規(guī)則使得各類服務(wù)之間容易協(xié)同合作。

4）服務(wù)層：這一層提供不可分割的、最小原子的、單一業(yè)務(wù)功能的服務(wù)，每一個服務(wù)部署在獨立的、隔離的運行環(huán)境，可以方便的替換和擴展，對上層提供基礎(chǔ)API調(diào)用接口支持。

1.3遷移需解決問題

在分布式環(huán)境下，從單體架構(gòu)遷移到微服務(wù)架構(gòu)需要解決很多問題：首先需要一種設(shè)計理念的轉(zhuǎn)變，根據(jù)職責分離的原則把大的復(fù)雜的業(yè)務(wù)邏輯抽象成更小的原子的可重復(fù)利用的服務(wù)，并且盡可能的減少流程緊密聯(lián)系的業(yè)務(wù)邏輯拆分；其次需要從服務(wù)這個角度出發(fā)考慮業(yè)務(wù)邏輯的設(shè)計實現(xiàn)，進而考慮服務(wù)的定位、編排和訪問控制如何優(yōu)雅的實現(xiàn)；最后需要考慮的是這些微服務(wù)的可持續(xù)交付以及后端數(shù)據(jù)最終一致性問題。從單體應(yīng)用遷移到微服務(wù)應(yīng)用如圖2所示：

1.3.1如何處理服務(wù)狀態(tài)

在分布式環(huán)境下盡可能的設(shè)計無狀態(tài)的微服務(wù)更容易實現(xiàn)可伸縮性，但是在很多應(yīng)用場景（用戶相關(guān)數(shù)據(jù)讀寫）有狀態(tài)是不可避免的，所以必須把有狀態(tài)服務(wù)的狀態(tài)相關(guān)信息提取出來使得有狀態(tài)服務(wù)達到無狀態(tài)服務(wù)同樣的性能和擴展能力。目前有兩種實現(xiàn)方式：一種是采用分布式緩存集群存儲狀態(tài)，一種是采用nosql數(shù)據(jù)庫集群來存儲狀態(tài)。

1.3.2服務(wù)之間通信機制

由于每個微服務(wù)都是在獨立、隔離的進程內(nèi)部運行，所以這些微服務(wù)之間的調(diào)用行為屬于進程間通信。服務(wù)之間通信機制需要考慮以下幾點：

1）服務(wù)標識：每個微服務(wù)需要通過類似語義定義語言來準確的描述標識一個服務(wù)的API，還需要考慮到服務(wù)升級和多版本共存如何描述，保證向前兼容；

2）服務(wù)并發(fā)情況：服務(wù)之間的調(diào)用方式存在兩種響應(yīng)方式：一個服務(wù)的請求會有一個服務(wù)實例響應(yīng)，一個服務(wù)的請求會有多個服務(wù)實例響應(yīng)。如果是并發(fā)就需要考慮如何實現(xiàn)并描述服務(wù)并發(fā)觸發(fā)機制以及并發(fā)策略；

3）處理部分失效：當服務(wù)被調(diào)用時可能存在調(diào)用超時或者得不到響應(yīng)因而產(chǎn)生調(diào)用堵塞并且占用資源，處理這類情況需要根據(jù)不同場景采取不同策略，比如超時重試策略、熔斷限流策略、最近失敗緩存等。

4）同步請求/響應(yīng)模式：基于http的REST，基于RPC和序列化支持多種消息格式的Thrift，二進制格式的Protocol Buffer、Avro。

5）異步消息通信模式：實現(xiàn)AMQP的RabbitMQ、Apache的Kafka。

6）服務(wù)執(zhí)行結(jié)果緩存：隨著系統(tǒng)性能要求的增長或者服務(wù)被重復(fù)調(diào)用的需要，在一定時間間隔緩存服務(wù)執(zhí)行結(jié)果存在一定必要性。

1.3.3服務(wù)注冊與發(fā)現(xiàn)機制

如何進行服務(wù)定位就涉及到服務(wù)的注冊與發(fā)現(xiàn)機制，這就需要提供一個高性能、高可用、實時更新的服務(wù)注冊與發(fā)現(xiàn)中心或者提供智能終端和啞管道。

服務(wù)注冊有自注冊/被注冊兩種方式。自注冊：由服務(wù)實例自己到服務(wù)注冊與發(fā)現(xiàn)中心注冊或注銷，并且通過心跳通訊來確認注冊信息有效性。被注冊：由服務(wù)注冊與發(fā)現(xiàn)中心來確認服務(wù)的注冊與注銷，它常常通過查詢服務(wù)實例部署信息或者通過訂閱服務(wù)實例部署事件來發(fā)現(xiàn)一個新的服務(wù)實例，并跟蹤其運行狀態(tài)確認注銷終止的服務(wù)實例。

服務(wù)發(fā)現(xiàn)有兩種場景：服務(wù)調(diào)用者發(fā)現(xiàn)/分發(fā)層服務(wù)發(fā)現(xiàn)。

1）服務(wù)調(diào)用者發(fā)現(xiàn)場景：服務(wù)調(diào)用者直接向服務(wù)注冊與發(fā)現(xiàn)中心請求查詢，獲得可用的服務(wù)，根據(jù)默認規(guī)則或者負載均衡策略從與此服務(wù)對應(yīng)的多個服務(wù)實例中選擇請求對象發(fā)出請求。這種場景就需要提供客戶端框架。

2）分發(fā)層服務(wù)發(fā)現(xiàn)場景：客戶端向分發(fā)層提出請求，分發(fā)層處理請求時首先向服務(wù)注冊與發(fā)現(xiàn)中心發(fā)出查詢獲取查詢結(jié)果，然后依據(jù)分發(fā)路由策略將每個請求轉(zhuǎn)發(fā)往可用的服務(wù)實例。這種場景需要服務(wù)端框架。

1.3.4服務(wù)可持續(xù)交付

實現(xiàn)微服務(wù)架構(gòu)的保障就是能夠嚴格執(zhí)行服務(wù)的可持續(xù)交付，服務(wù)可持續(xù)交付指的是每個服務(wù)交付的流程具備持續(xù)性，也就是說一個微服務(wù)應(yīng)用從開發(fā)完畢到部署發(fā)布中間的過程是一個可持續(xù)的過程，并且這個微服務(wù)應(yīng)用可能存在多個版本不同運行狀態(tài)的服務(wù)實例，它們需要集成到現(xiàn)有的運行環(huán)境中穩(wěn)定提供服務(wù)。服務(wù)可持續(xù)交付常常包括幾個方面：開發(fā)、單元測試、構(gòu)建、部署、集成、集成測試、發(fā)布，從基礎(chǔ)設(shè)施環(huán)境來看又包含幾個部分：代碼版本管理、構(gòu)建管理、部署管理、集成管理、測試管理、發(fā)布管理、運維監(jiān)控管理。

1.3.5數(shù)據(jù)最終一致性

數(shù)據(jù)最終一致性指的是數(shù)據(jù)對象在沒有新的更新之前，最終所有獲取數(shù)據(jù)的請求都將返回最后更新的值，在分布式環(huán)境微服務(wù)架構(gòu)下，為了保證每個微服務(wù)的可伸縮性和獨立性，為了保證微服務(wù)之間的松散耦合，不同的微服務(wù)都有自己的數(shù)據(jù)源并且可能使用不同類型的數(shù)據(jù)庫（nosql或者關(guān)系型數(shù)據(jù)庫），這種去中心的分布式數(shù)據(jù)管理使得實現(xiàn)多個服務(wù)之間的事務(wù)型事務(wù)變得極為困難，因為如果這種多階段事務(wù)執(zhí)行中任何一個階段失敗都會造成數(shù)據(jù)不一致（事務(wù)回滾非常復(fù)雜），這就需要一種方案既保證多服務(wù)之間的事務(wù)型事務(wù)執(zhí)行時業(yè)務(wù)交易的數(shù)據(jù)一致性又保證從多個服務(wù)獲取一致性數(shù)據(jù)的高可用性。

一種方案是多個微服務(wù)應(yīng)用訪問同一個數(shù)據(jù)庫或者把多個微服務(wù)應(yīng)用邏輯上歸并為一個微服務(wù)應(yīng)用開發(fā)，這里就需要在業(yè)務(wù)邏輯拆分時進行權(quán)衡，對于那些頻繁訪問或者流程緊密聯(lián)系的業(yè)務(wù)功能不進行拆分而作為一個微服務(wù)進行設(shè)計開發(fā)。

另一種方案是使用事件驅(qū)動框架和消息隊列來完成多個服務(wù)之間的事務(wù)型事務(wù)，其流程是把跨多服務(wù)的事務(wù)分解為若干步驟，每一個步驟會發(fā)布一個激活下一個步驟的事件，任何一個步驟失敗代表整個事務(wù)失敗，必須保證對數(shù)據(jù)的修改能夠通過事務(wù)補償運算來實現(xiàn)邏輯回滾。這種方案的優(yōu)點是異步且事務(wù)吞吐量大、容錯性好，其缺點是開發(fā)較為復(fù)雜。

2.微服務(wù)架構(gòu)基礎(chǔ)設(shè)施設(shè)計與分析

2.1微服務(wù)架構(gòu)基礎(chǔ)設(shè)施設(shè)計依據(jù)

2.1.1分布式系統(tǒng)核心問題

1）性能和可伸縮性

在分布式環(huán)境下，微服務(wù)架構(gòu)使得業(yè)務(wù)邏輯可以拆分為粒度較小的服務(wù)，這些服務(wù)能夠運行在獨立、隔離的環(huán)境，易于部署、可擴展性強，因此這些微服務(wù)的處理請求能力可伸縮性強，性能優(yōu)勢明顯。

2）數(shù)據(jù)一致性和高可用性

在分布式環(huán)境下，從硬件到主機操作系統(tǒng)到軟件總有一部分存在故障狀態(tài)，需要保證這個系統(tǒng)的高可用性就需要盡可能的減少系統(tǒng)資源開銷的同時排除單點故障或者容忍錯誤；然而在故障恢復(fù)或者多點備份或者執(zhí)行多服務(wù)事務(wù)的同時也需要保證數(shù)據(jù)的一致性，基于性能優(yōu)先的考慮這種數(shù)據(jù)一致性是數(shù)據(jù)最終一致性。

2.1.2DevOps基本原則

DevOps指的是從軟件交付的全局出發(fā)在開發(fā)和運維架起交流和協(xié)作的橋梁，并且自動化配置管理軟件的文化變革運動，DevOps的重要組成部分就是持續(xù)交付，其基本原則是使軟件交付的流程自動化且可持續(xù)，并盡可能簡潔。

2.2微服務(wù)架構(gòu)基礎(chǔ)設(shè)施總體設(shè)計

通過分析在分布式環(huán)境下從單體架構(gòu)遷移到微服務(wù)架構(gòu)需要解決的問題以及微服務(wù)架構(gòu)基礎(chǔ)設(shè)施的設(shè)計依據(jù)，得到微服務(wù)架構(gòu)基礎(chǔ)設(shè)施總體設(shè)計如圖3所示。

其中，開發(fā)完畢的微服務(wù)應(yīng)用經(jīng)由持續(xù)交付平臺部署、驗證、發(fā)布到分布式環(huán)境中，同時把這個微服務(wù)注冊到服務(wù)注冊中心，用戶或外部服務(wù)通過服務(wù)網(wǎng)關(guān)訪問此分布式環(huán)境節(jié)點中的API服務(wù)，服務(wù)網(wǎng)關(guān)通過服務(wù)注冊中心發(fā)現(xiàn)服務(wù)。其他一些基礎(chǔ)設(shè)施提供對這些微服務(wù)的運行監(jiān)控管理。

2.3微服務(wù)架構(gòu)基礎(chǔ)設(shè)施關(guān)鍵組件

2.3.1持續(xù)交付平臺

實現(xiàn)一個可持續(xù)交付平臺的目的是把基于分布式環(huán)境分析設(shè)計的微服務(wù)應(yīng)用快速靈活、可重復(fù)且持續(xù)的、自動化的集成部署到分布式環(huán)境中穩(wěn)定運行，并且這些微服務(wù)是可編程配置、易于維護、變更、擴展的，其可以運行于一個獨立、隔離的容器里表現(xiàn)為一個進程。持續(xù)交付流程如圖4所示。

一個可持續(xù)交付平臺主要包含兩部分內(nèi)容：

1）軟硬件資源管理功能：它主要管理整個分布式環(huán)境中的軟硬件資源如何合理進行邏輯劃分利用，這些資源包括主機資源（內(nèi)存、硬盤、磁盤陣列、CPU）、網(wǎng)絡(luò)設(shè)施（路由、虛擬網(wǎng)絡(luò)）、容器實例（微服務(wù)實例）等。

2）持續(xù)交付流程引擎：通過定義可持續(xù)交付流程的各個階段節(jié)點以及觸發(fā)條件，并且提供默認執(zhí)行規(guī)則和策略或者人工配置選項設(shè)置來實現(xiàn)一個微服務(wù)實例的構(gòu)建、集成、部署流程，通過心跳檢測或其它手段監(jiān)控微服務(wù)實例健康狀況并且可在期望閾值時觸發(fā)相應(yīng)響應(yīng)事件。

目前開源可借鑒產(chǎn)品有：Jenkins、Netflix的Spinnaker、ThoughtWorks的Go等。

2.3.2服務(wù)注冊與發(fā)現(xiàn)組件

服務(wù)注冊與發(fā)現(xiàn)是微服務(wù)架構(gòu)中的核心組件，分布式環(huán)境中服務(wù)的實例會根據(jù)運行環(huán)境變化依據(jù)默認規(guī)則或策略動態(tài)變化，這時要實現(xiàn)服務(wù)注冊與發(fā)現(xiàn)變得異常復(fù)雜，它常常需要提供以下功能：

1）注冊和標識服務(wù)：一個服務(wù)一旦從可持續(xù)交付平臺部署運行起來就成為一個服務(wù)實例服務(wù)實例最終是需要被用戶或其它服務(wù)訪問的，那么需要一個服務(wù)注冊中心記錄服務(wù)實例的位置信息屬性、訪問路徑、認證證書、訪問協(xié)議、版本號以及其它訪問相關(guān)信息。可以通過在部署流程結(jié)束時向服務(wù)注冊中心自動注冊服務(wù)實例。標識一個服務(wù)的服務(wù)實例那么意味著首先需要標識一個服務(wù)。一個服務(wù)實例和服務(wù)的不同之處在于服務(wù)實例是有位置信息和部署相關(guān)信息的，而且一個服務(wù)實例是有健康狀態(tài)的也是有生命周期的，一個服務(wù)可以有多個版本，每個版本的服務(wù)對應(yīng)多個服務(wù)實例，每個版本的服務(wù)對應(yīng)一個部署流程。服務(wù)注冊中心追蹤服務(wù)實例的運行狀態(tài)，服務(wù)實例隨著自身健康狀態(tài)的變化以及網(wǎng)絡(luò)環(huán)境的變化其位置信息會動態(tài)變化。一個版本的服務(wù)它的服務(wù)實例在運行環(huán)境中動態(tài)部署多少個需要配置相應(yīng)閾值觸發(fā)策略。

2）定位和發(fā)現(xiàn)服務(wù)：當用戶從客戶端直接訪問時，分發(fā)層會查詢服務(wù)注冊中心發(fā)現(xiàn)可訪問的服務(wù)并根據(jù)負載均衡算法轉(zhuǎn)發(fā)到相應(yīng)的服務(wù)實例。從分發(fā)層來看，服務(wù)層提供的服務(wù)是單個服務(wù)，聚合層提供的服務(wù)是多個服務(wù)的編排組合。分發(fā)層需要根據(jù)請求負載和活著的服務(wù)實例數(shù)量決定負載均衡算法或者擴展已有的服務(wù)實例。更多的場景是多個微服務(wù)協(xié)同合作時如何定位和發(fā)現(xiàn)服務(wù)。這時調(diào)用者如果不經(jīng)過分發(fā)層而是直接訪問服務(wù)層的服務(wù)，那么調(diào)用者查詢服務(wù)注冊中心發(fā)現(xiàn)可訪問的服務(wù)以及與之對應(yīng)的服務(wù)實例，然后設(shè)置相應(yīng)的負載均衡算法調(diào)用相應(yīng)的服務(wù)實例。

目前開源可借鑒產(chǎn)品有：Netflix的Eureka、Etcd、Consul等。

2.3.3服務(wù)網(wǎng)關(guān)

服務(wù)網(wǎng)關(guān)是一個統(tǒng)一調(diào)用邏輯人口，封裝了分布式環(huán)境中某個節(jié)點內(nèi)部的服務(wù)信息。服務(wù)網(wǎng)關(guān)的實現(xiàn)有幾部分：

1）支持對已有的服務(wù)注冊中心注冊的服務(wù)直接暴露給外部調(diào)用。

2）對于客戶端展現(xiàn)需要調(diào)用的多個服務(wù)的場景開發(fā)新的服務(wù)使得客戶端一次請求獲得多個服務(wù)的組合結(jié)果。

3）支持對請求預(yù)處理、規(guī)則匹配，比如認證、授權(quán)判斷等。

4）支持為某些一定時間間隔執(zhí)行結(jié)果不變的服務(wù)請求提供緩存存儲，并且對服務(wù)請求部分失效提供最后一次正確執(zhí)行的緩存結(jié)果或者空響應(yīng)。

5）提供請求分發(fā)路由、負載均衡、安全防護、協(xié)議轉(zhuǎn)換等功能。

目前開源的服務(wù)網(wǎng)關(guān)有：Netflix的Zuul，Mashape的Kong、Tyk等。

3.微服務(wù)架構(gòu)基礎(chǔ)設(shè)施在運維管理中的應(yīng)用

隨著信息化的發(fā)展，各類應(yīng)用系統(tǒng)層出不窮，運維人員管理數(shù)量極其龐大的微服務(wù)變得十分復(fù)雜，因此在分布式環(huán)境下應(yīng)用的可持續(xù)交付能力變得極其重要。采用持續(xù)交付平臺可以支持微服務(wù)自動化的便捷部署到分布式環(huán)境中并經(jīng)過驗證后發(fā)布。采用服務(wù)注冊中心可以支持微服務(wù)的發(fā)現(xiàn)與定位，為微服務(wù)的集成、組合提供支持。采用服務(wù)網(wǎng)關(guān)可以對外提供一個分布式環(huán)境節(jié)點的微服務(wù)API統(tǒng)一訪問入口。采用其它基礎(chǔ)設(shè)施比如消息總線可以提供微服務(wù)之間異步調(diào)用支持，任務(wù)和資源調(diào)度可以提供微服務(wù)合理利用分布式環(huán)境各類資源。通過在分布式環(huán)境下提供各種基礎(chǔ)設(shè)施使得整個運維管理更加高效、科學、合理，并且極大的降低了運維成本和復(fù)雜性。

4.結(jié)論

本文通過分析分布式環(huán)境下微服務(wù)架構(gòu)相對于單體架構(gòu)的優(yōu)勢以及其遷移需解決問題提出微服務(wù)基礎(chǔ)設(shè)施總體設(shè)計，分析了基礎(chǔ)設(shè)施關(guān)鍵組件的功能，舉例了其在運維管理中的應(yīng)用。當然微服務(wù)架構(gòu)的實踐還存在很多待深入研究的問題，比如其在機器學習、大數(shù)據(jù)挖掘等分布式計算場景的應(yīng)用，這些還需要今后在實踐中不斷探索、學習。