Istio微服務平臺整合實踐

業務服務，大部分的業務服務都已經實現了微服務化和無狀態，採用Docker容器部署在Kubernetes叢集中，利用Kubernetes的容器管理能力進行服務部署、彈縮。但也有部分服務只做了容器化，但並未進行微服務改造，此類服務屬於SOA架構，一個服務可能對外暴露多個業務API，這和敖小劍老師在《SOFAMesh中的多協議通用解決方案[1]》系列文章中提到的情況是類似的。

一些有狀態的公共服務，例如資料庫，FTP伺服器，共享快取等，目前未放入到Kubernetes叢集中，但業務服務對這些公共服務存在大量的依賴。

其他未納入Kubernetes叢集的服務，如遺留系統和第三方系統提供的服務。某些業務服務和這些服務之間存在互相訪問的需求。

對外部請求進行效能資料收集和統計分析。

呼叫認證服務對外部請求進行登入驗證。

實現了限流、熔斷、黑白名單等功能。

可以透過分流規則實現應用的灰度釋出。

在系統的初始階段，大部分的微服務都是基於Java編寫的，我們透過SDK封裝了服務發現，重試，限流，熔斷等用於服務間點對點通訊的邏輯提供給各個業務微服務使用。但隨著系統的發展，越來越多微服務開始採用Golang編寫，還有相當一部分基於Python的微服務，而且作為一個平臺，可以預見到將來還可能會有更多其他語言。為每一種語言編寫一套SDK的方案漸漸變得難以維護。將微服務的通訊層下沉到Mesh層是一個趨勢。

在API Gateway處可以對外部請求的效能資料進行統計分析，但無法對系統內部各個微服務之間呼叫的效能資料進行收集處理。如果採用侵入式的方案，則需要在各個語言和框架中採用一套標準的介面，並且要針對不同語言編寫對應的SDK，維護工作量很大，而且對於業務微服務的編碼有較大的限制，因此採用sidecar方式對微服務之間呼叫效能資料進行收集是一個更為合理的方式。

透過在API Gateway處使用分流規則來實現灰度釋出的方案有較大限制，只能對應用整體進行分流，而無法對應用中的單個微服務的不同版本進行分流配置。因此基本上無法透過灰度釋出來實現微服務粒度的快速升級迭代。