1. 前言

3 月 10 日，linux 基金會宣布旗下項目 TARS 正式成立 TARS 基金會，宣稱致力于構建微服務。該項目是騰訊公司捐獻給 Linux 基金會的一個項目，據稱該項目在騰訊已經使用了近 10 年，有大量的實踐經驗。為什么這么多公司打算在微服務領域進行深耕呢？我們真的需要微服務嗎？今天來聊一聊這些微服務。

2. Spring Cloud

Spring 官方在 14 年下半年出了 Spring Cloud。2016 年底無意中看到這個，當時國內資料很少也很少聽說便沒有過于在意。2017 年有同事安利了這個東西，也是從這個時候“微服務”這個概念在技術圈“熱”了起來。我便花了很大的精力學習了一番。一直到 2018 年下半年才有機會實踐中使用 Spring Cloud 。但是這個項目半年就“夭折”了，需求不明確，業務推進緩慢。

我一直不明白為什么當時 Leader 堅持使用 Spring Cloud ，從當時人力和業務都不應該使用它。畢竟很多場景需要的路由控制、限流等一些需要定制化的功能要花一些精力去處理，而且業務劃分是否合理也決定了微服務的復雜程度。我覺得更多的有“炫技”成分在里面。我個人覺得是否使用微服務一定要看業務的推進情況。不過 Spring Cloud 也為面試作出了很多的貢獻。

2018 年 11 月，當 Netflix 宣布旗下被 Spring Cloud 所依賴的諸多項目進入維護模式后，Spring Cloud 開始出現了一些危機。因為 Spring Cloud 只是作為上層的規范，底層依賴于第三方的輪子。這也符合 Spring 官方的一慣風格。

不過好在危機持續時間并不長，因為早在 2018 年 7 月底 Alibaba 就開始孵化 Spring Cloud Alibaba 項目了。這應該是國產項目第一次進入 Spring 體系進行孵化并在2019 年 8 月 1 日正式畢業。目前Spring Cloud Alibaba 已經發布了數個正式版本，成為目前 Spring Cloud 生態圈的重要組成部分。

借助于 Spring 的頭部地位，Spring Cloud 也成為目前受眾最廣的開源微服務體系。對于普通 JAVA 開發者來說從一般應用過渡到微服務的最好途徑可能就是 Spring Cloud 了。

3. Service Mesh

正當我學習 Spring Cloud 的時候，另一個微服務體系 Service Mesh 也出現了。當然 Service Mesh 出場有點霸道，直接宣布它就是下一代的微服務的標準。什么？下一代？這一代我還沒搞明白呢！相信很多人跟我一樣都是這么想的。

3.1 什么是 Service Mesh

Service Mesh 是微服務時代的 TCP 協議

我們拿比較好理解的 Spring Cloud 來說，它實現了微服務所需要的一系列基礎功能：負載均衡、服務治理、熔斷降級等，并屏蔽了其中的技術細節，讓我們很容易就可以開發出穩定的分布式系統。但是我們發現我們需要花更多精力去研究Spring Cloud本身才能更好的來貼合我們的業務。同時我們需要集成很多的庫來實現諸如服務注冊與發現，熔斷降級，負載均衡等業務無關的功能，就像一個既要搞前端又要后端，甚至需要自己去收集需求的開發一樣。

我們需要有一個專門的代理幫我們來做這些事情，而我們只專注于業務。服務之間的復雜交互由代理來做，我們不再過分操心非業務功能。這種組合模式也就是 Sidecar 模式，Sidecar來源于“三蹦子”。

然后所有的代理連起來就組成了一張通訊網：

為了更加清晰展示我們把業務服務隱藏掉，同時為了集中對代理組建進行拓撲更新和控制，又抽象出一個控制面板：

Service Mesh 更像是一種微服務的呈現風格。

3.2 Service Mesh 發展史

Service Mesh 的高調面市正是各家容器技術標準搶占地位的時候，雖然 Docker 在容器領域先下一城，但是 K8S 也開始發力，誰贏得標準之爭誰就會占據市場的核心地位。我認為這一時期 Service Mesh 正好契合了谷歌的需要，使得谷歌為之站臺，Service Mesh 布道者William Morgan 和 Oliver Gould 發起的第一個 Service Mesh 項目Linkerd 順利加入谷歌主導的 CNCF 基金會。

天下沒有免費的午餐，谷歌此時已經聯合 IBM 、Lyft 啟動了 Istio 項目，開始著手第二代 Service Mesh 的布局。就在Linkerd加入CNCF四個月后，Istio 發布了第一個 Release 版本，雖然 Bug 眾多。社區反響熱烈，群眾們紛紛表示歡迎并站隊。Linkerd 直接成了“過氣網紅”。Istio 的使命是為谷歌K8S生態圈的延伸，建立其在微服務領域的頭部位置。

憧憬是美好的，從一開始 Istio 就是一個“早產兒”，數個版本都存在可用性不足的情況，除了一些頭部公司很少有相關的落地案例，甚至一些公司也是處于研究階段。不過隨著Istio 1.5的發布這一狀況正在得到改善。但是 Service Mesh 目前還屬于微服務的金字塔， 需要熟練運用容器技術以及出色的運維能力，學習曲線相對陡峭一些。

4. 其它

還有其它一些企業，也想在微服務領域有一席之地，比如 RedHat 推出了 Quarkus 。Oracle 自己也搞了一個 Helidon。

都有各自的一些賣點,但是似乎社區并不買帳。但是它們都跟 Reactive Programming（反應式編程） 扯上了關系，這可能是另一種趨勢。微服務還在不停的向前推動，現在你不知道微服務都不好意思說你是搞后端的。

然后回到現在的 TARS，現在的公司不搞個基金會弄個開源項目，都不好意思說你是技術公司。TARS 同樣走了一條自己的路，但是這條路目前我個人并不看好。

5. 你真的需要微服務嗎

在開始實施微服務前你要考慮一些問題，而不是隨大流。這也是一些中小企業容易犯的錯誤。

業務是否需要

技術服務于業務是亙古不變的鐵律。微服務解決了你當前業務的什么問題，帶來了什么問題你要清楚。一共幾萬人的應用，日活區區幾千人，你搞微服務？

團隊是否準備好了

微服務意味著將應用“復雜化了”，從單體應用分割到多個應用，從團隊的技術素質、運維能力都是一種考驗。團隊是否能夠充分應對分布式帶來的負面作用。