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