導讀

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

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

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

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

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

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

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

Service Mesh技術特性

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

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

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

容器編排環(huán)境

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

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

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

配置管理分發(fā)

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

服務鏈路追蹤

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

服務通信安全

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

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

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

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

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

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

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

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

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

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

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

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

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

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

應用服務化

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

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

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

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

應用容器化

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

應用Mesh整合

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

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

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

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

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

Mesh管理控制

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

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

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

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

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

Service Mesh遠景形態(tài)

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

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

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

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

廣告

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