點擊下載《不一樣的 雙11 技術(shù)：阿里巴巴經(jīng)濟體云原生實踐》

本文節(jié)選自《不一樣的 雙11 技術(shù)：阿里巴巴經(jīng)濟體云原生實踐》一書，點擊上方圖片即可下載！

作者 | 李云（花名：至簡） 阿里云高級技術(shù)專家

導(dǎo)讀：在即將過去的 2019 年，Service Mesh 開源產(chǎn)品的成熟度雖在全球范圍內(nèi)沒有發(fā)生質(zhì)的變化，但在國內(nèi)仍出現(xiàn)了一些值得特別關(guān)注的事件。比如：阿里巴巴在 雙11 的部分電商核心應(yīng)用上落地了完整的 Service Mesh 解決方案，借助 雙11 的嚴苛業(yè)務(wù)場景完成了規(guī)模化落地前的初步技術(shù)驗證。本文作者將結(jié)合自己在阿里巴巴落地實踐 Service Mesh 過程中的觀察與思考，來和大家進行分享。

Service Mesh 是新瓶裝舊酒嗎？

新技術(shù)出現(xiàn)時所主張的價值一定會引發(fā)相應(yīng)的探討，Service Mesh 也不例外。

以往，懷疑?Service Mesh 價值的觀點主要有兩大類。

• 第一類是應(yīng)用的數(shù)量并沒有達到一定的規(guī)模，在?Service Mesh 增加運維和部署復(fù)雜度的情形下，認為所帶來的成本和復(fù)雜度高于所獲得的收益。

從根本上來看，這一類并非真正懷疑?Service Mesh 的價值，而是主張在?Service Mesh 還沒有完全成熟和普及的情形下，在未來合適的時機再考慮采納。當(dāng)然，我在與外部客戶交流時也碰到一些特例，他們即便在應(yīng)用數(shù)很少的情形下，仍希望通過?Service
Mesh 去解決非?Java 編程語言（比方說?Go）的分布式鏈路追蹤等服務(wù)治理問題，雖說這些能力在?Java 領(lǐng)域有相對成熟的解決方案，但在非?Java 領(lǐng)域確實偏少，所以很自然地想到了采用?Service Mesh。

• 第二類懷疑?Service Mesh 價值的，是應(yīng)用的數(shù)量具有相當(dāng)?shù)囊?guī)模且對分布式應(yīng)用的規(guī)模問題也有很好的認知，但由于在發(fā)展的過程中已經(jīng)積累了與?Service Mesh 能力相當(dāng)?shù)哪切?#xff08;非體系化的）技術(shù)，造成初識?Service Mesh 時有“老酒換新瓶”的感覺而不認可其價值。阿里巴巴過去也曾屬于這一陣營。

阿里巴巴在分布式應(yīng)用的開發(fā)和治理方面的整體解決方案的探索有超過十年的歷程，且探索過程持續(xù)地通過 雙11 這樣的嚴苛場景做檢驗和孵化，采用單一的?Java 語言打造了一整套的技術(shù)。即便如此，應(yīng)對分布式應(yīng)用的規(guī)模問題依然不輕松，體現(xiàn)于因為缺乏頂層設(shè)計而面臨體系性不足，加之對技術(shù)產(chǎn)品自身的用戶體驗缺乏重視，最終導(dǎo)致運維成本和技術(shù)門檻都偏高。在面臨這些陣痛之際，云原生的概念逐漸清晰地浮出了水面。

云原生主張技術(shù)產(chǎn)品在最為嚴苛的場景下仍能提供一定質(zhì)量的服務(wù)而體現(xiàn)良好彈性，同時也強調(diào)技術(shù)產(chǎn)品本身應(yīng)當(dāng)具有良好的易用性，以及將來為企業(yè)需要多云和混合云的?IT?基礎(chǔ)設(shè)施提供支撐（即：幫助實現(xiàn)分布式應(yīng)用的可移植性）。

云原生的概念不僅很好地契合了阿里巴巴集團在技術(shù)發(fā)展上亟待解決的陣痛，也迎合了阿里巴巴將云計算作為集團戰(zhàn)略、讓云計算普惠社會的初衷。在這一背景下，阿里巴巴做出了全面云原生化的決定，Service Mesh 作為云原生概念中的關(guān)鍵技術(shù)之一，當(dāng)然也包含在其中。

