Apache ServiceComb 服務網格與微服務開發框架融合實踐

更多精彩內容請關注我們

讀者需具備基礎：

已對微服務有一定實踐經驗，使用過一種以上的微服務開發框架。
對 Service Mesh 有一定理解，知道他是什麼，運作機制，可以通過我過去的分享來了解Service Mesh 在華爲公有云的實踐（https://dwz.cn/cKA6NCrw）

話題範圍：

不會討論灰度發佈、限流、熔斷、負載均衡等微服務實現技術，這些 ServiceComb 全部都擁有。
ServiceComb 包含微服務開發框架與配套的管理面服務，是一套微服務解決方案，但不解決 DevOps、應用生命週期管理等，這裏不做討論。

壹景

背景

2018 年被稱爲 Service Mesh 之年，層出不窮的服務網格產品，越來越多的廠商參與進來，提供自己的解決方案。

其中的 Istio 甚至成爲了服務網格代名詞。但目前我看到的是，經過了 2 年的發展，Istio 還未被大規模的使用於生產中。

Spring Cloud、Dubbo 等發展了多年的框架依然有着存量用戶，不容易切換到服務網格，因爲這勢必意味着 2 套解決方案共同存在，那麼如何平滑過渡到服務網格也是這些框架的用戶關心的事。

這次分享我將講述 Apache ServiceComb 在開發框架和服務網格的融合實踐，也會看到 Spring Cloud 如何向服務網格平滑過渡。

貳

ServiceComb 架構與實現機制

Apache ServiceComb 在今年推出了服務網格（https://github.com/apache/servicecomb-mesher），配置管理（https://github.com/apache/servicecomb-kie）等多個新服務。

我們在 17 年看到服務網格的興起後便開始了服務網格的研發，並於年底在華爲雲上線商用，今年將它開源捐贈給 Apache 基金會，完善了 ServiceComb 的多語言能力。

得益於我們本來在 ServiceComb 開發中的積累（Go、Java 語言開發框架），我們快速的基於原本的 Go 微服務開發框架進行了服務網格的開發，以此來實現多語言的接入。

這是當前組件的全景圖，Mesher 作爲服務網格方案可將服務接入到分佈式系統中，與 go chassis 和 java chassis 等開發出的微服務打通。

Service center

註冊發現中心，管理微服務及版本信息等元數據，並且可以管理框架生成出來的 Open API 文檔。而這也大大加強了團隊之間的合作效率，可以根據文檔來進行客戶端的開發和測試。

Kie

一個通用的配置管理中心，當前是獨立的服務，未來我們將會接入到配置管理中心，讓用戶可以在統一的中心進行配置管理（熔斷、限流等規則），並且能夠管理業務的配置。

go chassis 與 java chassis

2 個框架，都實現了一致的功能，以保證用戶體驗一致，比如熔斷、限流。可根據代碼自動生成 Open API 文檔並上傳到 Service center

以 go chassis 實現爲例，基本的運作機制如下：

不同協議請求進入到各協議 Server，Server 將具體的協議請求轉換爲 Invocation 統一抽象模型，並傳入 Handler chain，在這 chassis 已經默認實現了很多的 Handler，比如熔斷，限流等，最終再進入 Transport handler，使用具體的協議客戶端傳輸到目標。

生成的監控數據通過 http API 導出，由 Prometheus 收集處理

Archaius 爲動態配置框架，可從各種不同的 source 中讀取配置，比如 Kie。

Mesher

服務網格方案，Mesher 之所以能建立在 go chassis 之上快速建立起來，得益於 go chassis 的 invocation 概念

即 invocation 不感知協議，可以將協議轉換爲 invocation，而微服務相關的所有治理能力，都以 invocation 作爲標準，所以這些功能就可以完全複用，只需要擴展 Server 實現即可，代理服務將請求轉爲 invocation 後，後續的代碼就可以複用了。當前基於這個框架，Mesher 已支持 grpc 與 http 協議，也支持開發者自己定製。

Spring Cloud

提供Spring Cloud 的擴展組件（https://github.com/huaweicloud/spring-cloud-huawei），可以使其接入到 ServiceComb 管理面中，幫助 Spring Cloud 用戶平滑向多語言，服務網格轉型，Java 不再是開發微服務唯一的選擇，可平滑過渡到使用 Go 語言或者 Node js 等，並將一部分開發團隊從框架中解放。

.Net

Mesher 支持.Net 應用接入到服務網格，可以與其他語言打通，在一套系統下進行治理。

