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

京東科技開發者發表於2020-01-02
微服務

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

在微服務誕生之初，並沒有太多方案的選擇：選一個註冊中心用來做服務註冊和發現，透過客戶端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的複雜概念和使用過程進行了簡化，可以更容易的使用網格的各種功能。
點選 瞭解如何快速的建立服務網格系統並快速體驗。
歡迎點選“ 京東雲 ”瞭解更多精彩內容

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

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


來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69912185/viewspace-2671730/，如需轉載，請註明出處，否則將追究法律責任。

相關文章