導(dǎo)讀

創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),五原企業(yè)網(wǎng)站建設(shè),五原品牌網(wǎng)站建設(shè),網(wǎng)站定制,五原網(wǎng)站建設(shè)報價,網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,五原網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競爭力。可充分滿足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。

近期與幾位企業(yè)用戶交流 Service Mesh 及其相關(guān)技術(shù)，大家對于它所展現(xiàn)的形態(tài)以及未來發(fā)展都表示出極大的興趣。但對當(dāng)下企業(yè)應(yīng)用現(xiàn)狀如何與 Service Mesh 整合到一起又表現(xiàn)出極大的困惑。本文力圖結(jié)合Service Mesh技術(shù)特性與企業(yè)應(yīng)用的實(shí)際情況，就 Service Mesh 如何應(yīng)對企業(yè)應(yīng)用給出博云自身的思考，歡迎有興趣的朋友一起討論。

在進(jìn)行詳細(xì)探討之前，我們首先回顧一下 Service Mesh 的定義：服務(wù)網(wǎng)格是一個用于處理服務(wù)間通信的基礎(chǔ)設(shè)施層，它負(fù)責(zé)為構(gòu)建復(fù)雜的云原生應(yīng)用傳遞可靠的網(wǎng)絡(luò)請求。在實(shí)踐中，服務(wù)網(wǎng)格通常實(shí)現(xiàn)一組與應(yīng)用程序部署在一起的輕量級的網(wǎng)絡(luò)代理，但對應(yīng)用程序來說是透明的。

從定義中我們可以清晰地看到 Service Mesh 的技術(shù)定位：“處理服務(wù)間通信的基礎(chǔ)設(shè)施層”。因此我們不能希望它幫我們簡化開發(fā)測試場景面臨的挑戰(zhàn)（DevOps 或者應(yīng)用服務(wù)化，當(dāng)然一定程度上可以解耦應(yīng)用與基礎(chǔ)中間件的調(diào)用關(guān)系，稍后會詳細(xì)說明），或者解決應(yīng)用部署場景的問題（部署問題由容器編排平臺處理更加合適）。

總體來說，Service Mesh 專注業(yè)務(wù)應(yīng)用部署上線后期的通信領(lǐng)域問題，同時一定程度上解耦業(yè)務(wù)單元與基礎(chǔ)中間件的調(diào)用關(guān)系（例如服務(wù)注冊中心）。如圖所示：

圍繞 Service Mesh 所聚焦的領(lǐng)域以及如何服務(wù)于企業(yè)級應(yīng)用，本文重點(diǎn)探討4個問題：

· Service Mesh 的技術(shù)特性；
· Service Mesh 與企業(yè)應(yīng)用的整合之道；
· Service Mesh 的部署管理形態(tài)；
· Service Mesh 的遠(yuǎn)景形態(tài)。

Service Mesh技術(shù)特性

考慮到目前 Service Mesh 落地方式集中在以容器化為首的 PaaS 領(lǐng)域之內(nèi)，因此我們也將重點(diǎn)基于容器化方案探討 Service Mesh 所具備的技術(shù)特性。

從 Service Mesh發(fā) 展來看，無論是基礎(chǔ)的 Docker 運(yùn)行環(huán)境，還是以Kubernetes 為“事實(shí)標(biāo)準(zhǔn)”的容器編排環(huán)境，都是 Service Mesh 能夠快速發(fā)展的基石。以 Kubernetes 為例，Service Mesh 并非技術(shù)上的創(chuàng)新，更多是利用 CRD 特性對 Kubernetes 的擴(kuò)展以及傳統(tǒng)技術(shù)的整合（防火墻、DNS服務(wù)發(fā)現(xiàn)等）。以 Isito 為例， Istio 基于引入的標(biāo)準(zhǔn)規(guī)范以及 Kubernetes CRD 特性自定義幾十種自身的資源，并依賴 kubectl CLI 命令工具對這些 CRD 進(jìn)行統(tǒng)一管理。

