雲原生時代，微服務到底應該怎麼玩兒？

在微服務誕生之初，並無太多方案的選擇：選一個註冊中心用來作服務註冊和發現，經過客戶端SDK進行負載均衡和容錯，再搭配上日誌、監控、調用鏈全套觀測手段，一套微服務架構便創建起來了。

做爲最流行的業務開發語言，Java體系裏誕生了不少微服務架構，例如Spring Cloud。使用Spring Cloud，Spring技術棧的開發人員能夠快速的開發和管理微服務，豐富的功能讓其餘語言體系的開發者們羨慕不已。

在雲原生時代，Kubernetes快速普及，除了解決微服務所須要的應用編排、伸縮、保活等功能外，Kubernetes裏自己還帶了服務發現、配置管理、負載均衡和網關。既然這樣，那麼是否就能夠再也不注重註冊中心和服務治理框架，只基於Kubernetes構建微服務系統呢？

不少公司進行了這方面的嘗試，嘗試後發現從治理功能豐富度、大規模集羣效率等方面，仍是有不太滿意的地方。因而，後來又誕生了治理功能更爲豐富的服務網格架構，讓Kubernetes的服務治理能力極大加強，這些項目很快便獲得了大範圍的關注，例如Istio。

那麼，在雲原生時代，咱們的微服務體系到底應該怎麼建設和維護呢？

Kubernetes良好的應用編排能力，使其成爲微服務部署、伸縮、管理的最佳工具。假如是爲新增業務作技術選型，建議都直接使用Kubernetes和容器來部署和管理應用，而不是還使用物理服務器或者虛擬機。而關於服務治理，目前會有以下選擇：

只使用Kubernetes：

Kubernetes裏自己具有服務發現、配置管理、負載均衡和網關，這使得看起來只使用Kubernetes就能夠把微服務系統搭建起來。不過，這種方式存在問題。例如：

• 流量治理能力不足——缺少熔斷能力，沒有灰度控制能力；
• 大規模使用時的性能問題——基於Kubernetes Service的服務發現過程須要通過Iptables或IPVS的查找過程，集羣規模大時性能影響會比較明顯。

另外，不少觀測功能也都須要必定的代碼集成才能夠發揮做用。

使用Kubernetes部署+Spring Cloud（或Dubbo等）服務治理：

這種方式是筆者認爲目前最成熟的一種方式，能夠充分利用Kubernetes和Spring Cloud（或Dubbo等）自身的優勢。這種方式性能好、功能完備，也已經有大量穩定的線上案例。不過這裏面也會涉及到一個問題：語言和框架的依賴——Java之外的其餘語言都缺少完備的服務治理框架。

使用Kubernetes部署+Istio（或Linkerd等）服務治理：

服務網格是這兩年贏得最多關注的方式，完全把業務和服務治理邏輯切分開。這種方式沒有語言和框架依賴，應用不用修改代碼邏輯，只要接入網格就可使用網格提供的全套流量管理、策略管理、觀測能力和安全能力。京東雲內部已經有上百個線上服務運行在服務網格里，利用網格技術減小了這些服務接入安全、觀測、流量管理等功能的接入成本，經過此過程也積累了不少優化和運維經驗。不過，網格架構的複雜性，和通過兩層網絡代理引入的延遲，仍然是不可迴避的問題。

下面讓咱們再詳細看一下後兩種方式。

Kubernetes部署+Spring Cloud服務治理

對於Java業務研發工程師而言，採用這種方式的感受是Spring Cloud太「簡單」了，而Kubernetes太「難」了。

Spring Cloud很「簡單」。標準的Spring Boot開發方式，引入幾個包，服務發現、負載均衡、熔斷就都有了。業務研發工程師便開開心心拆分服務去了。等拆完服務真上線跑一段時間，才發現Spring Cloud太難了。監控線上系統是否存在異常這個工做，比以前監控單體服務複雜好幾個量級。一旦線上有點問題，想查一查，都不知道該上哪一個服務去查。調用鏈看起來很強大，用起來又不那麼容易。還可能出現過這樣的尷尬：老闆據說上完了微服務：老闆據說上完了微服務，問之後上線是否是能夠像互聯網公司那樣灰度發佈了，結果才發現Spring Cloud官方居然沒提供這個能力。

Kubernetes很「難」。一堆概念，什麼Pod、CNI、Replication Controller、Persistent Volume…並且，隨便搞個事情都須要寫一長串yaml，各類事情還都用命令行操做。但實際上，Kubernetes使應用交付大大簡化了。之前最複雜的服務依賴管理、彈性伸縮、故障恢復等能力，Kubernetes都提供了支持。並且是你只用聲明你指望達到什麼目標，Kubernetes就能自動幫你完成這背後的各類具體操做步驟。

所以，若是要採用這種方案，這裏會有一些建議：

• 先把整套部署、治理、觀測系統建設完善以後再去作微服務拆分；
• 利用專門的團隊或者直接利用雲服務完成整套系統的建設和運維；
• 系統建設完善後，業務運維儘可能交給業務研發本身進行。

爲了使業務研發工程師能更容易地使用Kubernetes和Spring Cloud構建微服務系統。京東雲微服務平臺產品作了下面這些改進：

• 一個平臺，全界面操做，能夠完成整套部署、治理、觀測等線上運維工做；
• 具有日誌、監控、調用鏈、依賴圖譜等全角度觀測能力；
• 屏蔽Kubernetes底層技術細節，託管註冊中心、配置中心、調用鏈分析等後端服務，讓研發工程師的關注點能夠迴歸業務自己；
• 擴展標準Spring Cloud能力，增長路由治理和服務鑑權功能，能夠更精確的控制調用。

點擊【閱讀】可查看微服務平臺上如何經過K8S管理Spring Cloud應用。

Kubernetes部署+Istio服務治理

對於業務研發工程師而言，若是Kubernetes已經很難，那麼Istio就更難了。Istio的難主要體如今以下方面。

• 概念複雜：又是不少新概念，Virtual Service、Destination Rule、Subset、Service Entry… …
• 架構複雜：包含太多的系統組件，Pilot、Mixer、Galley、Security、Gateways、Kiali… …組件之間的關係又很複雜。
• 保證穩定性困難：社區版本發佈頻率快，每一個版本都有很多穩定性問題。若是線上出現問題，等下一版解決吧等不起，本身改吧又太複雜不知道該怎麼改。

若是要採用服務網格方案，這裏會有一些建議：

• 先作完微服務化和容器化以後再考慮引入服務網格技術。不要由於網格沒有架構依賴，想經過網格解決十幾年前的大型單體應用的服務治理問題；
• 利用專門的團隊或者直接利用雲服務完成整套系統的建設和運維；
• 先從訪問量不大的邊緣系統嘗試網格，延遲敏感的應用慎用網格。

爲了使Istio服務網格技術能更容易落地，京東雲的雲服務網格產品作了以下改進：

• 創建完備的測試系統，能夠經過長時間實際業務的壓測及時發現版本問題並及時優化和迴歸，保證Istio版本的穩定性。
• 界面上能夠經過幾個簡單配置後自動完成安裝、升級等複雜操做。
• 對Istio的複雜概念和使用過程進行了簡化，能夠更容易的使用網格的各類功能。

點擊https://docs.jdcloud.com/cn/mesh/basic-example瞭解如何快速的創建服務網格系統並快速體驗。

歡迎點擊「京東雲」瞭解更多精彩內容