不是所有的應用都需要Service Mesh架構

{"type":"doc","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"“微服務架構”的含義在過去十年裏不斷演變，今天的"},{"type":"link","attrs":{"href":"https:\/\/www.infoq.cn\/article\/service-mesh-promise-peril","title":"xxx","type":null},"content":[{"type":"text","text":"服務網格"}]},{"type":"text","text":"實現已經相當複雜，第二代 Service Mesh 誕生在 Kubernetes 之後，它的代表是 lstio。在 lstio 之外，同時存在着各種層出不窮的框架，解決的卻都是相同的問題。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"正確的選擇框架卻不是件簡單的事情。就像在容器編排領域，之前我們有 Kubernetes、Docker Swarm、Mesos 和 Cloud Foundry，其中一些後來逐漸被市場淘汰，沒有選擇 Kubernetes 的企業有可能得從頭再來一次。在微服務領域，我們不希望有類似的情形出現。現在，各種框架競爭激烈，你的業務適合採用哪一個？使用微服務架構，除了 Service Mesh 還有其他選擇嗎？針對這些問題，我們採訪了騰訊 TSF Mesh 研發及負責人張培培，他給出了一些很好的見解。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"採訪嘉賓：張培培"},{"type":"text","text":"，騰訊研發高級工程師，TSF Mesh 研發及負責人，熱衷於雲原生和開源技術，在容器、Service Mesh、消息隊列、區塊鏈等領域擁有豐富經驗，目前致力於 Service Mesh 和 Mecha 多運行的落地和推廣。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"InfoQ：這十年裏微服務領域有哪些大的變化？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"張培培："},{"type":"text","text":" 微服務的概念最早是在 2011 年威尼斯一個的軟件架構會議上被提及的，隨後又有一大批的技術框架和文章湧現出來，越來越多的公司開始借鑑和使用微服務架構相關的技術，我覺得這十年微服務架構的演進分爲四個重要階段："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"第一個階段"},{"type":"text","text":"：RPC 通信，應用從單體拆分成運行於多主機的微服務，首要解決的問題就是微服務間的通信問題，這裏又分爲兩類，一類跟語言平臺綁定的框架如阿里 Dubbo、微博 Motan、騰訊 Tars，另一類跨語言平臺的框架如 Thrift、gRPC。這個階段，特別是早期版本的 RPC 框架，並沒有支持太多的服務治理能力，開發人員需要在應用程序中解決服務發現、熔斷重試等微服務架構所面臨的問題，這就導致大量的非功能性代碼耦合在業務代碼中；"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"第二個階段"},{"type":"text","text":"：服務治理 SDK 化，隨着微服務架構在企業大規模落地，調用鏈路越來越複雜，微服務架構所面臨的問題也越來越突出，亟需一套統一且完善的服務治理能力，而最直接的集成方式就是融合到 RPC 框架中，這個階段比較有代表性的框架如 Dubbo、Spring Cloud，只需要少量代碼和註解，即可集成各種所需的服務治理能力。而 Spring Cloud 更是對各種治理能力進行了模塊化抽象如服務註冊發現 Spring Cloud Eureka、服務調用負載均衡 Spring Cloud Feign、服務熔斷 Spring Cloud Hystrix 等；"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"第三個階段"},{"type":"text","text":"：服務治理 Sidecar 化，基於 SDK 的微服務框架，解決了治理能力統一的問題，但也帶來的諸多問題，如 SDK 升級維護成本高、難以支持多語言、策略控制不統一等問題。Service Mesh 方案應運而生，服務治理能力下沉到 Sidecar，治理策略有控制面統一管理。這個階段比較有代表性的框架如 Linkerd、Istio 等；"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"第四個階段"},{"type":"text","text":"：多運行時，對於一個複雜的大型分佈式系統，不管是基於 SDK 的服務治理和 Service Mesh，更多解決的是服務間通信的問題，而一個分佈式應用的需求遠遠不止於此，還需要狀態管理如 Workflow 管理、應用冪等實現、應用執行狀態等等，需要綁定外部依賴如數據存儲、事件驅動等，傳統的方式依然是通過 SDK 集成各種分佈式能力，要真正做到應用完全專注於業務邏輯，這部分分佈式能力也應該下沉到 Sidecar，這就是由一位大牛 bibryam 提出的 Mecha 多運行時的思想，目前比較有代表性的框架如 Dapr。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"InfoQ：在您看來，爲什麼服務網格越來越受歡迎？它能解決傳統微服務架構的哪些痛點？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"張培培："},{"type":"text","text":" 先理解下什麼是傳統微服務架構，就是微服務治理能力如服務註冊、發現、熔斷、限流等與業務邏輯解耦，單獨以 SDK 的形式提供給開發者，但服務治理和業務邏輯還是跑在一個進程中的。再看下這種傳統微服務架構帶來了哪些痛點："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"numberedlist","attrs":{"start":1,"normalizeStart":1},"content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":1,"align":null,"origin":null},"content":[{"type":"text","text":"SDK 升級維護成本高，由於 SDK 耦合在業務進程中，那每次 SDK 升級必然需要綁定業務一起升級，這對於擁有成千上萬的業務系統是很難接受的，而且涉及到 SDK 大版本的變更可能還會有兼容性問題；"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":2,"align":null,"origin":null},"content":[{"type":"text","text":"多語言框架 SDK 維護成本高，SDK 意味着和語言綁定，那不同語言都要維護不同的 SDK 版本，所以很少有多語言的傳統微服務框架，能流行起來的也就是某個語言的框架如 JAVA 系的 Spring Cloud、Dubbo，go 系的 go-micro 等；"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":3,"align":null,"origin":null},"content":[{"type":"text","text":"沒有統一微服務策略控制，各種治理能力控制比較分散，配置方式也比較隨意；"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":4,"align":null,"origin":null},"content":[{"type":"text","text":"額外組件的引入特別是註冊中心帶來的運維成本。"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"而 Servive Mesh 之所以越來越受歡迎，在提供更豐富的服務治理、安全性、可觀測性等核心能力外，其從架構設計從解決了以上幾個痛點，服務治理能力以 Sidecar 的模式下沉到數據面，解決了 SDK 升級及多語言的問題，由於沒有 SDK 的依賴，開發人員可以選擇任何開發語言，只需專注於業務邏輯的開發，無需關注服務治理，Sidecar 作爲基礎設施層，也可以獨立升級。對於像負載均衡、熔斷、限流等策略配置，由控制面統一管理和配置，並下發到數據面生效。同時，Kubernetes 已被認爲是雲原生時代的操作系統，越來越多的應用基於 Kubernetes 進行編排，而主流的 Service Mesh 方案像"},{"type":"link","attrs":{"href":"https:\/\/www.infoq.cn\/article\/USRrHeuiiSUFxRf6G2vN","title":"xxx","type":null},"content":[{"type":"text","text":" Isitio"}]},{"type":"text","text":"、Linkerd 都是承載在 Kubernetes 上，那微服務的核心之一服務註冊發現，就完全不需要額外引入外部註冊中心，編排在 Kubernetes 上的應用會自動在 Mesh 體系中被感知。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"InfoQ：像 Spring Cloud 、Zuul、Eureka、Consul… 這些涵蓋了微服務體系的服務註冊與發現、限流、熔斷降級、負載均衡、服務配置的開發框架或服務組件，在設計理念上與 Service Mesh 存在哪些差別？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"張培培："},{"type":"text","text":" 像 Dubbo、Spring Cloud 都屬於傳統的微服務框架，與服務治理相關的大部分邏輯都是以 SDK 的方式耦合在具體的微服務應用之中，服務註冊、服務調用、負載均衡以及服務熔斷、限流等高級治理都需要引入 SDK，同時，爲了整個分佈式系統的正常運作，還需要額外引入註冊中心、微服務網關的基礎組件。對於服務治理策略的控制，支持硬編碼到代碼邏輯、配置文件或者遠程配置中心，基本是由開發人員控制的，像熔斷、限流、負載均衡等服務治理的策略配置，也比較分散。總之，傳統微服務框架更多的是面向開發者，沒有形成統一的微服務控制平面。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"Service Mesh 被定義爲用於處理服務間通信的基礎設施層，其在架構設計上採用了控制面 + 數據面的模式，微服務的治理能力下沉到數據面，與應用進程完全解耦，以 Sidecar 模式運行，並由控制面統一控制，以 Istio 爲例，控制面實時感知服務治理策略的變更並通過 xDS 協議下發到數據面。尤其，在以 Kubernetes 爲代表的容器編排技術逐步成爲軟件運行主流基礎環境的背景下，目前主流的 Service Mesh 方案都是基於 Kubernetes 進行構建，像 Istio 天然依託於 Kubernetes，註冊中心、邊界網關包括配置管理的基礎組件，都不需要額外引入。開發人員負責將只包含純業務邏輯的應用編排進 Kubernetes，服務治理由數據面和控制面協作完成。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"InfoQ：在您看來，目前有哪些 Mesh 主流的框架，如 lstio、Linkerd？各有什麼優勢？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"張培培："},{"type":"text","text":" 業內 Mesh 方案較多，如 Istio、Linkerd、Consul Connect，Kuma，AWS App Mesh 和 OpenShift，而成熟度較高、社區較爲活躍的無疑是 Istio 和 Linkerd。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"下面來對比下 Istio 和 Linkerd 的 Mesh 方案："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"首先"},{"type":"text","text":"，目前兩者都已經成熟，並已被多家企業用於生產，都是控制面 + 數據面的架構模式，支持多集羣多網絡的部署模式，支持 gRPC、HTTP\/2、HTTP\/1.x、Websocket 和所有 TCP 流量，涵蓋了流量管理、安全性、可觀測性等核心功能。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"其次"},{"type":"text","text":"，再看下各自的優勢。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"Istio："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"numberedlist","attrs":{"start":1,"normalizeStart":1},"content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":1,"align":null,"origin":null},"content":[{"type":"text","text":"Istio 有 IBM、Google 和 Lyft 等行業領軍者的支持，背景更加強大，社區也非常活躍；"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":2,"align":null,"origin":null},"content":[{"type":"text","text":"統一的東西流量和南北流量管理方案；"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":3,"align":null,"origin":null},"content":[{"type":"text","text":"功能相對豐富些，如熔斷、延時注入等流量控制，安全方面支持基於 RABC 的訪問控制。"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"Linkerd："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"numberedlist","attrs":{"start":1,"normalizeStart":1},"content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":1,"align":null,"origin":null},"content":[{"type":"text","text":"Linkerd 是業界的第一款 Service Mesh 框架，輕量級，相比 Istio 複雜而靈活的配置選項，Linkerd 配置簡單，且內置開箱即用的配置，安裝相對容易，運維成本也較低；"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":2,"align":null,"origin":null},"content":[{"type":"text","text":"控制面 namerd 支持直接對接多註冊中心如 Kubernetes、ZooKeeper、Consul、etcd，Istio 雖然支持 service entry、mcp over xDS 的方式擴展除 Kubernetes 外的第三方註冊中心，但需要用戶自行編寫組件擴展；"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":3,"align":null,"origin":null},"content":[{"type":"text","text":"性能較好，根據第三方基準測試，Istio 1.6 VS Linkerd 2.7，Linkerd 快 3-5 倍；"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":4,"align":null,"origin":null},"content":[{"type":"text","text":"企業支持較好，Buoyant 開發了 Linkerd OSS 版本， 提供了完整的企業級工程、支持和培訓。"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"總結下來，Istio 社區更活躍、功能更完善，也更復雜；Linkerd 更輕量、性能更好，操作簡單但也欠靈活。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"InfoQ：您認爲服務網格目前的侷限性表現在哪些方面？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"張培培："},{"type":"text","text":"Service Mesh 讓開發人員可以專注於業務邏輯的開發，無需關注服務治理，但也存在不少侷限性。Istio 是目前業內最爲流行的 Mesh 方案，下面就以 Istio 爲例參考社區的幾點總結："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"numberedlist","attrs":{"start":1,"normalizeStart":1},"content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":1,"align":null,"origin":null},"content":[{"type":"text","text":"複雜性增加，Service Mesh 通過 Sidecar 侵入到業務數據流的，而 Sidecar 對業務進程又是透明的，雖然業務代碼簡單了，但整個數據流變複雜了，一次簡單的調用從兩跳變爲六跳，這就極大的增加了開發調試及運維的難度；"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":2,"align":null,"origin":null},"content":[{"type":"text","text":"無法做到完全對應用透明，對於一些微服務框架已經集成了一些治理能力如重試機制，如果在 Sidecar 中再重試，容易引起重試風暴，還有 tracing header 的傳遞，也需要應用代碼的參與，總之，現有的業務體系接入 Mesh，還是要充分考慮到所用的框架是否和 Mesh 有重合、衝突的地方；"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":3,"align":null,"origin":null},"content":[{"type":"text","text":"對非 Kubernetes 環境支持有限，目前主流的 Service Mesh 方案像 Istio 還是比較依賴於 Kubernetes 的，對於非容器環境或者非 Kubernetes 環境，服務註冊發現、策略配置管理可能需要自行擴展，Sidecar 注入也需要自行維護管理；"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":4,"align":null,"origin":null},"content":[{"type":"text","text":"協議支持有限，目前主流的 Service Mesh 方案像 Istio、Linkerd 中 HTTP1.x\/2.0、gRPC 纔是一等公民，對於其它協議要麼只侷限在四層治理上，要麼治理能力不全如 Dubbo、Thrift、Redis 等，這就導致一些傳統的微服務框架很難直接遷移到 Service Mesh；"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":5,"align":null,"origin":null},"content":[{"type":"text","text":"擴展的門檻並不低，比如擴展第三方註冊中心，雖然 Istio 提供了多種標準的擴展方式如 controller 實現、Service entry 或者 mcp over xDS，但依然需要理解各種複雜的接口或定義並實現；再比如對私有協議的支持，首先你需要在 Istio 的 API 代碼庫中進行協議擴展，其次你需要修改 Istio 代碼庫來實現新的協議處理和下發，然後你還需要修改 xDS 代碼庫的協議，最後你還要在 Envoy 中實現相應的 Filter 來完成協議的解析和路由等功能，這過程中可能還涉及到編譯問題、代碼合併問題、開源升級問題；"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":6,"align":null,"origin":null},"content":[{"type":"text","text":"性能損耗，由於服務調研經過了 Sidecar 代理，勢必會帶來性能上的損耗，目前公開的 Service Mesh 中 Envoy 造成的額外訪問延時大概是 3 毫秒，這對延時極其敏感的業務會產生一定影響；"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":7,"align":null,"origin":null},"content":[{"type":"text","text":"資源佔用問題，考慮到開箱即用，用戶不用進行過多的配置，Istio 默認下發全量的規則，僅僅幾個服務，Envoy 所收到的配置信息就有將近 20w 行，可以想象，在稍大一些的集羣規模，Envoy 的內存開銷、Istio 的 CPU 開銷、xDS 的下發時效性等問題，也會變得尤爲突出；同時，Envoy 作爲流量代理，是 CPU 密集型應用，隨着 QPS 的增加 Envoy 的 CPU 開銷也是不可忽視，在內部一個模擬業務的壓測場景下，Envoy 要額外喫掉 20%-30% 的 CPU 資源。"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"InfoQ：爲什麼服務網格落地時，會是百花齊放的局面？很多企業會自己實現一套？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"張培培："},{"type":"text","text":" 究其原因還是很多公司的業務系統存在較重的歷史包袱，很難推翻現有平臺或框架直接替換 Service Mesh 框架，因此在實際落地時會結合當前業務場景來打造自己的 Service Mesh。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"比如：不少傳統公司還沒有容器化改造或者全量容器化改造，更不要說接入 Kubernetes，而像 Istio 這樣的 Mesh 方案是非常依賴 Kubernetes 的，那可能就需要"},{"type":"link","attrs":{"href":"https:\/\/www.infoq.cn\/video\/tElTWbzwttvCzewu4CVl","title":"xxx","type":null},"content":[{"type":"text","text":"改造 Istio"}]},{"type":"text","text":"，支持控制面容器化部署，支持數據面容器化部署，由於不依賴 Kubernetes，那服務註冊發現、策略配置管理就需要自己整一套。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"再比如，在傳統微服務框架盛行的年代，很多公司基於像 Dubbo、Spring Cloud 進行開發，或者一些公司自己的微服務體系，需要平滑、逐步遷移到 Service Mesh，那必然要考慮存量業務和 Mesh 業務共存的問題，同時保證兩者的互聯互通，而老系統有一套甚至多套註冊中心像 ZooKeeper、Consul，有完整的服務治理控制平臺，那可能就要設計註冊中心同步或者雙註冊方案。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"InfoQ：企業在實施微服務 \/ 服務網格可能會存在哪些技術債？總結起來會由哪些情況導致？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"張培培："},{"type":"text","text":" 總結下來，有以下幾個方面："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"numberedlist","attrs":{"start":1,"normalizeStart":1},"content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":1,"align":null,"origin":null},"content":[{"type":"text","text":"業務系統是否已經做了微服務改造，如果還是單體應用或者 SOA 體系，引入 Service Mesh 所帶來的"},{"type":"text","marks":[{"type":"strong"}],"text":"收益"},{"type":"text","text":"也並不明顯，反正增加了額外的運維成本；"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":2,"align":null,"origin":null},"content":[{"type":"text","text":"業務系統是否已經容器化 \/Kubernetes 編排，像主流 Mesh 方案還是強依賴於 Kubernetes，雖然對非容器環境有一定支持，但如果希望能直接融入 Mesh 體系，最好"},{"type":"text","marks":[{"type":"strong"}],"text":"先容器化"},{"type":"text","text":"；"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":3,"align":null,"origin":null},"content":[{"type":"text","text":"業務系統中服務間通信是否基於如 "},{"type":"text","marks":[{"type":"strong"}],"text":"HTTP\/gRPC"},{"type":"text","text":"，否則需要擴展第三方協議，上面也聊到擴展協議其實並不那麼輕鬆；"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":4,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"運維體系是否完善"},{"type":"text","text":"，在大規模應用場景下，大量的應用意味着有等量的 Sidecar 需要運維，一套完善的運維繫統才能保證應用及 Sidecar 在部署、灰度及升級階段中的穩定性。"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"InfoQ：在微服務選型時，您認爲需要一個什麼樣的前期的決策過程？需要哪些步驟？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"張培培："},{"type":"text","text":" 首先，捋下現有業務系統的痛點，比如，是否是單體應用微服務改造的問題，是否是傳統微服務 SDK 的升級問題，是否是多語言多框架服務治理不統一的問題。再深入瞭解下 Service Mesh 適用場景、能力矩陣，看引入 Service Mesh 是否能真正解決自己的業務痛點。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"其次，評估下上面提到的 Service Mesh 侷限性是否能接受，是否能夠駕馭的了 Service Mesh。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"最後，如果決定引入 Service Mesh，評估下現有業務系統的遷移成本，是否有完善的開發配置基礎設施如 CI\/CD、統一的治理平臺。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"Service Mesh 解耦了開發和運維，開發簡單了，但運維複雜了，如果考慮到運維成本較大或者遷移成本較大，也可以考慮下現有云廠商的 Mesh 平臺託管，目前不少雲平臺已經解決了跨 Paas 平臺、多註冊中心、多框架多協議等問題，極大的降低了遷移成本。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"InfoQ：未來還有哪些趨勢值得關注？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"張培培："},{"type":"text","text":" 未來大家可以多關注下“Mecha”多運行時的發展。如果 Service Mesh 解決的是服務間的通信問題，解決的是網絡運行時，那“Mecha”多運行時，就是 Service Mesh 的延展和昇華，對分佈式應用運行時所需的能力進行了抽象，對外暴露統一的分佈式原語 API，並且不侷限於 Sidecar 模式，甚至支持 node 模式，以適應 Iot 或者 Faas 的應用場景。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"而針對不用的應用場景和架構可能又會分化出兩種不同的落地實現："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"numberedlist","attrs":{"start":1,"normalizeStart":1},"content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":1,"align":null,"origin":null},"content":[{"type":"text","text":"微服務治理能力的多運行，可以看作是 Service Mesh 的 Mecha 實現，從目前業內 Service Mesh 的落地實踐來看，並沒有完全撼動傳統微服務系統的地位，歸根結底還是之前提到的一些侷限性導致很多公司掌控不了 Service Mesh。因此依然採用像 gRPC、Spring Cloud、Dubbo 甚至自研框架，但傳統微服務的痛點又依然存在，而微服務治理能力的多運行實現正好迎合了這種場景，路由、泳道、熔斷、負載均衡、限流、鑑權等微服務能力高度抽象，治理能力的實現和擴展下沉到 Sidecar 或 node，同時提供統一治理接口，並支持適配各種開發框架，這裏沒有實際侵入應用的數據流，因此，調用鏈路並不複雜，性能影響很小，運維成本也很小。目前，我們內部已經孵化出一款輕量級的雲原生多運行時微服務框架，支持多語言、多框架、多平臺，預計在今年10月份開源，敬請期待！"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":2,"align":null,"origin":null},"content":[{"type":"text","text":"分佈式應用能力的多運行，對於構建一個複雜的業務系統，除了需要滿足應用生命週期的管理、服務治理的需求，還需要如分佈式配置、分佈式鎖、狀態管理、事件驅動等能力，分佈式應用能力的多運行就是對諸如這些能力的抽象，對應用提供統一的訪問接口，這種實現方式就不過多介紹，有興趣的可以瞭解下業內第一個多運行的開源實踐項目 Dapr。"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}}]}