我們發(fā)現(xiàn)Service Mesh 的技術(shù)特性主要體現(xiàn)在5個方面：容器編排環(huán)境；數(shù)據(jù)代理控制；配置管理分發(fā)；服務(wù)鏈路追蹤；服務(wù)通信安全。

容器編排環(huán)境

結(jié)合 Service Mesh 落地的幾個方案來看，容器編排環(huán)境是 Service Mesh 能夠落地的必備要素之一（這里暫時不深入討論容器化采用的技術(shù)原理，如namespace，AUFS等）。容器化編排環(huán)境的特性能夠?qū)⑵髽I(yè)應(yīng)用或者業(yè)務(wù)實(shí)例組織成方便管理和尋址的業(yè)務(wù)單元，方便系統(tǒng)化的方式訪問這些單元。這里同樣暫時忽略 Mesh 外圍對接的各種 Adapter。

數(shù)據(jù)代理控制

從 Service Mesh 定義中可知，其本身是一個與應(yīng)用綁定在一起的輕量級網(wǎng)絡(luò)代理，該代理攔截所有服務(wù)請求的出站和入站流量，并依賴控制層面標(biāo)準(zhǔn)化接口提供的規(guī)則信息（最終轉(zhuǎn)化成防火墻內(nèi)的路由配置）進(jìn)行流量的轉(zhuǎn)發(fā)和控制，同時對調(diào)用日志、調(diào)用鏈路、響應(yīng)時長進(jìn)行記錄和匯報。

配置管理分發(fā)

Service Mesh 為了保證數(shù)據(jù)代理功能的獨(dú)立性，將配置與數(shù)據(jù)代理進(jìn)行解耦。配置也稱作控制層面，負(fù)責(zé)從容器環(huán)境搜集服務(wù)信息，并且以高度抽象化的標(biāo)準(zhǔn)接口提供給數(shù)據(jù)代理服務(wù)，為流量轉(zhuǎn)發(fā)提供可靠的路由依賴。同時控制層面面向用戶提供“聲明式”的規(guī)則定義，這些規(guī)則會存儲在容器平臺中，同時生成路由轉(zhuǎn)發(fā)的流量控制規(guī)則，并且以接口的形式提供給數(shù)據(jù)代理服務(wù)，為路由轉(zhuǎn)發(fā)的流量控制提供管理依據(jù)。例如在 Istio 中規(guī)則定義表現(xiàn)為 Istio 定義的 CRD 資源，規(guī)則生效接口表現(xiàn)為 Policy 提供的 XDS 接口。

服務(wù)鏈路追蹤

服務(wù)鏈路在 Service Mesh 中是基礎(chǔ)必備的功能。它的實(shí)現(xiàn)依賴兩部分：數(shù)據(jù)采集和鏈路呈現(xiàn)。數(shù)據(jù)采集主要依賴數(shù)據(jù)代理服務(wù)進(jìn)行服務(wù)請求攔截或者轉(zhuǎn)發(fā)時記錄服務(wù)請求的源IP地址、目的IP地址和對應(yīng)的服務(wù)名稱等有效信息；鏈路呈現(xiàn)依賴于分布式跟蹤系統(tǒng)，將采集的服務(wù)調(diào)用鏈路信息存儲在分布式跟蹤系統(tǒng)中，做集中呈現(xiàn)，例如 Zipkin 等。

服務(wù)通信安全

安全是企業(yè)應(yīng)用必然關(guān)注的因素之一，那么 Service Mesh 在安全領(lǐng)域提供哪些技術(shù)特性呢？Service Mesh 作為 PaaS 的擴(kuò)展實(shí)現(xiàn)，主要從3個層面為企業(yè)應(yīng)用安全保駕護(hù)航：

第一：基于TLS的雙向通行加密。例如Isito中可以在部署時打開TLS雙向認(rèn)證配置，并且依賴獨(dú)立的證書管理功能，實(shí)現(xiàn)服務(wù)通信過程的加密。

第二：權(quán)限控制訪問。Service Mesh為了保證服務(wù)調(diào)用的合法性，提供了權(quán)限訪問控制。例如Isito中基于RBAC的權(quán)限訪問控制；

