3 月 10 日，Linux 基金會宣布旗下項目 TARS 正式成立 TARS 基金會，宣稱致力于構(gòu)建微服務(wù)。該項目是騰訊公司捐獻給 Linux 基金會的一個項目，據(jù)稱該項目在騰訊已經(jīng)使用了近 10 年，有大量的實踐經(jīng)驗。為什么這么多公司打算在微服務(wù)領(lǐng)域進行深耕呢？我們真的需要微服務(wù)嗎？今天來聊一聊這些微服務(wù)。
2. Spring CloudSpring 官方在 14 年下半年出了 Spring Cloud。2016 年底無意中看到這個，當(dāng)時國內(nèi)資料很少也很少聽說便沒有過于在意。2017 年有同事安利了這個東西，也是從這個時候“微服務(wù)”這個概念在技術(shù)圈“熱”了起來。我便花了很大的精力學(xué)習(xí)了一番。一直到 2018 年下半年才有機會實踐中使用 Spring Cloud 。但是這個項目半年就“夭折”了，需求不明確，業(yè)務(wù)推進緩慢。
我一直不明白為什么當(dāng)時 Leader 堅持使用 Spring Cloud ，從當(dāng)時人力和業(yè)務(wù)都不應(yīng)該使用它。畢竟很多場景需要的路由控制、限流等一些需要定制化的功能要花一些精力去處理，而且業(yè)務(wù)劃分是否合理也決定了微服務(wù)的復(fù)雜程度。我覺得更多的有“炫技”成分在里面。我個人覺得是否使用微服務(wù)一定要看業(yè)務(wù)的推進情況。不過 Spring Cloud 也為面試作出了很多的貢獻。
2018 年 11 月，當(dāng) Netflix 宣布旗下被 Spring Cloud 所依賴的諸多項目進入維護模式后，Spring Cloud 開始出現(xiàn)了一些危機。因為 Spring Cloud 只是作為上層的規(guī)范，底層依賴于第三方的輪子。這也符合 Spring 官方的一慣風(fēng)格。
不過好在危機持續(xù)時間并不長，因為早在 2018 年 7 月底 Alibaba 就開始孵化 Spring Cloud Alibaba 項目了。這應(yīng)該是國產(chǎn)項目第一次進入 Spring 體系進行孵化并在2019 年 8 月 1 日正式畢業(yè)。目前Spring Cloud Alibaba 已經(jīng)發(fā)布了數(shù)個正式版本，成為目前 Spring Cloud 生態(tài)圈的重要組成部分。
借助于 Spring 的頭部地位，Spring Cloud 也成為目前受眾最廣的開源微服務(wù)體系。對于普通 Java 開發(fā)者來說從一般應(yīng)用過渡到微服務(wù)的最好途徑可能就是 Spring Cloud 了。
3. Service Mesh正當(dāng)我學(xué)習(xí) Spring Cloud 的時候，另一個微服務(wù)體系 Service Mesh 也出現(xiàn)了。當(dāng)然 Service Mesh 出場有點霸道，直接宣布它就是下一代的微服務(wù)的標(biāo)準(zhǔn)。什么？下一代？這一代我還沒搞明白呢！相信很多人跟我一樣都是這么想的。
3.1 什么是 Service MeshService Mesh 是微服務(wù)時代的 TCP 協(xié)議
我們拿比較好理解的 Spring Cloud 來說，它實現(xiàn)了微服務(wù)所需要的一系列基礎(chǔ)功能：負載均衡、服務(wù)治理、熔斷降級等，并屏蔽了其中的技術(shù)細節(jié)，讓我們很容易就可以開發(fā)出穩(wěn)定的分布式系統(tǒng)。但是我們發(fā)現(xiàn)我們需要花更多精力去研究Spring Cloud本身才能更好的來貼合我們的業(yè)務(wù)。同時我們需要集成很多的庫來實現(xiàn)諸如服務(wù)注冊與發(fā)現(xiàn)，熔斷降級，負載均衡等業(yè)務(wù)無關(guān)的功能，就像一個既要搞前端又要后端，甚至需要自己去收集需求的開發(fā)一樣。
我們需要有一個專門的代理幫我們來做這些事情，而我們只專注于業(yè)務(wù)。服務(wù)之間的復(fù)雜交互由代理來做，我們不再過分操心非業(yè)務(wù)功能。這種組合模式也就是 Sidecar 模式，Sidecar 來源于“三蹦子”。
然后所有的代理連起來就組成了一張通訊網(wǎng)：
為了更加清晰展示我們把業(yè)務(wù)服務(wù)隱藏掉，同時為了集中對代理組建進行拓撲更新和控制，又抽象出一個控制面板：
3.2 Service Mesh 發(fā)展史Service Mesh 更像是一種微服務(wù)的呈現(xiàn)風(fēng)格。
Service Mesh 的高調(diào)面市正是各家容器技術(shù)標(biāo)準(zhǔn)搶占地位的時候，雖然 Docker 在容器領(lǐng)域先下一城，但是 K8S 也開始發(fā)力，誰贏得標(biāo)準(zhǔn)之爭誰就會占據(jù)市場的核心地位。我認為這一時期 Service Mesh 正好契合了谷歌的需要，使得谷歌為之站臺，Service Mesh 布道者William Morgan 和 Oliver Gould 發(fā)起的第一個 Service Mesh 項目Linkerd 順利加入谷歌主導(dǎo)的 CNCF 基金會。
天下沒有免費的午餐，谷歌此時已經(jīng)聯(lián)合 IBM 、Lyft 啟動了 Istio 項目，開始著手第二代 Service Mesh 的布局。就在Linkerd加入CNCF四個月后，Istio 發(fā)布了第一個 Release 版本，雖然 Bug 眾多。社區(qū)反響熱烈，群眾們紛紛表示歡迎并站隊。Linkerd 直接成了“過氣網(wǎng)紅”。Istio 的使命是為谷歌K8S生態(tài)圈的延伸，建立其在微服務(wù)領(lǐng)域的頭部位置。
憧憬是美好的，從一開始 Istio 就是一個“早產(chǎn)兒”，數(shù)個版本都存在可用性不足的情況，除了一些頭部公司很少有相關(guān)的落地案例，甚至一些公司也是處于研究階段。不過隨著Istio 1.5 的發(fā)布這一狀況正在得到改善。但是 Service Mesh 目前還屬于微服務(wù)的金字塔， 需要熟練運用容器技術(shù)以及出色的運維能力，學(xué)習(xí)曲線相對陡峭一些。
4. 其它還有其它一些企業(yè)，也想在微服務(wù)領(lǐng)域有一席之地，比如 RedHat 推出了 Quarkus 。Oracle 自己也搞了一個 Helidon。
都有各自的一些賣點,但是似乎社區(qū)并不買帳。但是它們都跟 Reactive Programming（反應(yīng)式編程） 扯上了關(guān)系，這可能是另一種趨勢。微服務(wù)還在不停的向前推動，現(xiàn)在你不知道微服務(wù)都不好意思說你是搞后端的。
然后回到現(xiàn)在的 TARS，現(xiàn)在的公司不搞個基金會弄個開源項目，都不好意思說你是技術(shù)公司。TARS 同樣走了一條自己的路，但是這條路目前我個人并不看好。
5. 你真的需要微服務(wù)嗎在開始實施微服務(wù)前你要考慮一些問題，而不是隨大流。這也是一些中小企業(yè)容易犯的錯誤。
業(yè)務(wù)是否需要技術(shù)服務(wù)于業(yè)務(wù)是亙古不變的鐵律。微服務(wù)解決了你當(dāng)前業(yè)務(wù)的什么問題，帶來了什么問題你要清楚。一共幾萬人的應(yīng)用，日活區(qū)區(qū)幾千人，你搞微服務(wù)？
團隊是否準(zhǔn)備好了微服務(wù)意味著將應(yīng)用“復(fù)雜化了”，從單體應(yīng)用分割到多個應(yīng)用，從團隊的技術(shù)素質(zhì)、運維能力都是一種考驗。團隊是否能夠充分應(yīng)對分布式帶來的負面作用。
