受訪者 | 王夕寧
記者 | 伍杏玲
出品 | CSDN(ID:CSDNnews)
如今微服務已成為構建現(xiàn)代云應用的主導模式,它圍繞著特定的業(yè)務功能,將單個組件分解為獨立的服務。但隨之而來產生另外的問題:越來越多的系統(tǒng)被拆解成了很多個細胞一樣的微服務,如何對微服務進行管理,是工程師遇到的難題之一。
傳統(tǒng)的微服務架構中,雖然有服務治理的組件,但需要在應用代碼里進行集成,如何標準化高效地部署和運維的微服務?
Service Mesh應運而生。它將整體服務代碼獨立成一套服務,將業(yè)務代碼和治理邏輯做了整體的分離,讓運維部署變得簡單。有人認為,Service Mesh是下一代微服務。
在前不久Gartner發(fā)布2020年公共云容器報告,阿里云連續(xù)兩年成為唯一入選的中國企業(yè),并成為全球容器產品最完善的云服務廠商之一。其中Alibaba Cloud Service Mesh(ASM)也位列入選的產品中,Service Mesh到底是什么?ASM背后的技術演進是怎樣?
對此,CSDN(ID:CSDNnews)專訪阿里云高級技術專家、阿里云服務網格ASM技術負責人王夕寧,來一探究竟。
云原生時代下,Service Mesh三大優(yōu)勢
王夕寧表示,過去幾年間Kubernetes得到了具有變革性的進展,最重要的原因之一是其API的設計更加考慮了開發(fā)人員。開發(fā)者可以在Kubernetes中創(chuàng)建應用部署或者服務,這些應用本身仍然在使用計算、網絡和存儲資源,開發(fā)者可以使用一致的API方式來創(chuàng)建和使用,而不需要關注于太多底層細節(jié)。
但是,僅僅在Kubernetes中運行一個Pod或者容器并不能解決復雜分布式應用的全部,應用除了運行本身的代碼之外,還需要與其他應用服務進行網絡通信交互。定義應用程序通信的API是云原生開發(fā)人員體驗的關鍵部分,這些API通常被稱為Service Mesh API。通過Service Mesh技術,重新定義了分布式應用之間的通信消息機制與諸如拓撲、路由、度量和訪問控制的特性。
Service Mesh 有以下三大優(yōu)勢:
1、服務治理能力的Sidecar化。
在服務網格技術使用之前,把一個單體應用程序向分布式的微服務架構進行改造,通常的服務治理邏輯的實現(xiàn)往往是以代碼庫的方式構建在應用程序本身中,這些代碼庫中包括了服務發(fā)現(xiàn)、熔斷、限流等這樣的一些功能,這些代碼庫的版本也可能不同,不同的情況下也可能會帶來沖突問題。
此外,庫的版本一旦變更,即使你的應用邏輯并沒有任何變化,整個應用也要隨之全部變更。通過把這些服務治理的能力Sidecar化,就能夠把服務治理的能力與應用程序本身進行了解耦,可以較好地支持多種編程語言、并且不需要依賴于某種特定技術框架。
針對Sidecar代理的生命周期管理和針對應用程序本身的生命周期管理可以獨立,提升了應用管理和運維管理的靈活性;同時這種去中心化的架構,有利于提升系統(tǒng)的可伸縮性。
2、通過Sidecar機制逐漸地將服務治理功能標準化、統(tǒng)一化。
隨著這些Sidecar代理功能的增強,原本在代碼庫中包含的功能逐漸地下沉到這些代理中,這些功能包含了服務治理中需要到的諸如流量管理、熔斷、重試、客戶端負載均衡的能力、安全以及可觀測性能力等。
這些能力的標準化、統(tǒng)一化,可以解決復雜系統(tǒng)中的微服務實現(xiàn)中面臨的差異大、缺少共性的問題,可以很好地支持不同的編程語言、不同的框架。
3、容器編排技術的更加成熟,加速了Sidecar代理的普及與使用的便捷。
試想一下,如果每一個Sidecar代理都需要手工去注入、管理它的生命周期,那它的價值與帶來的復雜性相比,就顯得比較單薄。Kubernetes是一個出色的容器部署和管理平臺,提供的API可以支持很自然的擴展,Sidecar代理可以在應用程序的容器啟動時自動注入到對應的Pod中。
服務網格技術帶來了上述優(yōu)勢,它使用起來的情況如何呢?我們知道,在云原生應用模型中,一個應用程序可能會包含數(shù)百個服務,每個服務又有數(shù)百個實例構成,那么這些成百上千個應用程序的Sidecar代理如何統(tǒng)一管理,這就是服務網格中定義的控制平面部分要解決的問題。作為代理,Envoy非常適合服務網格的場景,但要發(fā)揮Envoy的最大價值,就需要使它很好地與底層基礎設施或組件緊密配合。Envoy構成了服務網格的數(shù)據(jù)平面,Istio提供的支撐組件則是創(chuàng)建了控制平面。
這些Sidecar代理形成一個網狀的數(shù)據(jù)平面,通過該數(shù)據(jù)平面處理和觀察所有服務間的流量。數(shù)據(jù)平面扮演了一個用來建立、保護和控制通過網格的流量的角色。負責數(shù)據(jù)平面如何執(zhí)行的管理組件稱為控制平面??刂破矫媸欠站W格的大腦,并為網格使用人員提供公開API,以便較容易地操縱網絡行為。
這些復雜配置也是用戶經常遇到的一些挑戰(zhàn),特別是在支持多集群、如何支持用戶自建的IDC內的集群、如何支持非容器化應用的統(tǒng)一管理,這些基本成為了用戶使用服務網格技術的阻礙。
解決這些問題的方式,是需要全部托管控制平面的組件,降低用戶使用的復雜度,用戶只需要專注于業(yè)務應用的開發(fā)部署。在托管模式下,保持與Istio的兼容,支持聲明式的方式定義靈活的路由規(guī)則,支持多個Kubernetes集群的統(tǒng)一流量管理。
在安全上,用戶可以一鍵啟用或者禁用雙向TLS認證,整個網格內的安全配置動態(tài)生效;在多集群模式下,用戶也不需要去維護根證書了,這些事情都會交給平臺來管理。此外,在深入分析服務網格方面,提供了網格診斷能力,把過去一年多來用戶遇到的問題以及如何解決這些問題的手段變成產品能力;同時優(yōu)化集成跟蹤、日志服務等來提升端到端的可觀測性。
這是阿里云做托管式服務網格ASM產品背后的邏輯。
阿里云在服務網格的技術演進歷程
2018年,阿里云容器服務ACK產品中以addon的方式集成了Istio,以社區(qū)開源Isito為基礎,優(yōu)化整合了阿里云的相關服務,例如跟蹤服務、日志服務等提升端到端的觀測性;通過使用阿里云的CEN云企業(yè)網,打通了多個集群的統(tǒng)一管理,將多集群下的Pod實現(xiàn)互聯(lián)互通和統(tǒng)一管理。
在接近兩年的時間中,跟隨社區(qū)的快速發(fā)展,迭代發(fā)布了多個版本,來支持目前在云上的數(shù)百個用戶集群。
2020年2月,阿里云發(fā)布了業(yè)內首個全托管,Istio兼容的服務網格產品ASM。
ASM三大優(yōu)勢
ASM控制平面的組件托管在阿里云側,與數(shù)據(jù)面?zhèn)鹊挠脩艏邯毩?,降低用戶使用的復雜度,用戶只需要專注于業(yè)務應用的開發(fā)部署。在托管模式下,保持與Istio的兼容,支持聲明式的方式定義靈活的路由規(guī)則,支持多個Kubernetes集群的統(tǒng)一流量管理。
此外,ASM在Istio基礎上進行大量的擴展。ASM整合阿里云服務包括可觀測性服務、日志服務、基于云企業(yè)網實現(xiàn)跨VPC網絡互連能力等,同時也優(yōu)化整合了社區(qū)開源軟件包括開放策略代理OPA的支持、授權服務的定制化能力等。隨著Isito1.5新架構的優(yōu)化,將WebAssembly技術引入服務網格,使得ASM架構成為:托管的高可用彈性控制平面 + 可擴展的插件式的數(shù)據(jù)平面。
在數(shù)據(jù)平面的支持上,ASM產品可以支持多種不同的計算基礎設施,這包括了阿里云ACK Kubernetes集群、ASK集群、以及針對ECS虛擬機的支持。此外,ASM也在今年4月份推出多云混合云的支持,可以支持用戶自身IDC建設的Kubernetes集群或者運行在其他云提供商上的Kubernetes集群使用服務網格能力。通過ASM提供統(tǒng)一的服務治理能力,可以實現(xiàn)就近訪問,故障轉移,灰度發(fā)布等功能,支持云容災、異地多活等應用場景,提升業(yè)務連續(xù)性。
服務治理體系演進遷移,如何避免踩坑?
隨著微服務的發(fā)展,企業(yè)進行一些服務治理體系的演進,如從Spring Cloud到Service Mesh遷移,需要注意哪些問題?
王夕寧回答道,Netflix是最早采用微服務的公司之一。為了跟上其增長速度,Netflix決定從單一的數(shù)據(jù)中心轉移到基于云的微服務架構,來實現(xiàn)高可用性,規(guī)模和速度。Netflix OSS是Netflix開源的一組庫和框架,用于解決大規(guī)模設計分布式系統(tǒng)的問題。Spring Cloud基于Spring Boot開發(fā),里面使用了Netflix OSS這套庫和框架,提供了一套完整的微服務解決方案。
從功能角度來看,Spring Cloud與Service Mesh在服務治理場景下,存在較多的重疊,這也就為從Spring Cloud向Service Mesh遷移提供了一種潛在的可能性。當前兩者所解決的問題盡管是類似的,即微服務架構中分布式特點帶來的復雜性問題;然而兩者解決相同問題的方式手段不盡相同,在《 Istio服務網格技術解析與實踐》書提到這一點,詳細對特定應用程序庫的缺點的分析、Istio網格與傳統(tǒng)微服務框架的比較,希望這些內容能夠讓讀者理解他們之間的差異。
linux容器簡化了應用程序的打包部署,容器是云原生應用基石,通過應用容器化,不僅使得開發(fā)部署更加敏捷、遷移更加靈活,并且將這些實現(xiàn)標準化。而容器編排則是更近一步,負責解決如何高效地編排和利用好這些資源。Kubernetes編排容器服務已經成為一種事實標準;同時微服務與容器在輕量、快速部署、運維等特征的匹配,微服務運行在容器中也正成為一種標準實踐。
類似于Istio的這些服務網格技術在微服務治理上很好地補齊了Kubernetes,同時它又與Kubernetes有著完美的集成,不同于現(xiàn)有的微服務架構如SpringCloud、Dubbo或者Netflix OSS等。
由上述可知,如從Spring Cloud到Service Mesh遷移,應用的容器化是第一個需要注意的問題。
越來越多的應用走在了通往應用容器化的道路上,容器化會成為應用部署的標準形態(tài)。
無論哪種容器化運行環(huán)境,天然支撐服務注冊發(fā)現(xiàn)這一基本要求,這就導致Spring Cloud體系應用上容器的過程中,存在一定的功能重疊,針對這部分重疊功能,不防分析下在Kubernetes是否可以滿足這些能力。特別是一些大規(guī)模場景下,當遷移到Kubernetes環(huán)境時,需要考慮集群的規(guī)模、etcd集群的規(guī)模、節(jié)點配置及規(guī)模、網段劃分等,是否合理規(guī)劃,避免資源浪費。
容器化環(huán)境規(guī)劃好之后,就是針對應用服務的改造。這涉及到很多細節(jié)問題,需要根據(jù)應用本身特點具體來分析。大體上來講,是圍繞上述重疊功能模塊依賴的去除或者替換,這里面可能會涉及到網關、熔斷器、注冊中心、負載均衡、鏈路跟蹤等組件。本質上講,重試、超時、客戶端負載平衡、或者熔斷等等,這些問題與應用程序功能本身相互獨立,我們真正想要的是一種技術無關的方式來實現(xiàn)這些問題,并減輕特定于應用程序本身來實現(xiàn)。
此外,強調的一點是一定不能將應用程序的安全性和正確性轉移到Istio或任何服務網格上。構建正確和安全的應用程序的責任仍然是應用程序本身。
ASM未來部署
談及未來,王夕寧表示,在過去的一年里,以Istio為代表的服務網格技術的快速發(fā)展和成熟完善。
服務網格技術未來發(fā)展可分為2個方面:一方面服務網格技術架構優(yōu)秀、提供的功能也比較豐富的,包括細粒度的流量管理、安全性、可觀測性等,過去這些功能往往是需要若干個中間件拼湊在一起才是實現(xiàn),它的復雜度絕對不低于服務網格技術本身。
另一方面,隨著Kubernetes的更加成熟穩(wěn)定,基于Kubernetes的服務網格架構也隨著變得更加成熟,控制面和數(shù)據(jù)面解耦使得托管變成現(xiàn)實,聲明式的擴展方式更加靈活簡便,數(shù)據(jù)面能力無論是從支持的基礎設施形態(tài)上還是多云混合云邊界上都隨之不斷增強擴展。
云計算三大發(fā)展趨勢
對于云計算未來技術的發(fā)展動態(tài),王夕寧表示有以下三大發(fā)展技術趨勢:
首先,Kubernetes深入企業(yè)應用。我們預期Kubernetes將會在大多數(shù)企業(yè)中被廣泛采用,并繼續(xù)保持其在容器編排方面的主導地位。盡管支持企業(yè)Kubernetes解決方案已經存在了很長一段時間,但在很多企業(yè)需求方面仍有提升空間,例如權限、治理、成本控制和集成。
其次,混合云。據(jù)IDC預測,到2022年,50%的企業(yè)將部署統(tǒng)一的VMs、Kubernetes和多云混合云管理流程和工具,以支持跨本地和公有云部署的多云混合云管理和治理。同時,據(jù)IDC預測,中國90%以上的企業(yè)將依賴于本地/專屬私有云、多個公有云和遺留平臺的組合,以滿足其基礎設施需求。
第三,服務網格。2020 年 Istio 作為控制平面的一種技術實現(xiàn)仍將在 Service Mesh 領域扮演核心角色。Istio 獲得業(yè)界廣泛關注的原因,在于背靠 google 公司的內部工程實踐,以及對工程實踐的再思考和重新提煉。Istio 在過去一年的重要工作是完善功能和改善穩(wěn)定性確保小規(guī)模生產可用,在 2020 年隨著阿里巴巴采用這一技術實現(xiàn)大規(guī)模落地將為 Istio 的規(guī)模化運用提供真實的場景,這將使得 Istio 在接下來的一年在支持集群規(guī)模的能力上大幅提高。此外,Istio 的可運維性和架構的合理性在 2020 年也將迎來積極的變化,其部署和運維的復雜性高等問題將得到解決。
嘉賓簡介:王夕寧,阿里云高級技術專家,阿里云服務網格ASM技術負責人,關注Kubernetes、云原生、服務網格等領域。之前曾在IBM中國開發(fā)中心工作,曾擔任專利技術評審委員會主席,作為架構師和主要開發(fā)人員負責或參與了一系列在SOA中間件、云計算等領域的工作,擁有50多項相關領域的國際技術專利?!禝stio 服務網格解析與實戰(zhàn)》作者。