第三：基于策略的黑白名單訪問控制以及服務(wù)熔斷控制。

當(dāng)然僅僅依靠 Service Mesh 保證企業(yè)應(yīng)用的安全是不夠的，同樣需要借助其他軟硬件手段，例如防火墻、網(wǎng)絡(luò)安全監(jiān)控、內(nèi)部異常檢測等，具體不在本文討論范圍。

Service Mesh與企業(yè)級應(yīng)用整合之道

在了解 Service Mesh 技術(shù)特性以后，我們重點(diǎn)來聊一下 Service Mesh 如何與企業(yè)級應(yīng)用整合。

在具體展開之前，首先我們說一下企業(yè)應(yīng)用的現(xiàn)狀與特性：根據(jù) Gartner 對當(dāng)前 PaaS 市場的統(tǒng)計調(diào)研結(jié)果，大部分企業(yè)處于傳統(tǒng)應(yīng)用（物理或者虛擬化）向容器化轉(zhuǎn)型的階段，不同行業(yè)都期望能夠把自己的應(yīng)用合理地遷移到云端（重點(diǎn)考慮 PaaS 領(lǐng)域）。但對于遺留的企業(yè)系統(tǒng)，尤其是核心系統(tǒng)上 PaaS 多多少少有一定的顧慮，因此我們把企業(yè)應(yīng)用的部署形態(tài)分為三個等級（等級沒有先后之分）：

第一：核心系統(tǒng)，短期（未來幾年）不會考慮容器化處理，例如金融行業(yè)的核心數(shù)據(jù)庫和核心系統(tǒng)等；

第二：支撐系統(tǒng)，當(dāng)下以虛擬化居多，可能會嘗試服務(wù)容器化；

第三：外部系統(tǒng)，虛擬化為主，期望遷移到 PaaS 平臺；而目前無論是項目交付還是產(chǎn)品自研，絕大多數(shù)圍繞第三類應(yīng)用系統(tǒng)展開，這也是我們當(dāng)下考慮的重點(diǎn)。

其次我們來分析一下企業(yè)應(yīng)用的特性：企業(yè)應(yīng)用在大多數(shù)情況下是以業(yè)務(wù)為驅(qū)動的。按照這個層面考慮，構(gòu)建業(yè)務(wù)系統(tǒng)時存在兩種情況：一體化應(yīng)用和服務(wù)化應(yīng)用。

針對一體化應(yīng)用，與 Service Mesh 進(jìn)行整合時，并不能發(fā)揮 Service Mesh 的功效（由于業(yè)務(wù)集中處理，所有功能及非功能系統(tǒng)全部集中在代碼本身，一定程度上 Service Mesh 集成意義不大）。因此我們重點(diǎn)考慮服務(wù)化應(yīng)用與 Service Mesh 的整合。這樣考慮的緣由是基于微服務(wù)或者云原生應(yīng)用是構(gòu)建系統(tǒng)的趨勢所在，也更符合應(yīng)用形態(tài)的發(fā)展規(guī)律。

結(jié)合企業(yè)級應(yīng)用的現(xiàn)狀以及特性，我們把 Service Mesh 與企業(yè)應(yīng)用的整合劃分為四個階段，如下圖所示：

應(yīng)用服務(wù)化

應(yīng)用服務(wù)化與大家所說的微服務(wù)構(gòu)建有一些不同之處。整體來講，應(yīng)用服務(wù)化還是利用微服務(wù)拆分原則，對應(yīng)用業(yè)務(wù)單元進(jìn)行服務(wù)拆分，同時確定服務(wù)間交互依賴的支撐組件。

不同的地方在于服務(wù)直接的交互組件的選型，不再采用 Spring Cloud、Dubbo 或者其他組件提供的支撐功能（如服務(wù)注冊與發(fā)現(xiàn)，服務(wù)鏈路跟蹤，負(fù)載均衡等），而是依賴容器平臺（如 kubernetes 提供的服務(wù)注冊發(fā)現(xiàn)，負(fù)載均衡）和 Service Mesh。此種做法的目的是將應(yīng)用支撐組件下沉，幫助客戶從技術(shù)調(diào)研與選型的細(xì)節(jié)中解脫出來，完全從業(yè)務(wù)角度考慮問題。業(yè)務(wù)之外的事情交由 PaaS 平臺、Service Mesh 統(tǒng)一處理。