Service Mesh 給阿里巴巴帶來的價值

Service Mesh 所帶來的第一個變化體現(xiàn)于：服務(wù)治理手段從過去的框架思維向平臺思維轉(zhuǎn)變。

這種轉(zhuǎn)變并非后者否定前者，而是前后者相結(jié)合去更好地發(fā)揮各自的優(yōu)勢。兩種思維的最大區(qū)別在于，平臺思維不僅能實現(xiàn)應(yīng)用與技術(shù)基礎(chǔ)設(shè)施更好的解耦，也能通過平臺的聚集效應(yīng)讓體系化的頂層設(shè)計有生發(fā)之地。

框架思維向平臺思維轉(zhuǎn)變在執(zhí)行上集中體現(xiàn)于“輕量化”和“下沉”兩個動作。

• 輕量化是指將那些易變的功能從框架的?SDK 中移出，結(jié)果是使用了?SDK 的應(yīng)用變得更輕，免除了因易變功能持續(xù)升級所帶來的低效；也徹底讓應(yīng)用的開發(fā)者無需關(guān)心這些功能，讓他們能更好地聚焦于業(yè)務(wù)邏輯本身；

• 從框架中移出的功能放到了?Service Mesh 的 Sidecar 中實現(xiàn)了功能下沉。

Service Mesh 作為平臺性技術(shù)，將由云廠商去運維和提供相應(yīng)的產(chǎn)品，通過開源所構(gòu)建的全球事實標準一旦被所有云廠商采納并實現(xiàn)產(chǎn)品化輸出，那時應(yīng)用的可移植性問題就能水到渠成地解決。

功能下沉在阿里巴巴落地?Service Mesh 的過程中也看到了相應(yīng)的價值。阿里巴巴的電商核心應(yīng)用基本上都是用?Java 構(gòu)建的，在 Mesh 化之前，RPC 的服務(wù)發(fā)現(xiàn)與路由是在?SDK 中完成的，為了保證 雙11 這樣的流量洪峰場景下的消費者用戶體驗，會通過預(yù)案對服務(wù)地址的變更推送做降級，避免因為頻繁推送而造成應(yīng)用進程出現(xiàn)?Full GC。Mesh 化之后，SDK 的那些功能被放到了 Sidecar（開發(fā)語言是?C ）這一獨立進程中，這使得?Java 應(yīng)用進程完全不會出現(xiàn)類似場景下的?Full GC 問題。

軟件設(shè)計的質(zhì)量主要體現(xiàn)在“概念”和“關(guān)系”兩個詞上。

同樣功能的一個系統(tǒng)，不同的概念塑造與切分將產(chǎn)生完全不同的設(shè)計成果，甚至影響到最終軟件產(chǎn)品的工程質(zhì)量與效率。當(dāng)概念確定后，關(guān)系也隨之確立，而關(guān)系的質(zhì)量水平體現(xiàn)在解耦的程度上。Service Mesh 使得應(yīng)用與技術(shù)基礎(chǔ)設(shè)施之間的關(guān)系變得更松且穩(wěn)定，通過流量無損的熱升級方案，使得應(yīng)用與技術(shù)基礎(chǔ)設(shè)施的演進變得獨立，從而加速各自的演進效率。軟件不成熟、不完善并不可怕，可怕的是演進起來太慢、包袱太重。

阿里巴巴在落地?Service Mesh 的過程中，體會到了松耦合所帶來的巨大工程價值。當(dāng)應(yīng)用被 Mesh 化后，接下來的技術(shù)基礎(chǔ)設(shè)施的升級對之就透明了，之前因為升級工作所需的人力配合問題可以通過技術(shù)產(chǎn)品化的手段完全釋放。另外，以往應(yīng)用進程中包含了業(yè)務(wù)邏輯和基礎(chǔ)技術(shù)的功能，不容易講清楚各自對計算資源的消耗，Service Mesh 通過獨立進程的方式讓這一問題得以更好地隔離而實現(xiàn)量化，有了量化結(jié)果才能更好地對技術(shù)做優(yōu)化。