叄

使用 ServiceComb 構建微服務系統

ServiceComb 可獨立部署，不會綁定部署系統，無論虛機還是容器還是 kubernetes 平臺，都可以部署，部署限制性很低。

使用統一的微服務解決方案可打通公司內部各個業務服務的能力，不斷複用當前能力，以更快的應對需求並且通過業務暴露出的數據做更多的業務整合，以構建更加強大的業務平臺。

下面，我以實際的例子來講述用戶使用 ServiceComb 的實踐經驗。

梅斯醫學

多年的 PHP 技術積累，很多程序都是 PHP 的，面臨微服務化改造非常困難，而基於 java 技術新開發的業務又要快速開發以應對市場變化。那麼微服務化是非常重要的，爲了能讓服務共同協作。

java 可以選用 java chassis 進行微服務化。對於存量 PHP 業務，要求穩定，不碰業務代碼，零侵入完成微服務化；對於新開發業務，要求高性能，細化到業務的治理和監控。在這個場景中，一個統一的微服務解決方案變得至關重要。

以下是改造後的架構

改造後收益：

在原來的框架中，PHP 作爲動態語言難以承載未來業務量的上升，在進行接入改造後，由於java chassis 是一種高性能 java 微服務開發框架，因此整體的性能得到了提升，而更多的語言選擇意味着業務團隊可以自由選擇適合服務的語言進行實現，並能夠在統一的系統中進行治理。對外暴露使用 Edge Service，一種網關開發框架，與業務部署在同一網絡，可將業務能力暴露給其他應用。

同濟大學

原本的系統是獨立的煙囪式單體，業務能力無法複用，如果想應變不斷變化的需求就需要將單體進行拆分，微服務化，以快速複用解耦的已存在的業務能力，前臺選擇 Node js 進行開發，使用服務網格接入，而後臺則全部使用 java chassis 開發。

同濟使用了多種雲服務構建了自己的平臺服務，其中的 EI 服務，雲容器引擎等商用方案不在本次話題內。微服務引擎就是 ServiceComb 的商用方案名稱。

肆

爲什麼開發框架依然是必要的

並非所有服務都適合服務網格。由於服務網格是應用代理服務，用戶態與內核態之間的數據複製導致性能有所下降，而下降的程度基本與一次請求調用傳輸的 payload 大小相關，越大性能下降越明顯。而較小的尺寸，性能下降很小。所以對於請求併發量很大，且處理大尺寸請求的接口最好不要應用服務網格，比如圖片，大量數據。開發框架依然是這種場景的首選。

即便使用用戶態協議棧，避免了內核態用戶態切換以及數據拷貝，但這也並非是一個完美的方案（https://blog.cloudflare.com/why-we-use-the-linux-kernels-tcp-stack/），所以在某些場景下，使用服務網格將會一直面臨性能上的降低，而且當前沒有好的解決方案。

使用 ServiceComb，如果是新項目可以一開始全部使用服務網格，在遇到性能瓶頸時再考慮使用開發框架進行優化。

伍

總結

ServiceComb 在微服務領域多年的積累使我們能夠快速的應對服務網格的興起，並且快速構建出開發框架與服務網格融合的解決方案。在用戶對性能有要求的情況下能夠使用框架來滿足，並對其他語言提供了兼容，而使用 Spring Cloud 的用戶也可以接入到 ServiceComb 中使用服務網格或是 go 語言框架。

爲何架構設計如此重要，因爲他幫助你解決非功能性的問題，並促進業務的成功，爲業務保駕護航。

微服務作爲一種架構模式，給了一種架構指導，也是一種最佳實踐。而該模式的引入幫你解決問題的同時卻又引入不少問題需要解決，需要一套強大的框架來幫助你完成這個架構轉型，讓你更加聚焦於業務功能，免去架構設計上的投入，ServiceComb 的微服務解決方案便是爲了解決微服務帶來的複雜性而生。

微服務化給業務帶來的一個很大的價值是將企業內部的業務能力進行解耦後複用，打通數據，以快速應對變化的市場需求。而隨着多年的發展，公司內部通常會積累相當多的技術棧，語言，這些系統(即異構系統)間通常是不產生關係的，數據無法打通，將這些業務進行整合，打破煙囪成爲了亟待解決的問題，ServiceComb 在這方面提供了一個完整的方案，可以供企業轉型時使用。

對於想深入瞭解 ServiceComb 的讀者，可以閱讀我們的項目介紹參與到社區：