Servicemesh 落地實踐三年，效果一直并不理想，到了該反思的時候了。Mecha 作為面向服務(wù)的分布式能力抽象層，是 Servicemesh 模式的自然進化版
Servicemesh 落地實踐三年，效果一直并不理想，到了該反思的時候了。Mecha 作為面向服務(wù)的分布式能力抽象層，是 Servicemesh 模式的自然進化版本，預(yù)計也將是云原生化和 Mesh 化的必然趨勢，讓我們將 Mesh 進行到底。
Mecha 介紹
什么是 Mecha?
Mecha 一詞，相信愛好動漫的同學(xué)應(yīng)該都不陌生。是的，就是大家熟悉的那個 Mecha(機甲)：
Mecha 這個詞之所以出現(xiàn)在這里，主要是因為 Bilgin Ibryam 的這個博客文章 “Multi-Runtime Microservices Architecture”，提出了微服務(wù)架構(gòu)的一個新的設(shè)想：Multiple Runtime。
備注：這篇博客文章強烈推薦閱讀，我甚至建議在閱讀本文之前先閱讀這篇文章，因為我今天的內(nèi)容，可以視為對這個文章的深度解讀和思考。為了方便，這里提供一份中文翻譯版本 多運行時微服務(wù)架構(gòu)。
在這篇博客中，Bilgin Ibryam 首先分析并總結(jié)了分布式應(yīng)用的四大需求:
生命周期(Lifecycle)
網(wǎng)絡(luò)(Networking)
狀態(tài)(State)
捆綁(Binding)
由于每種需求存在的問題和局限性，導(dǎo)致傳統(tǒng)解決方案如企業(yè)服務(wù)總線(ESB)及其變體(例如面向消息的中間件，更輕量級的集成框架等)不再適用。隨著微服務(wù)架構(gòu)的發(fā)展，以及容器和 Kubernetes 的普及和廣泛使用，云原生思想開始影響這些需求的實現(xiàn)方式。未來的架構(gòu)趨勢是通過將所有傳統(tǒng)的中間件功能移至其他運行時來全面發(fā)展，最后的目標是在服務(wù)中只需編寫業(yè)務(wù)邏輯。
備注：詳情請見原文，為了節(jié)約篇幅，這里只做簡單概述，不完全引用原文內(nèi)容。
下圖是傳統(tǒng)中間件平臺和云原生平臺的對比，傳統(tǒng)中間件以各種 SDK 的方式提供能力，而云原生平臺則通過各種外圍 Runtime(典型如大家熟悉的 Servicemesh/Istio)：
因此作者引入了 Multiple Runtime 的概念：
作者提出：很可能在將來，我們最終將使用多個運行時來實現(xiàn)分布式系統(tǒng)。多個運行時，不是因為有多個微服務(wù)，而是因為每個微服務(wù)都將由多個運行時組成，最有可能是兩個運行時 - 自定義業(yè)務(wù)邏輯運行時和分布式原語運行時。
對多運行時微服務(wù)架構(gòu)和 Mecha 的說明：
您還記得電影《阿凡達》和科學(xué)家們制作的用于去野外探索潘多拉的 Amplified Mobility Platform (AMP)“機車服”嗎?這個多運行時架構(gòu)類似于這些 Mecha- 套裝，為類人駕駛員賦予超能力。在電影中，您要穿上套裝才能獲得力量并獲得破壞性武器。在這個軟件架構(gòu)中，您將擁有構(gòu)成應(yīng)用核心的業(yè)務(wù)邏輯(稱為微邏輯 /micrologic)和提供強大的開箱即用的分布式原語的 sidecar mecha 組件。Micrologic 與 mecha 功能相結(jié)合，形成多運行時微服務(wù)，該服務(wù)將進程外功能用于其分布式系統(tǒng)需求。最棒的是，Avatar 2 即將面世，以幫助推廣這種架構(gòu)。我們最終可以在所有軟件會議上用令人贊嘆的機甲圖片代替老式的邊車摩托車;-)。接下來，讓我們看看該軟件架構(gòu)的詳細信息。
這是一個類似于客戶端 - 服務(wù)器體系結(jié)構(gòu)的雙組件模型，其中每個組件都是獨立的運行時。它與純客戶端 - 服務(wù)器架構(gòu)的不同之處在于，這兩個組件都位于同一主機上，彼此之間有可靠的網(wǎng)絡(luò)連接。這兩個組件的重要性相當(dāng)，它們可以在任一方向上發(fā)起操作并充當(dāng)客戶端或服務(wù)器。其中的一個組件稱為 Micrologic，擁有非常少的業(yè)務(wù)邏輯，把幾乎所有分布式系統(tǒng)問題都剝離出去了。另一個伴隨的組件是 Mecha，提供了我們在本文中一直討論的所有分布式系統(tǒng)功能(生命周期除外，它是平臺功能)。
作者在這里正式提出了 Mecha 的理念：
思路大體是：Smart Runtime， Dumb Pipes。
我對 Mecha 的理解是：業(yè)務(wù)邏輯在編碼開始階段應(yīng)該是“裸奔”的，專注于業(yè)務(wù)邏輯的實現(xiàn)，而盡量不涉及到底層實現(xiàn)邏輯;而在運行時，則應(yīng)該裝備“機甲”，全副武裝，大殺四方。熟悉的味道是吧?標準而地道的云原生思想。
Mecha 的本質(zhì)
作者在原文中探討了 Mecha 運行時的特性：
Mecha 是通用的，高度可配置的，可重用的組件，提供分布式原語作為現(xiàn)成的能力。
Mecha 可以與單個 Micrologic 組件一起部署 (Sidecar 模式)，也可以部署為多個共享 (注：我稱之為 Node 模式)。
Mecha 不對 Micrologic 運行時做任何假設(shè)。它與使用開放協(xié)議和格式(例如 HTTP/gRPC，JSON，Protobuf，CloudEvents)的多語言微服務(wù)甚至單體一起使用。
Mecha 以簡單的文本格式(例如 YAML，JSON)聲明式地配置，指示要啟用的功能以及如何將其綁定到 Micrologic 端點。
與其依靠多個代理來實現(xiàn)不同的目的(例如網(wǎng)絡(luò)代理，緩存代理，綁定代理)，不如使用一個 Mecha 提供所有這些能力。
下面是我對上述特性的個人理解：
Mecha 提供的是能力，以分布式原語體現(xiàn)的各種能力，而不局限于單純的網(wǎng)絡(luò)代理。
Mecha 的部署模型，不局限于 Sidecar 模式，Node 模式在某些場景下(如 Edge/IoT，Serverless FaaS)可能會是更好的方式。至少，Mecha 下有機會按需選擇，而不是綁死在 Sidecar 模式上
Mecha 和 Micrologic 之間的交互是開放而有 API 標準的，Mecha 和 Micrologic 之間的“協(xié)議”體現(xiàn)在 API 上，而不是 TCP 通訊協(xié)議。這提供了一個契機：一個統(tǒng)一 Micrologic 和 Mecha 之間通訊方式的契機。
Mecha 可以以聲明式的方式進行配置和控制，這非常符合云原生的理念，同樣也使得 API 更關(guān)注于能力本身，而不是能力如何配置。
應(yīng)用需要的能力如此之多(參見上面的圖：分布式應(yīng)用的四大需求)，如果每個能力都對應(yīng)一個代理(不管是 Node 還是 Sidecar)，數(shù)量會非?？鋸?，帶來的運維壓力會很可怕。因此，如 Mecha 這個名字暗示的，運行時應(yīng)該是整套的形式提供能力，而不是分散。
如果用一句話來總結(jié)，那么我認為 Mecha 的本質(zhì)應(yīng)該是：“面向應(yīng)用的分布式能力抽象層”
如 Servicemesh 的本質(zhì)是服務(wù)間通訊的抽象層一樣，Mecha 的本質(zhì)是應(yīng)用需要的各種分布式能力和原語，包括但不限于服務(wù)間通訊。
從這個角度上說，Mecha 覆蓋的范圍是 Servicemesh 的超集：畢竟 Servicemesh 只覆蓋到應(yīng)用的部分需求(服務(wù)間通訊，還只限于同步 / 一對一 /request-response 模式)，還有更多的分布式能力和原語有待覆蓋。
換一句話說，Mecha 的目標應(yīng)該是：“將 Mesh 進行到底!”
Mecha 的優(yōu)勢和未來
作者指出：Mecha 的好處是業(yè)務(wù)邏輯和越來越多的分布式系統(tǒng)問題之間的松耦合。
下圖是業(yè)務(wù)邏輯和分布式系統(tǒng)問題在不同架構(gòu)中的耦合：
其實思路和 Servicemesh 是一脈相承的，只是覆蓋的分布式能力更廣泛一些。
有一個問題：Mecha 會不會成為微服務(wù)架構(gòu)的演進的下一個形態(tài)?我個人的答案：是，隨著云原生的推進，分布式能力(以傳統(tǒng)中間件為典型代表)下沉是大勢所趨，Mesh 化的范圍必然會繼續(xù)擴大，也就離 Mecha 的形態(tài)越來越近了。這也就是本文標題的立意所在，Mecha 會是微服務(wù)乃至云原生的下一站。
微軟 Dapr
在介紹完 Mecha/Multiple Runtime 的理念之后，我們來看看目前微軟新推出來的 Dapr 項目 —— 這應(yīng)該是業(yè)界第一個 Multiple Runtime 的開源實踐項目。
項目地址：https://github.com/dapr/dapr。
Dapr 介紹
Dapr 是 Distributed Application Runtime (分布式應(yīng)用運行時)的縮寫，官方介紹說 Dapr 是“一種可移植的，事件驅(qū)動的運行時，用于構(gòu)建跨云和邊緣的分布式應(yīng)用”。
Dapr 的詳細介紹是：
Dapr 是一種可移植的，serverless 的，事件驅(qū)動的運行時，它使開發(fā)人員可以輕松構(gòu)建彈性，無狀態(tài)和有狀態(tài)微服務(wù)，這些服務(wù)運行在云和邊緣上，并包含多種語言和開發(fā)框架。
Dapr 整理了構(gòu)建微服務(wù)應(yīng)用為開放，獨立的構(gòu)建塊的最佳實踐，使您能夠使用自己選擇的語言和框架來構(gòu)建可移植的應(yīng)用程序。每個構(gòu)建塊都是獨立的，您可以在應(yīng)用中使用其中的一個或多個。
Dapr 的功能和定位，下面這一張圖就可以概括了：
最底下基礎(chǔ)設(shè)施是各種云平臺(主流公有云都支持)或者邊緣環(huán)境
其上是 dapr 提供的分布式能力，dapr 稱之為“building block”。
這些 building block 的能力，以統(tǒng)一的 API(支持 HTTP 和 gRPC)對外提供服務(wù)
應(yīng)用可以用各種語言編寫，然后通過 dapr 提供的 API 使用這些能力，dapr 也提供客戶端類庫來簡化對 API 的調(diào)用，實現(xiàn)了多語言的支持。
Dapr 提供的具體分布式能力(building block)如下圖所示：
每個 building block 提供的具體能力請參加 Dapr 的官方文檔：https://github.com/dapr/docs/tree/master/concepts。
Dapr 的 API 例子
我們來看一下應(yīng)用調(diào)用 Darp API 的例子，體驗一下使用 Dapr 的方式。
以 Service Invocation / 服務(wù)調(diào)用為例：
部署和調(diào)用方式與 Servicemesh/Istio 極為相似，但是，差別在于：Dapr 是以提供 API 的方式提供 API 背后的能力，而不是提供提供協(xié)議代理的方式。
上圖中 1，是 ServiceA 發(fā)起請求來調(diào)用一個遠程服務(wù)。其 HTTP request 如下所示：
POST/GET/PUT/DELETE http://localhost:
其中：
參數(shù) daprPort 是 Dapr Runtime 啟動的監(jiān)聽端口，用來接受應(yīng)用的 outbound 請求
參數(shù) appId 是遠程應(yīng)用在 darp 中的關(guān)聯(lián) id，每個注冊到 dapr 的應(yīng)用都有一個唯一的 appId
參數(shù) method-name 是要調(diào)用的遠程應(yīng)用的方法名或者 URL
負載可以存放在 HTTP body 中隨請求發(fā)送，如 json。
注意，雖然都是提供相同的功能，這里體現(xiàn)了 Dapr(或者說背后的 Mecha)和 Servicemesh 在方式上的差異：暴露 API 還是代理通訊協(xié)議。
我們看一個更明顯的例子，dapr 提供的 “publish/subscriptions” 能力，讓應(yīng)用可以方便的發(fā)布消息，或者訂閱主題并接收消息。下圖是應(yīng)用發(fā)布消息，請求直接發(fā)給 dapr 即可：
例子中，參數(shù) topic 指定了消息要發(fā)往的主題(例子中是 deathStarStatus)。后續(xù) dapr 會完成將消息入 queue，然后推送到訂閱了該 topic 的應(yīng)用。接收消息的方式也類似，不過這次是 darp 主動發(fā)起： dapr 首先會請求應(yīng)用，咨詢應(yīng)用需要訂閱那些主題(topic)，如例子中應(yīng)用返回的的 TopicA / TopicB
dapr 實現(xiàn)主題訂閱，在接收到消息之后，再把消息發(fā)送給應(yīng)用，通過 URL 參數(shù)的不同來區(qū)分不同的主題
注意在這個調(diào)用期間，無論是收發(fā)消息，應(yīng)用完全不用理會底層 pub/sub 的實現(xiàn)機制(比如是 kafka，還是 rocketmq，還是其他公有云提供的消息機制)，也完全不用引入該實現(xiàn)機制的客戶端 SDK，只是簡單的使用 darp 定義的 API 即可，從而實現(xiàn)了和底層的解耦，以及“廠商不綁定”。
為了進一步簡化調(diào)用的過程(畢竟發(fā)一個最簡單的 HTTP GET 請求也要應(yīng)用實現(xiàn) HTTP 協(xié)議的調(diào)用 / 連接池管理等)，dapr 提供了各個語言的 SDK，如 java / go / python / dotnet / js / cpp / rust 。另外同時提供 HTTP 客戶端和 gRPC 客戶端。
我們以 Java 為例，java 的 client API 接口定義如下：
public interface DaprClient { Mono publishEvent(String topic, Object event); Mono invokeService(Verb verb, String appId, String method, Object request); ......}
具體可見：
https://github.com/dapr/java-sdk/blob/master/sdk/src/main/java/io/dapr/client/DaprClient.java
分析和總結(jié)
前面介紹了 Multiple Runtime / Mecha 的架構(gòu)思想，以及參考實現(xiàn)之一的微軟 Dapr 項目。
由于 Multiple Runtime / Mecha 這個思想非常的新，剛剛提出不久，而微軟 Dapr 項目也是一個新出來的項目，不管是理論思想還是實踐都處于非常早期的狀態(tài)，也還沒有形成完善的方法論。
特別申明：以下內(nèi)容更多是我個人當(dāng)下的理解和感悟，僅代表個人意見，肯定有很多不成熟甚至謬誤的地方，歡迎指正和探討。
Mecha 和 Dapr 的啟示
1. Mesh 模式應(yīng)該推向更大的領(lǐng)域
隨著云原生的深入，應(yīng)用需要的分布式能力應(yīng)該全面下沉，而不僅僅局限于 Servicemesh 提供的服務(wù)間通訊能力;應(yīng)用形態(tài)會朝純業(yè)務(wù)邏輯這個目標更進一步，應(yīng)用更加的云原生化。
這是大勢所趨，也是 Mecha 架構(gòu)出現(xiàn)和發(fā)展的原動力。
2. Mecha 強調(diào)是“提供能力”，而不是通訊代理
Mecha 的使用方式和 Servicemesh 有非常大的差異：Mecha 強調(diào)的是提供分布式能力給應(yīng)用使用，這些能力最終以封裝完善的 API 的方式呈現(xiàn)。API 體現(xiàn)的是應(yīng)用對能力的“需求”和“意愿”，不涉及到如何實現(xiàn)，實現(xiàn)是 Mecha 的職責(zé)，采用什么樣的實現(xiàn)也是由 Mecha 來控制。
在 Servicemesh 下，不存在這個需求：Servicemesh 提供的是服務(wù)間通訊能力，這個能力是由 sidecar 來提供，沒有其他的更底層的實現(xiàn)，不存在隔離和替換的可能。受服務(wù)通訊協(xié)議和報文 schema 的限制，Servicemesh 只能做請求的“轉(zhuǎn)發(fā)”，能力聚焦在“如何轉(zhuǎn)發(fā)”上，沒有其他需要隔離和替代的能力。
當(dāng) Mecha 把能力擴展到 Servicemesh 之外時，很多能力是由外部系統(tǒng)提供：比如 pub-sub 能力可以由不同的 Message Queue 實現(xiàn);狀態(tài)管理能力可以連接不同的 Key-Value 實現(xiàn)。此時能力的隔離性和可替代性就成為關(guān)鍵需求：解耦應(yīng)用和能力實現(xiàn)，容許 Mecha 替換底層實現(xiàn)(進而實現(xiàn)供應(yīng)商不鎖定等)。
3. 不強求“零侵入”
在 Servicemesh 中，“零侵入”是一個非常強調(diào)的特性，為此不惜引入 iptables 等流量劫持方案。“零侵入”在某些特殊場景下會發(fā)揮巨大的優(yōu)勢，如舊有應(yīng)用不做改造的前提下接入 servicemesh。好處自然不言而喻，但零侵入也有自身的限制：客戶端必須能發(fā)出符合服務(wù)器端要求的網(wǎng)絡(luò)通訊請求，這個過程外部無法插手。
對于服務(wù)間通訊，這個不是大問題。但是對于其他能力，由于有和實現(xiàn)解耦的需求，再通過客戶端自行發(fā)起原生協(xié)議的請求就不合適了。因此，Mecha 中更傾向于采用低侵入的輕量級 SDK 方案，同樣也可以實現(xiàn)跨語言和跨平臺，只是需要付出實現(xiàn)各種語言 SDK 的代價。由于這個 SDK 足夠輕量，因此代價還不算很高。
而這些少量的工作量，少量的侵入，可以換取輕量級 SDK 能提供的各種便利和配合(簡單理解：開后門)，可以實現(xiàn)能力的抽象和 API 的封裝。權(quán)衡利弊，Mecha 下更傾向于輕量級 SDK 方案。
4. 不限定 Sidecar 部署
Sidecar 部署模式，存在資源占用、維護成本增加等缺點，在某些情況下可能并不合適：
邊緣網(wǎng)絡(luò)，IoT 場景：資源非常有限，不適合啟動太多 Sidecar
FaaS 場景：應(yīng)用自身足夠輕量，甚至比 Sidecar 還要輕量
Serverless 場景：Scale to Zero 時，對冷啟動速度有嚴格要求，Sidecar 的啟動和初始化可能拖累應(yīng)用啟動速度
Mecha 下，部署模式不限定于 Sidecar ，在合適時容許選擇 Node 模式，甚至 Node 模式和 Sidecar 模式混合使用
5. API 和配置是關(guān)鍵
API 是分布式能力的抽象，需要要對(開發(fā)上層業(yè)務(wù)應(yīng)用的)客戶友好，簡單好用，穩(wěn)定不變。這些 API 也需要標準化，被社區(qū)廣泛接受和采納，才能實現(xiàn)廠商不鎖定和自由遷移，提升客戶價值。
另外，API 還需要配合配置使用，在把能力抽象為 API 時，是不提供能力的細節(jié)控制的。這些控制將在運行時由 Mecha 根據(jù)配置實現(xiàn)，可以理解為：“API + 配置 = 完整的能力”。
API 和配置的制訂以及標準化，預(yù)計將會是 Mecha 成敗的關(guān)鍵。
Mecha 的精髓
Program to an interface, not an implementation.
Design Patterns: Elements of Reusable Object-Oriented Software (GOF, 1994)
Mecha 的精髓，要從上面這句名言開始：在 Mecha 下，為了實現(xiàn) 解耦 和 可替換， Runtime 隔離 了底層實現(xiàn)，因此演變?yōu)椋?quot;Program to an Runtime, not an implementation.""
考慮到 Runtime 不管是部署為 Sidecar 模式，還是部署為 Node 模式，都是 Localhost，因此有：“Program to an Localhost, not an implementation.”
為了簡化開發(fā)，Mecha 還是會提供輕量級 SDK，提供 API 作為能力的 抽象：“Program to an API, not an implementation.”
考慮到 API 通常是以 interface 的形式提供，因此繞了一圈，Mecha 最后還是回到原點：“Program to an interface, not an implementation.”
個人理解，Mecha 的精髓就在于這幾個關(guān)鍵點：隔離 / 抽象 / 解耦 / 可替換。如下圖所示：
在 Mecha 下，MicroLogic(也就是業(yè)務(wù)邏輯的代碼實現(xiàn))不容許直接使用底層實現(xiàn)提供的分布式能力
Mecha Runtime 將為 Micro Logic 提供分布式能力，同時隔離應(yīng)用和底層實現(xiàn)
為了方便使用，提供輕量級 SDK，其中的 API 層實現(xiàn)了分布式能力的抽象，應(yīng)用只需面向 API 編程
輕量級 SDK 和 Mecah Runtime 配合，完成對底層實現(xiàn)的解耦和可替換。
Mecha 的實現(xiàn)原則
在 Mecha 的實現(xiàn)上，我理解的原則是這樣：
Runtime 是主力，要做厚
輕量級 SDK 主要是給 Runtime 打配合，要做薄
具體的職責(zé)劃分：
輕量級 SDK：實現(xiàn)多語言接入，低侵入(但不追求零侵入)
API 接口：由輕量級 SDK 中提供統(tǒng)一，目標社區(qū)化 + 標準化，給開發(fā)者提供一致的編程體驗，同時提供可移植性
應(yīng)用：輕量級 SDK/Runtime 配合，提供各種分布式能力，應(yīng)用無感，只需簡單使用 API，不耦合底層實現(xiàn)
在 Mecha 架構(gòu)中，Runtime 自然是整個架構(gòu)的核心，扮演類似 Servicemesh 中數(shù)據(jù)平面的角色
所有分布式能力使用的過程(包括訪問內(nèi)部生態(tài)體系和訪問外部系統(tǒng))都被 Runtime 接管和屏蔽實現(xiàn)
通過 CRD/ 控制平面實現(xiàn)聲明式配置和管理(類似 Servicemesh)
部署方式上 Runtime 可以部署為 Sidecar 模式，或者 Node 模式，取決于具體需求，不強制
備注：Mecha 有非常多的能力，實現(xiàn)上也有非常多的細節(jié)，這里先做一個 High Level 的概述。細節(jié)后面會有一系列文章一一覆蓋，歡迎多交流討論。
Mecha 總結(jié)
大概是在 3 月初，當(dāng)時我第一次閱讀 “Multi-Runtime Microservices Architecture” 這篇文章，有一種豁然開朗的感覺，尤其是有很多之前在反復(fù)考慮和權(quán)衡但是下不了結(jié)論的問題，在這個文章中得到了清晰的解答?？芍^受益匪淺。
在 Servicemesh 探索和實踐的這三年中，遇到很多問題，有很多之前沒有想到過的問題浮現(xiàn)。比如，以前一直覺得 Servicemesh 中引入 Sidecar 帶來的最大麻煩會是性能，但實際上，從目前的實踐看，Sidecar 引入后帶來的維護代價才是更令人頭疼的事情，相比之下 Sidecar 引入帶來的性能損失顯得無傷大雅。
總結(jié)一下我個人對 Mecha 架構(gòu)的核心理解，主要是兩點：
Mecha 是云原生化和 Mesh 化的必然趨勢：云原生在繼續(xù)發(fā)展，應(yīng)用需要的分布式能力需要繼續(xù)下沉，越來越多的能力會以 sidecar 的形式出現(xiàn)，這是大勢所趨。但不可能出現(xiàn)一個應(yīng)用部署十幾個 sidecar 的局面，這會是運維地獄。因此，必然需要出現(xiàn)新的形態(tài)來解決 Sidecar 過多的問題，合并為一個或者多個 Sidecar 就會成為必然。
Mecha 是 Servicemesh 模式的自然進化版本：Servicemesh 落地實踐三年了，效果一直并不理想，到了該反思反省的時候了;而且 Mecha 的范圍也遠不止服務(wù)間通訊，新的需求下應(yīng)該有新的思考和突破。Servicemesh 現(xiàn)有的固定模式，在 Mecha 下可以嘗試打破以探索新的方式：不必拘泥于 Sidecar，試試 Node 模式;不必拘泥于通訊協(xié)議轉(zhuǎn)發(fā)，試試 Runtime 提供能力解耦底層實現(xiàn);不必拘泥于零侵入，試試在應(yīng)用中保留一個足夠輕的輕量級 SDK。
正如曾有說法，說“微服務(wù)是 SOA 實踐中正確的部分(the Good Part)”，我希望在 Mecha 的探索和實踐中，能夠從 Servicemesh 的實踐中吸取成功的經(jīng)驗和失敗的教訓(xùn)，希望 Mecha 也能成為 Servicemesh 的 Good Part。希望在云原生的演進路線中，Mecha 可以繼微服務(wù)和 Servicemesh 之后，成為云原生落地實踐的下一站。
回到現(xiàn)實，目前 Mecha 和 Multi-Runtime 還是一個非常新的想法，Dapr 項目也才剛剛起步，Mecha 要探索的道路還很漫長，一切都還需要摸索著前進。
附錄：參考資料
在文章的最后，特別鳴謝 “Multi-Runtime Microservices Architecture”一文的作者 “Bilgin Ibryam”，我非常認可這篇文章中的思想和理念，分析歸納的非常到位，提煉和升華的能力令人佩服。
本文參考了 Bilgin Ibryam 出品的如下內(nèi)容：
Multi-Runtime Microservices Architecture，作者 Bilgin Ibryam，Mecha 的思想來自這篇文章，強烈推薦閱讀。也可以直接看我翻譯的版本 多運行時微服務(wù)架構(gòu)。如前所述，建議在閱讀本文之前先閱讀這篇博客文章。
The Evolution of Distributed Systems on Kubernetes : 作者 Bilgin Ibryam, 2020 年 3 月在 QCon London 的演講，依然強烈推薦。內(nèi)容非常精彩，對 Kubernetes 上分布式系統(tǒng)演進做了很好的總結(jié)和展望，當(dāng)然也依然在布道多運行時微服務(wù)架構(gòu)的理念。本文的很多圖片 援引自這份 PPT。
作者介紹
敖小劍，具有十八年軟件開發(fā)經(jīng)驗，資深碼農(nóng)，微服務(wù)專家，Cloud Native 擁護者，敏捷實踐者，Service Mesh 布道師，ServiceMesher 中文社區(qū)聯(lián)合創(chuàng)始人。專注于基礎(chǔ)架構(gòu)建設(shè)，對微服務(wù)、servicemesh，serverless 等云原生相關(guān)技術(shù)有著深入研究和獨到見解。
關(guān)鍵詞： Servicemesh