Service Mesh 所帶來的第二個變化在于：技術(shù)平臺的建設(shè)從面向單一編程語言向面向多編程語言轉(zhuǎn)變。

對于初創(chuàng)或小規(guī)模企業(yè)來說，業(yè)務(wù)應(yīng)用的開發(fā)采用單一的編程語言具有明顯優(yōu)勢，體現(xiàn)于因為個體掌握的技術(shù)棧相同而能帶來良好的協(xié)作效率，但當(dāng)企業(yè)的發(fā)展進入了多元化、跨領(lǐng)域、規(guī)模更大的更高階段時，多編程語言的訴求就隨之產(chǎn)生，對于阿里巴巴這樣的云廠商來說更是如此（所提供的云產(chǎn)品不可能過度約束客戶所使用的編程語言）。多編程語言訴求的背后是每種編程語言都有自己的優(yōu)勢和適用范圍，需要發(fā)揮各自的優(yōu)勢去加速探索與創(chuàng)新。
?
從技術(shù)層面，這一轉(zhuǎn)變意味著：

• 第一，技術(shù)平臺的能力需要盡可能地服務(wù)化，避免因為服務(wù)化不徹底而需要引入?SDK，進而帶來多編程語言問題（即因為沒有相應(yīng)編程語言的?SDK 而無法使用該編程語言）；
• 第二，在無法規(guī)避?SDK 的情形下，讓?SDK 變得足夠的輕且功能穩(wěn)定，降低平臺化和多編程語言化的工程成本，支持多編程語言?SDK 最好的手段是采用?IDL。

從組織層面，這一轉(zhuǎn)變意味著平臺技術(shù)團隊的人員技能需要多編程語言化。一個只有單一編程語言的團隊是很難做好面向多編程語言的技術(shù)平臺的，不只是因為視角單一，還因為無法“吃自己的狗食”而對多編程語言問題有切膚之痛。

Service Mesh 帶來的發(fā)展機遇

在這兩個變化之下，我們來聊一聊?Service Mesh?所帶來的發(fā)展機遇。

• 首先，Service Mesh?創(chuàng)造了一次以開發(fā)者為中心去打造面向未來的分布式應(yīng)用開發(fā)平臺的機會。

在?Service Mesh 出現(xiàn)之前，各種分布式服務(wù)治理技術(shù)產(chǎn)品的發(fā)展，缺乏強有力的抓手去橫向拉通做體系化設(shè)計和完成能力復(fù)用，因而難免出現(xiàn)概念抽象不一致和重新造輪子的局面，最終每個技術(shù)產(chǎn)品有自己的一套概念和獨立的運維控制臺。當(dāng)多個運維控制臺交到開發(fā)者手上時，他們需要做大量的學(xué)習(xí)，去理解每個運維控制臺的概念以及它們之間的關(guān)系，背后所帶來的困難和低效是很容易被人忽視的。

本質(zhì)上，Service Mesh 的出現(xiàn)是解決微服務(wù)軟件架構(gòu)之下那些藏在應(yīng)用與應(yīng)用之間的復(fù)雜度的。它的出現(xiàn)使得所有的分布式應(yīng)用的治理問題被放到了一起去考慮。換句話說，因為?Service Mesh 的出現(xiàn)，我們有機會就分布式應(yīng)用的治理做一次全局的設(shè)計，也有機會將各種技術(shù)產(chǎn)品整合到一起而避免重復(fù)建設(shè)的問題。

未來的分布式應(yīng)用開發(fā)平臺一定是基于?Service Mesh 這一基礎(chǔ)技術(shù)的。為此，需要借這個契機從易用性的角度重新梳理應(yīng)給開發(fā)者塑造的心智。易用性心智的確立，將使得開發(fā)者能在一個運維控制臺上做最少的操作，通過為他們屏蔽背后的技術(shù)實現(xiàn)細節(jié)，而減輕他們在使用時的腦力負擔(dān)，以及降低操作失誤帶來安全生產(chǎn)事故的可能性。

理論上，沒有?Service Mesh 之前這些工作也能做，但因為沒有具體的橫向技術(shù)做抓手而無法落地。

• 其次，Service Mesh?給其他技術(shù)產(chǎn)品創(chuàng)造了重新思考云原生時代的發(fā)展機會。