應(yīng)用服務(wù)化，有兩個目的：拆分應(yīng)用業(yè)務(wù)單元和梳理業(yè)務(wù)單元調(diào)用鏈。(需要進(jìn)一步說明：摒棄服務(wù)注冊與發(fā)現(xiàn)組件，并非拋棄其能力，而是更換一種更方便的實(shí)現(xiàn)方式。開發(fā)環(huán)境下，各個服務(wù)聯(lián)調(diào)直接利用 HTTP 或者其他協(xié)議的調(diào)用框架進(jìn)行遠(yuǎn)程服務(wù)調(diào)用即可；測試或者生產(chǎn)環(huán)境中，將服務(wù)地址替換為容器平臺注冊的 Service 地址，從而具備服務(wù)注冊發(fā)現(xiàn)，服務(wù)負(fù)載的能力)。

當(dāng)然針對之前已經(jīng)基于 Spring Cloud 或者 Dubbo 開發(fā)的業(yè)務(wù)系統(tǒng)，在不改變原有架構(gòu)的基礎(chǔ)上同樣可以與 Service Mesh 進(jìn)行整合，但是在服務(wù)治理層面會存在一定沖突，目前來看，最有效的解法是把支撐能力交給平臺本身，將業(yè)務(wù)與支撐解耦，實(shí)現(xiàn)徹底的服務(wù)化。

應(yīng)用容器化

上面已經(jīng)提到過，在當(dāng)下的落地實(shí)踐中容器化是 Service Mesh 能夠存在的必要條件（當(dāng)然可以非容器化，但代價無疑是巨大的）。應(yīng)用服務(wù)拆分后的容器化改造，目前有多種實(shí)現(xiàn)的方式。最直接的是利用 DevOps 工具鏈，構(gòu)建應(yīng)用服務(wù)容器鏡像。當(dāng)然針對不同平臺或者語言也可以進(jìn)行獨(dú)立實(shí)現(xiàn)，例如 Maven 的 docker 插件，github 提供的 CI 流程，Jenkins 提供的 pipeline 等都能夠很好的實(shí)現(xiàn)服務(wù)容器化操作，這里不展開討論。需要指出的是，服務(wù)容器化的重點(diǎn)在于構(gòu)建一套符合企業(yè)制度與風(fēng)格的控制流程規(guī)范，這其中技術(shù)因素不是主導(dǎo)因素，需要結(jié)合企業(yè)自身情況決定。

應(yīng)用Mesh整合

應(yīng)用服務(wù)化和應(yīng)用容器化能夠解決應(yīng)用向 PaaS 平臺遷移的絕大多數(shù)場景。但是前兩者僅僅解決了服務(wù)編排部署問題，并沒有對服務(wù)上線后的管理支撐提供更多的功能，而 Service Mesh 恰恰定位于這一領(lǐng)域。那么應(yīng)用如何與 Mesh 進(jìn)行整合呢？可以分四步進(jìn)行，如圖所示：

第一步，Service Mesh 與 PaaS 基礎(chǔ)設(shè)施整合。利用 PaaS 平臺強(qiáng)大的編排部署能力，部署Service Mesh（具體項目例如Isito）的控制層面，各個組件在啟動時會自動初始化 Mesh 所需的環(huán)境以及從 PaaS 平臺中搜集需要的信息，必要的時候，可以把 Mesh 作為 PaaS 平臺基礎(chǔ)設(shè)施的一部分。

第二步，配置 PaaS 平臺。使其具備Mesh中代理程序自動注入的功能（例如 Istio 自動注入Sidecar的配置），當(dāng)然該步驟可以省略，后續(xù)由用戶手動注入，目的在于攔截服務(wù)請求與轉(zhuǎn)發(fā)流量。

