企業(yè)基于集中交換模式的信息系統(tǒng)服務(wù)網(wǎng)格化實(shí)踐

一、背景傳統(tǒng)的企業(yè)信息系統(tǒng)體系多采用集中交換架構(gòu)，它結(jié)構(gòu)簡單，部署方便，但故障容錯(cuò)能力及彈性擴(kuò)展能力不足。隨著業(yè)務(wù)的不斷發(fā)展，用戶增加，并發(fā)訪問量和交易量呈爆發(fā)式增長，業(yè)務(wù)逐漸精細(xì)化拆分，業(yè)務(wù)需求更明確更專業(yè)，對業(yè)務(wù)需求的響應(yīng)更敏捷，傳統(tǒng)的集中式架構(gòu)無法滿足我們的業(yè)務(wù)發(fā)展，通過信息系統(tǒng)分布式服務(wù)化轉(zhuǎn)型來快速響應(yīng)需求已成為必然趨勢。由傳統(tǒng)的集中交換模式向分布式點(diǎn)對點(diǎn)交換模式轉(zhuǎn)變，體系上發(fā)生了巨大的變化，同時(shí)也面臨巨大的調(diào)整和風(fēng)險(xiǎn)。本文將結(jié)合某企業(yè)級分布式服務(wù)平臺項(xiàng)目實(shí)踐，提出一套適合傳統(tǒng)企業(yè)的信息系統(tǒng)服務(wù)網(wǎng)格化轉(zhuǎn)型實(shí)施路徑。二、服務(wù)網(wǎng)格技術(shù)介紹近年來，以SpringCloud、Dubbo、ServiceMesh服務(wù)網(wǎng)格為代表的微服務(wù)框架成為業(yè)界主流。SpringCloud、Dubbo等微服務(wù)框架為Java強(qiáng)綁定，基于SDK模式需侵入到應(yīng)用的業(yè)務(wù)邏輯代碼當(dāng)中。ServiceMesh服務(wù)網(wǎng)格則另辟蹊徑，基于代理模式對服務(wù)進(jìn)行管理，不入侵應(yīng)用邏輯，不關(guān)注具體實(shí)現(xiàn)。企業(yè)級應(yīng)用信息系統(tǒng)服務(wù)網(wǎng)格化過程中，集中交換式應(yīng)用系統(tǒng)普遍面臨以下幾個(gè)難點(diǎn)：1.技術(shù)多樣性：多種開發(fā)語言和技術(shù)框架并存：C++、Java等，無法采用某一種SDK實(shí)現(xiàn)多平臺的服務(wù)集成；2.集成復(fù)雜性：系統(tǒng)業(yè)務(wù)邏輯復(fù)雜，系統(tǒng)間多層關(guān)聯(lián)依賴，采用SDK式模式會進(jìn)一步增加應(yīng)用代碼復(fù)雜度；3.基礎(chǔ)能力共性化：避免各系統(tǒng)服務(wù)化改造涉及的服務(wù)注冊發(fā)現(xiàn)、服務(wù)鑒權(quán)、服務(wù)流控、灰度發(fā)布、鏈路跟蹤等基礎(chǔ)服務(wù)能力重復(fù)建設(shè)?；谝陨想y點(diǎn)，我們選定ServiceMesh作為集中交換式系統(tǒng)進(jìn)行服務(wù)化改造整合的技術(shù)基礎(chǔ)。ServiceMesh是用于處理服務(wù)間通信的基礎(chǔ)設(shè)施層，用于在原生應(yīng)用復(fù)雜的服務(wù)拓?fù)渲袑?shí)現(xiàn)可靠的請求傳遞。在實(shí)踐中，ServiceMesh是一組與應(yīng)用一起部署，但對應(yīng)用透明的輕量級網(wǎng)絡(luò)代理。ServiceMesh是通過獨(dú)立的進(jìn)程代理方式幫助應(yīng)用程序建立穩(wěn)定的通信機(jī)制，業(yè)務(wù)所有的流量都轉(zhuǎn)發(fā)到ServiceMesh的代理服務(wù)中，同時(shí)ServiceMesh還承擔(dān)了微服務(wù)框架所有的功能，包括服務(wù)注冊、發(fā)現(xiàn)、負(fù)載均衡、限流熔斷、鑒權(quán)、緩存等，除此之外，還承擔(dān)了上報(bào)日志、監(jiān)控的責(zé)任。（綠色表示服務(wù)，藍(lán)色表示代理，由代理形成了一個(gè)服務(wù)之間通訊的網(wǎng)絡(luò)）目前，業(yè)界主流的ServiceMesh相關(guān)的框架有兩個(gè)，分別是Google，IBM，Lyft都參與其中的Istio，以及Bouyant公司下的開源ServiceMesh框架Linkerd。其中Istio由于眾多大廠商和大型社區(qū)的支持，應(yīng)用更為廣泛。三、

