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

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

中圖分類號(hào)：TP311.5 文獻(xiàn)標(biāo)識(shí)碼：A DOI：10.3969/j.issn.1003 6970.2016.05.023

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

0.引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.3遷移需解決問題

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1）性能和可伸縮性

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

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

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

2.1.2DevOps基本原則

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

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

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

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

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

2.3.1持續(xù)交付平臺(tái)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.結(jié)論

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