雲原生雖已被公認是新一代雲端計算髮展方向，但若從應用程式的開發、測試、執行以及最後部署到雲環境中的過程看，實現雲原生業務要打通許多技術。

微服務通常被看做是雲原生的代表技術之一，在單體應用中，雲原生基本發揮不出優勢，故而有人說現代應用程式的趨勢就是“微服務+雲原生”，以及內含在其中的容器、敏捷與 DevOps 等技術組合。網際網路海量和多變的業務，正要求多種功能的同時實現，同樣是要集合各種技術。

8 月 1 日，線上舉辦的 CloudNative + Open Source Virtual Summit China 2020，TARS 基金會分論壇上釋出了 K8STARS 專案，這是一個整合了 K8S 和微服務框架 TARS 功能的專案，對於 TARS 專案本身來說，彌補了其自身的自動擴伸縮等能力，增強了其雲原生特性。

放到雲原生中來看，微服務架構應用系統後期會面臨許多挑戰，比如持續整合、持續交付、持續部署、監控、認證、授權以及快速配置計算資源等等，而 Kubernetes 提供如資源的排程、彈性伸縮、自動化部署等能力，是許多微服務在實施應用時不可或缺的。

正如這幾日 TARS 基金會分論壇上 Linux 基金會執行董事 Jim Zemlin 在開場時提到的：TARS 基金會致力於解決在使用微服務方面可能出現的問題，包括減少開發和服務治理的難度。而基金會中最主要的專案 TARS 也不僅僅只是一個 RPC 框架。

TARS 基金會成立於今年 3 月 10 日，是 Linux 基金會中微服務開源生態的代表。這次論壇上，TARS 基金會主席單致豪詳細介紹了基金會目前的生態，並公佈了近期加入 TARS 基金會的 4 個開源專案：測試相關的 TARS Benchmark 與 TARS JMeter，服務閘道器 TARS Gateway，以及重磅釋出的雲原生微服務治理方案 K8STARS。

其中 TARS Gateway 是一套基於 TARS 框架開發的通用 API 閘道器，請求使用 HTTP 協議，後端同時支援 TARS-tup&TARS-TARS 協議、TARS-json 協議、HTTP 協議。除了協議轉發之外，還支援流量控制與黑白名單等功能；TARS JMeter 是一款針對 TARS 協議進行私有化定製的 JMeter 測試外掛，它具有易用性強、支援分散式、支援複雜場景與資料可監控等特點；TARS Benchmark 是專門為 TARS 服務量身訂做的無碼壓測工具，具備易用性、高效能、可伸縮、支援動態隨機和資料實時反饋的特性。 

下邊具體說說 K8STARS。

K8STARS：基於 K8S 與 TARS 的雲原生微服務治理方案

微服務架構已然成為雲原生中最核心的技術之一，TARS 結合 Kubernetes 帶來的優勢突破或讓 TARS 這個微服務框架在雲原生生態中更上一層樓，也將讓 TARS 基金會覆蓋更寬廣的領域。

先介紹一下 K8STARS，簡單來講，K8STARS 是便於將 TARS 服務執行在 Kubernetes 中的解決方案，它的主要特性包括：

• 保持 TARS 原生的開發框架能力

• 支援 TARS 的名字服務自動註冊和配置刪除

• 支援原有 TARS 服務平滑遷移到 Kubernetes 等容器平臺

• 無侵入性設計，與執行環境無偶合關係

騰訊高階工程師、TARSGo 核心開發者利開園在分享中更具體地分析了 K8STARS 解決方案。簡單來說，K8STARS 保留了 TARS 的名字服務、高效能 RPC 及服務治理功能，整合了 K8S 的資源排程等能力，使得 TARS 具有更多的雲原生特性。

微服務的理念下，使用容器作為基礎設施，能夠實現快速部署、快速迭代。而隨著容器化技術興起，Kubernetes 可以說已經成為基於容器的 DevOps+微服務+容器的黃金標準。整合 K8S 成為許多微服務框架完善功能的一個大方向。

利開園總結，業務規模增長會帶來四大挑戰：

• 隨著使用者流量增長，需要分散式架構，以及更高效能的快取等；

• 為了滿足高效能的要求，需要更多的研發人員以及更好的協調，這就需要通用的通訊協議、多語言開發框架等；