有了?Service Mesh 后，以前很多獨立的技術(shù)產(chǎn)品（比如，服務(wù)注冊中心、消息系統(tǒng)、配置中心）將變成?BaaS（Backend as a Service）服務(wù)，由?Service Mesh 的?Sidecar 負責(zé)與它們對接，應(yīng)用對這些服務(wù)的訪問通過?Sidecar 去完成，甚至有些?BaaS 服務(wù)被?Sidecar 終結(jié)而完全對應(yīng)用無感。

這些變化并非弱化了那些?BaaS 服務(wù)的重要性。相反，因為其重要性而需要與?Service Mesh 做更好的整合去為應(yīng)用提供服務(wù)，與此同時探索做一定的能力增強。比方說，Service Mesh 所支持的應(yīng)用版本發(fā)布的灰度功能（包括藍綠發(fā)布、金絲雀發(fā)布、A/B 測試），并非每一個?BaaS 服務(wù)在 Mesh 化后就能很好地支持這一功能，而是需要做相應(yīng)的技術(shù)改造才行。請注意，這里主要講的是應(yīng)用的灰度能力，而非?BaaS?服務(wù)自身的灰度能力。當(dāng)然，并不妨礙探索通過?Service Mesh 讓?BaaS 服務(wù)自身的灰度工作變得簡單且低風(fēng)險。

未來很多技術(shù)產(chǎn)品的競爭優(yōu)勢將體現(xiàn)于它能否與?Service Mesh 形成無縫整合。

無縫整合的核心驅(qū)動力，源于用戶對技術(shù)產(chǎn)品的易用性和應(yīng)用可移植性的需要。基于這一認識，阿里巴巴正在將?RocketMQ/MetaQ 消息系統(tǒng)的客戶端中的重邏輯剝離到?Envoy 這一?Sidecar 中（思路依然是“下沉”），同時基于?Service Mesh 所提供的能力做一定的技術(shù)改造，以便?RocketMQ/MetaQ 能很好地支撐應(yīng)用的灰度發(fā)布。類似這樣的思考與行動，相信未來會在更多的技術(shù)產(chǎn)品上出現(xiàn)。

• 再次，Service Mesh?給技術(shù)基礎(chǔ)設(shè)施如何與業(yè)務(wù)基礎(chǔ)技術(shù)更好地協(xié)同提供了一次探索機會。

每一種業(yè)務(wù)（比如電商）都會構(gòu)建基于所在領(lǐng)域的基礎(chǔ)技術(shù)，這類技術(shù)我們稱之為業(yè)務(wù)基礎(chǔ)技術(shù)。當(dāng)阿里巴巴希望將某一業(yè)務(wù)的基礎(chǔ)技術(shù)搬到外部去服務(wù)客戶時，面臨業(yè)務(wù)基礎(chǔ)技術(shù)如何通過服務(wù)化去滿足客戶已選擇的、與業(yè)務(wù)基礎(chǔ)技術(shù)不同的編程語言的問題，否則會出現(xiàn)基于 Java 構(gòu)建的業(yè)務(wù)基礎(chǔ)技術(shù)很難與 Go 所編寫的應(yīng)用協(xié)同。

在?Service Mesh 致力于解決服務(wù)化問題的過程中，能否通過一定的技術(shù)手段，讓業(yè)務(wù)基礎(chǔ)技術(shù)的能力通過插件的形式“長”在?Service Mesh 之上是一個很值得探索的點。當(dāng)業(yè)務(wù)基礎(chǔ)技術(shù)以插件的形式存在時，業(yè)務(wù)基礎(chǔ)技術(shù)無需以獨立的進程存在而取得更好的性能，且這一機制也能被不同的業(yè)務(wù)復(fù)用。阿里巴巴的?Service
Mesh 技術(shù)方案所采用的 Sidecar?開源軟件 Envoy 正在積極地探索通過?Wasm 技術(shù)去實現(xiàn)流量處理的插件機制，將該機制進一步演變成為業(yè)務(wù)基礎(chǔ)技術(shù)插件機制是值得探索的內(nèi)容。

下圖示例說明了業(yè)務(wù)基礎(chǔ)技術(shù)的插件機制。

