亂彈微服務

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 在容器領域先下一城，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 。Oracle 本身也搞了一個 Helidon。

都有各自的一些賣點,可是彷佛社區並不買賬。可是它們都跟 Reactive Programming（反應式編程） 扯上了關係，這多是另外一種趨勢。微服務還在不停的向前推進，如今你不知道微服務都很差意思說你是搞後端的。

而後回到如今的 TARS，如今的公司不搞個基金會弄個開源項目，都很差意思說你是技術公司。TARS 一樣走了一條本身的路，可是這條路目前我我的並不看好。

5. 你真的須要微服務嗎

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

業務是否須要

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

團隊是否準備好了

微服務意味着將應用「複雜化了」，從單體應用分割到多個應用，從團隊的技術素質、運維能力都是一種考驗。團隊是否可以充分應對分佈式帶來的負面做用。