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

讀者需具有基礎：

- 已對微服務有必定實踐經驗，使用過一種以上的微服務開發框架
- 對 Service Mesh 有必定理解，知道他是什麼，運做機制，能夠經過我過去的分享來了解[Service Mesh 在華爲公有云的實踐](https://gitbook.cn/books/5a1e7dca387c5b4ee351790b/index.html)

話題範圍：

- 不會討論灰度發佈，限流，熔斷，負載均衡等微服務實現技術，這些 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 語言或者 nodejs 等，並將一部分開發團隊從框架中解放。

.Net

mesher 支持.Net 應用接入到服務網格，能夠與其餘語言打通，在一套系統下進行治理。

使用 ServiceComb 構建微服務系統

ServiceComb 可獨立部署，不會綁定部署系統，不管虛機仍是容器仍是 kubernetes 平臺，均可以部署，部署限制很低。

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

我以實際的例子來說述用戶使用 ServiceComb 的實踐經驗。

梅斯醫學

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

​

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

如下是改造後的架構

​

改造後收益：

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

同濟大學

本來的系統是獨立的煙囪式單體，業務能力沒法複用，若是想應變不斷變化的需求就須要將單體進行拆分，微服務化，以快速複用解耦的已存在的業務能力，前臺選擇 nodejs 進行開發，使用服務網格接入，然後臺所有使用 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 的讀者，能夠閱讀咱們的項目介紹參與到社區：

- https://github.com/apache/servicecomb-mesher: 服務網格- https://github.com/apache/servicecomb-kie：配置管理中心- https://github.com/go-chassis/go-chassis： go 微服務框架- https://github.com/apache/servicecomb-java-chassis： java 微服務框架