分布式服務(wù)平臺實(shí)踐本項(xiàng)目通過引入基于服務(wù)網(wǎng)格技術(shù)的Istio實(shí)現(xiàn)構(gòu)建分布式服務(wù)框架，同時(shí)增加服務(wù)治理中心、服務(wù)運(yùn)營中心和服務(wù)交換網(wǎng)關(guān)，提供應(yīng)用由集中交換模式到分布式服務(wù)架構(gòu)轉(zhuǎn)型的基礎(chǔ)支持。整個(gè)分布式服務(wù)平臺的邏輯架構(gòu)如下：1）分布式服務(wù)框架分布式服務(wù)框架采用以Istio框架為核心的ServiceMesh技術(shù)體系基礎(chǔ)支撐（包括Envoy數(shù)據(jù)面、Pilot控制面和以Consul為統(tǒng)一服務(wù)注冊中心），實(shí)現(xiàn)服務(wù)的互聯(lián)互通和運(yùn)行期狀態(tài)實(shí)時(shí)管理與監(jiān)控。在應(yīng)用節(jié)點(diǎn)上部署代理，這些代理跟應(yīng)用之間沒有技術(shù)上的強(qiáng)綁定，開發(fā)人員只需按照原有的方式去開發(fā)，將服務(wù)暴露成HTTP協(xié)議，分布式服務(wù)代理基于流量劫持技術(shù)來完成服務(wù)鑒權(quán)、限流、路由等與業(yè)務(wù)無關(guān)的工作，這樣就形成了一個(gè)網(wǎng)格的網(wǎng)絡(luò)。分布式服務(wù)平臺在日常運(yùn)行過程當(dāng)中只關(guān)心服務(wù)心跳的更新及一些控制信息的下發(fā)，應(yīng)用將服務(wù)調(diào)用請求發(fā)送給代理，代理根據(jù)路由規(guī)則將請求發(fā)送給被調(diào)服務(wù)的某個(gè)實(shí)例，通訊實(shí)際上是由代理到代理之間直接發(fā)生的。2）服務(wù)治理中心服務(wù)治理中心為企業(yè)級服務(wù)治理的支撐工具，規(guī)范服務(wù)數(shù)據(jù)標(biāo)準(zhǔn)。推動制度規(guī)范建立、組織流程建設(shè)、管理流程優(yōu)化。主要包括四部分的管理：1.服務(wù)目錄管理：支持服務(wù)的定義，服務(wù)間依賴關(guān)系等管理功能，提供多維度的服務(wù)檢索視圖。2.元數(shù)據(jù)管理：服務(wù)的接口管理及接口的合約管理。3.服務(wù)生命周期管理：支持服務(wù)從定義，上線，變更，下線過程中的生命周期管理。4.服務(wù)SLA管理：支持服務(wù)的SLA定義及審計(jì)等相關(guān)管理功能。3）服務(wù)運(yùn)營中心服務(wù)運(yùn)營中心用于服務(wù)鑒權(quán)、路由和限流的配置管理以及服務(wù)運(yùn)行時(shí)監(jiān)控。可以監(jiān)控實(shí)時(shí)交易量請求成功率及實(shí)例狀態(tài)的相關(guān)信息，通過調(diào)用鏈分析每一個(gè)環(huán)節(jié)在每一臺服務(wù)上所消耗的時(shí)間，可以提高和優(yōu)化現(xiàn)有的運(yùn)維和應(yīng)急處置能力。4）服務(wù)交換網(wǎng)關(guān)集中式交換向分布式交換轉(zhuǎn)變必然是一個(gè)持久的過程，兩個(gè)體系必然長期共生共存。在這個(gè)過程中，分布式交換體系下的服務(wù)必然會與集中交換體系下的系統(tǒng)存在關(guān)聯(lián)，此時(shí)我們通過服務(wù)交換網(wǎng)關(guān)來完成兩個(gè)體系間的互聯(lián)互通，通過在服務(wù)交換網(wǎng)關(guān)實(shí)現(xiàn)兩個(gè)交換體系間的通訊協(xié)議和報(bào)文格式的轉(zhuǎn)換。四、