第三步，利用 PaaS 平臺直接部署業(yè)務(wù)應(yīng)用。此時應(yīng)用已經(jīng)與Mesh綁定在一起共享整個網(wǎng)絡(luò)棧資源，實(shí)現(xiàn)應(yīng)用與 Service Mesh 的初步整合。

第四步，利用第二步中部署的 Service Mesh 控制層面入口，設(shè)置服務(wù)通信規(guī)則，從而控制服務(wù)之間的通信，最終完成應(yīng)用與 Mesh 的整合。

Mesh管理控制

Service Mesh 管理控制是客戶介入服務(wù)間通信的唯一入口。而 Service Mesh 基于“聲明式”規(guī)則的控制將決定企業(yè)管理過程中更多的是規(guī)則的設(shè)定者，卻不具備對規(guī)則的有效性進(jìn)行實(shí)時校驗(yàn)的條件。因此需要結(jié)合其他外圍組件對當(dāng)前服務(wù)是否符合預(yù)期進(jìn)行監(jiān)測。例如對接 Prometheus，獲取服務(wù)的運(yùn)行數(shù)據(jù)（包括 tcp 連接數(shù)，請求成功數(shù)，請求鏈路時長等），并且基于 AlterManager 進(jìn)行告警策略的管理；或者對接 ELK 日志平臺，對服務(wù)調(diào)用的日志進(jìn)行統(tǒng)一分析管理。當(dāng)然還有其他系統(tǒng)，統(tǒng)一稱為 Adapter。

總體而言，應(yīng)用是數(shù)據(jù)的產(chǎn)生源頭，Service Mesh 負(fù)責(zé)服務(wù)通信控制，服務(wù)數(shù)據(jù)收集以及服務(wù)數(shù)據(jù)上報，其他平臺負(fù)責(zé)數(shù)據(jù)處理，三者通力合作，才能將 Service Mesh 切實(shí)和企業(yè)應(yīng)用整合在一起，發(fā)揮它大的功效。

Service Mesh部署管理形態(tài)

Service Mesh部署形態(tài)從當(dāng)下的技術(shù)實(shí)現(xiàn)考慮，需要緊緊依賴 PaaS 平臺的底層實(shí)現(xiàn)，尤其是對容器化環(huán)境的依賴。無論是單集群還是夸集群的部署，官方文檔都提供了詳盡的部署方案，這里不過多說明，可以參考 Istio 的實(shí)現(xiàn)（https://preliminary.istio.io/zh/docs/concepts/multicluster-deployments/）。

Servie Mesh 的管理形態(tài)最好的方式是與 PaaS 整合在一起，在 PaaS 自身的能力之上，增加服務(wù)治理的各種功能，有助于幫助 PaaS 平臺更好的整合資源。Service Mesh 同樣是對于 PaaS 的補(bǔ)充，從而形成全套的 PaaS 解決方案：包括 DevOps 工具形態(tài)，PaaS 編排部署形態(tài)，以及 Mesh 的服務(wù)治理形態(tài)。這時就具備了對應(yīng)用生命周期各個階段的集中控制能力。

Service Mesh遠(yuǎn)景形態(tài)

這個是大膽的預(yù)測了，無論從技術(shù)角度考慮，還是行業(yè)發(fā)展趨勢，Service Mesh 在未來必然會成為服務(wù)治理的主要工具之一。它對于企業(yè)應(yīng)用大的優(yōu)勢是解耦應(yīng)用業(yè)務(wù)，企業(yè)能夠徹底從業(yè)務(wù)角度考慮問題。相比純粹的微服務(wù)架構(gòu)，又向前邁了一步，同時與容器編排部署平臺的集成，最終有可能成為企業(yè)級應(yīng)用編排部署和服務(wù)治理的標(biāo)準(zhǔn)形態(tài)。

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

分享題目：ServiceMesh在企業(yè)級應(yīng)用的生存之道-創(chuàng)新互聯(lián)
網(wǎng)站鏈接：http://www.rwnh.cn/article18/cepegp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站內(nèi)鏈、軟件開發(fā)、云服務(wù)器、營銷型網(wǎng)站建設(shè)、企業(yè)網(wǎng)站制作、網(wǎng)站改版

廣告

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