• 隨著伺服器數量的增長，還有龐大數量的叢集需要管理，此時需要機房故障時的自動解決方案；

• 最後服務程序數量暴漲，處理好併發的服務也是一個難點。

TARS 的主要能力是高效率開發，如程式碼自動生成、多語言、名字服務等等；高質量運維，如服務視覺化、無損變更、配置管理與容災容錯等。“然而，在面對業務規模增長帶來的技術挑戰時，TARS 也有需要增強的地方。”

“TARS 可以使開發者專注業務邏輯，而不需要關心底層，但是 TARS 過去是沒有自動擴伸縮能力的。”利開園介紹：“TARS 需要用到 K8S 的自動排程和自動擴縮容的能力。”

不過 TARS 和 K8S 存在許多重合的能力，想要整合並不簡單。同時 K8S 生態中，Istio 是最熱門的微服務解決方案，此時是不是直接放棄 TARS 轉向 Istio 更好？

▲中間部分為重合的能力

對比了 TARS 和 Istio 的優缺點之後，考慮到 TARS 服務遷移的成本，開發團隊覺得有必要使用 TARS，將 TARS 改造成支援在 K8S 中排程的微服務解決方案。

▲選型中考慮的 TARS 與 Istio 的情況

具體怎麼整合呢？TARS 比 K8S 多出的能力包括高效能 RPC 框架、日誌監控、呼叫鏈以及指標監控等服務治理能力；二者重合的功能有服務部署、版本管理等。整合首先要對重合功能做出取捨，因為 K8S 支援自動排程，基於 Docker 映象可有更好的版本管理實現；而在名字服務部分，TARS 支援閘道器流量，發現單點故障時可快速遮蔽問題，配置管理也更適合在生產環境中使用。

通過在 TARSregistry 增加了 3 個介面，用於 TARS 名字的自動註冊/心跳上報和節點下線，同時提供一個 TarsCLI 命令列工具，用於分配埠/生成配置/上報心跳以及節點下線，最終整合出了 K8STARS 這一全新的解決方案，讓 TARS 服務執行在 Kubernetes 上。

具體細節可以檢視專案說明與原始碼：https://github.com/TarsCloud/K8STARS

從 TARS 到 TARS 基金會到雲原生微服務開源生態

前邊提到，本次分論壇較為全面地對外介紹了成立於今年 3 月的 TARS 基金會的情況，這也是其首次分享其生態相關資訊。

作為基金會，發展的是生態而不是單一專案，TARS 基金會介紹其希望吸納上下游的開源專案，以建立更好的微服務生態。包含但不限於基礎設施、儲存、開發框架、服務治理、DevOps 和基於任何程式語言的應用。具體來講，目前基金會中已經有 30+ 專案，7 家成員組織，以及獲得了覆蓋遊戲、影片直播、網際網路工具、娛樂、交通、社交網路與金融等領域 100+ 家公司/企業的採用。

此外，分論壇還有來自不同公司不同業務的技術專家分享了 TARS 在其各自領域上的具體應用情況，比如自騰訊的陳德賢、閱文的馬延波與虎牙的毛茂德分享了各自業務中採用 TARS 進行微服務架構改造的情況；同時，TarsJava 技術負責人俞慧濤分享了閱文 TARS 的海外最佳實踐；Arm 企業級架構師、TARS 技術監督委員會成員 Tina Tsou 分享瞭如何通過 Arm 架構和 Ampere Computing 支援 TARS 平臺上的雲原生工作負載加速；來自 Apache APISIX 的 TARS 技術監督委員會成員溫銘強調了 API 閘道器在雲原生體系中的重要性；最後騰訊 CSIG 高階測試專家魯珺聊到了如何實現微服務效能評測。

從周邊專案、開發者與社群成員的發展情況，從專案演進，到硬體架構擴充套件，再到應用實踐以及效能測試等方面，TARS 基金會分論壇在此次雲原生峰會中為開發者呈現了一個正在快速發展中的雲原生微服務開源生態。

最後，或者這張生態全景圖可以很好地勾勒出 TARS 基金會未來的發展全貌，當然，生態還在動態演進，具體會如何發展，是留給 TARS 基金會這一新生組織的一大問題，也是關注雲原生微服務開源生態的開發者的一大期待。