讀者需具備基礎：

- 已對微服務有一定實踐經驗，使用過一種以上的微服務開發框架
- 對 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 微服務框架