圖中兩個彩色分別代表了不同的業(yè)務(wù)（比如一個代表電商，另一個代表物流），兩個業(yè)務(wù)的基礎(chǔ)技術(shù)并非開發(fā)了兩個獨立的應(yīng)用（進程）然后做發(fā)布和運維管理，而是基于 Wasm 所支持的編程語言實現(xiàn)了業(yè)務(wù)技術(shù)插件，這一點可以理解為用多編程語言的方式解決業(yè)務(wù)服務(wù)化問題，而非強制要求采用與 Sidecar 一樣的編程語言。插件通過 Service Mesh 的運維平臺進行管理，包含安裝、灰度、升級、監(jiān)控等能力。

由于插件是“長”在 Service Mesh 之上的，插件化的過程就是業(yè)務(wù)技術(shù)服務(wù)化的過程。

另外，Service Mesh 需要提供一種選擇能力，讓業(yè)務(wù)的應(yīng)用開發(fā)者或運維者選擇自己的機器上需要哪些插件（可以理解為插件市場）。另一個值得關(guān)注的點是：插件的運維和管理能力以及一定的質(zhì)量保證手段由 Service Mesh 平臺提供，但運維、管理和質(zhì)量保證的責(zé)任由各插件的提供者承擔(dān)。這種劃分將有效地杜絕所有插件的質(zhì)量由 Service Mesh 平臺去承擔(dān)而帶來的低效，分而治之仍是改善很多工程效率的良方。

• 最后，Service Mesh 給探索面向未來的異地多活、應(yīng)用永遠在線的整體技術(shù)解決方案打開了一扇大門。

服務(wù)之間的互聯(lián)互通，服務(wù)流量的控制、觀測和安全加固是微服務(wù)軟件架構(gòu)下所要解決的關(guān)鍵問題，這些問題與規(guī)模化下的服務(wù)可用性和安全性緊密相關(guān)。未來，通過 Service Mesh 的流量控制能力能做很多改善應(yīng)用發(fā)布和運維效率的文章，那時才能真正看到一個靈動、稱手的云平臺。

Service Mesh 的“三位一體”發(fā)展思路

阿里巴巴作為云計算技術(shù)的供應(yīng)商，在探索 Service Mesh 技術(shù)的道路上，不只是考慮如何讓云原生技術(shù)紅利在阿里巴巴內(nèi)部兌現(xiàn)，同時還思考著如何將技術(shù)紅利帶給更多的阿里云客戶。基于此，阿里巴巴就 Service Mesh 的整體發(fā)展思路遵循“三位一體”，即阿里巴巴內(nèi)部、阿里云上的相應(yīng)商業(yè)產(chǎn)品和開源軟件將采用同一套代碼。

就我們與阿里云客戶交流的經(jīng)驗來看，他們樂于盡最大可能采用非云廠商所特有的技術(shù)方案，以免被技術(shù)鎖定而在未來的發(fā)展上出現(xiàn)掣肘。另外，他們只有采納開源的事實標準軟件才有可能達成企業(yè)的多云和混合云戰(zhàn)略。基于客戶的這一訴求，我們在 Service Mesh 的技術(shù)發(fā)展上特別重視參與開源事實標準的共建。在 Istio 和 Envoy 兩個開源項目上，我們都會致力于將內(nèi)部所做的那些優(yōu)化反哺給開源社區(qū)。

未來，我們將在 Service Mesh 領(lǐng)域堅定而扎實地探索，也一定會將探索成果和思考持續(xù)地分享給大家。

本書亮點

• 雙11 超大規(guī)模 K8s 集群實踐中，遇到的問題及解決方法詳述
• 云原生化最佳組合：Kubernetes 容器 神龍，實現(xiàn)核心系統(tǒng) 100% 上云的技術(shù)細節(jié)
• 雙 11 Service Mesh 超大規(guī)模落地解決方案

“阿里巴巴云原生微信公眾號（ID：Alicloudnative）關(guān)注微服務(wù)、Serverless、容器、Service Mesh等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實踐，做最懂云原生開發(fā)者的技術(shù)公眾號。”

總結(jié)

以上是生活随笔為你收集整理的Service Mesh 是新瓶装旧酒吗？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。