應(yīng)用系統(tǒng)集成模式針對傳統(tǒng)集中交換IT系統(tǒng)不同的架構(gòu)模式、節(jié)點(diǎn)規(guī)模以及自身的改造規(guī)劃，結(jié)合分布式服務(wù)平臺部署靈活、無侵入性的特點(diǎn)，應(yīng)用可選擇以下三種服務(wù)網(wǎng)格集成方案：1）直接集成直接集成模式即將分布式代理直接安裝到應(yīng)用節(jié)點(diǎn)上。主要針對架構(gòu)簡單、服務(wù)成熟度高、服務(wù)的節(jié)點(diǎn)數(shù)小于4個(gè)的服務(wù)。2）應(yīng)用網(wǎng)關(guān)集成應(yīng)用網(wǎng)關(guān)集成模式即在應(yīng)用部署的同時(shí)部署應(yīng)用網(wǎng)關(guān)，在應(yīng)用網(wǎng)關(guān)節(jié)點(diǎn)安裝代理。應(yīng)用網(wǎng)關(guān)作為對內(nèi)部服務(wù)訪問的統(tǒng)一出入口，可對內(nèi)外部的通訊協(xié)議進(jìn)行轉(zhuǎn)換，屏蔽服務(wù)內(nèi)部的復(fù)雜度。此集成模式主要針對結(jié)構(gòu)復(fù)雜、服務(wù)成熟度不高、服務(wù)節(jié)點(diǎn)數(shù)大于4個(gè)的情況。由于服務(wù)內(nèi)部復(fù)雜或服務(wù)成熟度不高，后期可能會對服務(wù)進(jìn)行拆分和調(diào)整，使用應(yīng)用網(wǎng)關(guān)集成模式，對服務(wù)調(diào)用方的影響較小。3）服務(wù)交換網(wǎng)關(guān)集成服務(wù)交換網(wǎng)關(guān)集成模式，主要針對對集中交換模式依賴較重、暫時(shí)無法進(jìn)行服務(wù)網(wǎng)格化的應(yīng)用系統(tǒng)，通過服務(wù)交換網(wǎng)關(guān)與分布式服務(wù)平臺內(nèi)的系統(tǒng)進(jìn)行交互。服務(wù)交換網(wǎng)關(guān)對接收的報(bào)文信息進(jìn)行協(xié)議轉(zhuǎn)換和報(bào)文格式轉(zhuǎn)換，為分布式體系和集中交換體系充當(dāng)中間媒介。五、

平臺應(yīng)急處置方案分布式服務(wù)體系下點(diǎn)對點(diǎn)交換消除了集中交換不可避免的單點(diǎn)故障，天然具備高可用優(yōu)勢。但是分布式服務(wù)平臺建設(shè)過程中引入了大量的新技術(shù)和新產(chǎn)品，這些技術(shù)和產(chǎn)品本身也在快速迭代和更新中，同時(shí)系統(tǒng)服務(wù)化后應(yīng)用節(jié)點(diǎn)幾何級增長，對運(yùn)維提出了更高的要求。平臺集中服務(wù)注冊管控和分布式通訊代理如果出現(xiàn)故障，將對分布式體系安全運(yùn)營造成影響，必須做好極端情況下的應(yīng)急處置響應(yīng)。一方面，平臺設(shè)計(jì)上各組件均采用集群高可用部署，通訊代理啟用本地緩存，在網(wǎng)絡(luò)故障無法與平臺通訊時(shí)仍然能保持服務(wù)訪問通訊能力。另一方面，我們要求所有服務(wù)在集成接入時(shí)，虛擬機(jī)服務(wù)預(yù)留F5應(yīng)急訪問能力，容器云服務(wù)預(yù)留Ingress應(yīng)急訪問能力，當(dāng)服務(wù)代理出現(xiàn)故障甚至極端情況下整個(gè)分布式服務(wù)平臺不可用時(shí)，通知各服務(wù)請求方切換到通過服務(wù)提供方的F5或Ingress進(jìn)行訪問。對于同時(shí)接入集中交換體系和分布式