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 日正式畢業[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 來源于“三蹦子”。
然後所有的代理連起來就組成了一張通訊網：
img
為了更加清晰展示我們把業務服務隐藏掉，同時為了集中對代理組建進行拓撲更新和控制，又抽象出一個控制台：
★
Service Mesh 更像是一種微服務的呈現風格。
”
3.2 Service Mesh 發展史
Service Mesh 的高調面市正是各家容器技術标準搶占地位的時候，雖然 Docker 在容器領域先下一城，TARS 但是 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[2] 。Oracle 自己也搞了一個 Helidon[3]。
都有各自的一些賣點,但是似乎社群并不買帳。但是它們都跟 Reactive Programming（反應式程式設計） 扯上了關系，這可能是另一種趨勢。微服務還在不停的向前推動，現在你不知道微服務都不好意思說你是搞後端的。
然後回到現在的 TARS，現在的公司不搞個基金會弄個開源項目，都不好意思說你是技術公司。TARS 同樣走了一條自己的路，但是這條路目前我個人并不看好。
5. 你真的需要微服務嗎
在開始實施微服務前你要考慮一些問題，而不是随大流。這也是一些中小企業容易犯的錯誤。
業務是否需要
技術服務于業務是亘古不變的鐵律。微服務解決了你目前業務的什麼問題，帶來了什麼問題你要清楚。一共幾萬人的應用，日活區區幾千人，你搞微服務？
團隊是否準備好了
微服務意味着将應用“複雜化了”，從單體應用分割到多個應用，從團隊的技術素質、運維能力都是一種考驗。團隊是否能夠充分應對分布式帶來的負面作用。