作者黃挺，螞蟻金服高級技術(shù)專家，螞蟻金服分布式架構(gòu) SOFA 的開源負(fù)責(zé)人。目前在螞蟻金服中間件團(tuán)隊(duì)負(fù)責(zé)應(yīng)用框架與服務(wù)化相關(guān)的工作。
本文根據(jù)黃挺在 2018/09/01 微服務(wù)實(shí)踐沙龍（上海站）分享整理，這篇文章中，一共列舉了 SOFA 在發(fā)展過程中四種多語言的支持方式。
多語言的現(xiàn)狀
世界上的編程語言千千萬，每個(gè)人都有自己偏好的語言，
有人認(rèn)為 PHP 是世界上最好的語言。也有人非常喜歡 Java，強(qiáng)類型，泛型，多態(tài)，性能也非常不錯(cuò)。也有人很喜歡 Ruby，再比如 Paul Graham 在他著名的「黑客與畫家」的書中表達(dá)了對 Lisp 的無限喜愛。個(gè)人對于語言的喜好是無可厚非的。
相信大家都聽說過巴別塔，人類想要造巴別塔通天，上帝知道了，就讓不同族群的人類說不同的語言，最后人類之間由于語言溝通不流暢，巴別塔沒有造成。從這個(gè)故事中我們可以學(xué)到要做成一件事情，溝通是多么地重要。
假設(shè)一家公司的業(yè)務(wù)的目標(biāo)就是通天，我們都知道只使用一門語言是不能解決所有的問題，前端幾乎都是 JavaScript 系的語言，后端的語言則更加五花八門，從現(xiàn)實(shí)地角度來看，必須選擇不同的語言來解決不同的問題，那么這些語言之間怎么做相互通信，就是我們需要去解決的問題。
回到微服務(wù)這個(gè)領(lǐng)域，如果要解決基本的通信的問題，基本上只要解決三個(gè)問題就可以了，首先是基本的網(wǎng)絡(luò)通信的能力，然后是雙方需要協(xié)商好數(shù)據(jù)怎么序列化和反序列化，最后要解決服務(wù)發(fā)現(xiàn)的問題，要調(diào)用對方的服務(wù)，總得知道從哪里去尋找對方的服務(wù)吧。
但是解決完這些基本的問題之后，因?yàn)槲⒎?wù)把整個(gè)系統(tǒng)給分布式化了，接下來我們又得面對分布式的問題，這個(gè)領(lǐng)域的問題可就多了，包括負(fù)載均衡，鏈路追蹤，限流，熔斷，鏈路加密，服務(wù)鑒權(quán)等等一大堆的問題。那么在微服務(wù)這個(gè)領(lǐng)域下去解決多語言的問題，我們就必然要在這些問題上做考量，做抉擇。
簡單的解決方式
首先，我們嘗試一個(gè)比較簡單的方法來解決多語言的問題，假設(shè)現(xiàn)在有一個(gè) Java 寫的 SOFA 系統(tǒng)，它通過 SOFARPC 里面的默認(rèn)的長連接基于 TCP 的協(xié)議 Bolt 暴露了一個(gè)服務(wù)，這個(gè)時(shí)候有一個(gè) NodeJS 的系統(tǒng)需要去調(diào)用它，最簡單的方式可以怎么做呢？
我們可以嘗試在 SOFA 這一端把原來的服務(wù)通過一種新的形式給暴露出來，提供一個(gè)JSONover HTTP 的形式讓 NodeJS 的系統(tǒng)去調(diào)用，在 SOFA 里面去提供一個(gè) JSON over HTTP 的服務(wù)非常方便，只要對原來的配置稍作修改即可。
為什么選擇 JSON over HTTP 的方式呢？因?yàn)?JSON 以及 HTTP 在每個(gè)語言里面幾乎都有原生的支持，即使沒有原生的支持，也有三方庫來支持，而且相對來說，每個(gè)語言支持地都比較好。通過 JSON over HTTP，我們解決了網(wǎng)絡(luò)通信和序列化的問題。
服務(wù)發(fā)現(xiàn)的問題怎么來解決呢？也很簡單，可以通過一些 F5 的這樣的設(shè)備，然后 NodeJS 的應(yīng)用通過 DNS 的方式去發(fā)現(xiàn) F5 的設(shè)備，然后通過 F5 這樣的設(shè)備再將請求轉(zhuǎn)到后面的 SOFA 應(yīng)用的集群上面，就可以解決了，這邊可能需要去做的就是花點(diǎn)錢，買個(gè)負(fù)載均衡設(shè)備而已，當(dāng)然，如果你用 K8s 的話，那么就可以通過 K8s 的 Service，Service 對于使用方來說，跟 DNS 是一模一樣的。
但是這種方式只能解決服務(wù)發(fā)現(xiàn)以及基本的通信的問題，另外的一些高階的能力，比如熔斷，限流等能力，都無法通過這種方式來解決。所以這種方式比較適合于在一些相對來說邊緣的場景下去解決多語言通信問題，如果調(diào)用過程中的流量可用，不會(huì)有突發(fā)的流量，錯(cuò)誤也是可以忍受的，那么采用這種方式可能是比較經(jīng)濟(jì)實(shí)惠的。這個(gè)也是螞蟻金服早期很多多語言的場景的普遍的方式。
“重復(fù)造輪子”
隨著 NodeJS 在業(yè)界關(guān)注度越來越高，螞蟻金服也希望將 NodeJS 應(yīng)用在更加核心的場景，在當(dāng)前的螞蟻的整個(gè)體系中，BFF 層更多都是由 NodeJS 的應(yīng)用來承擔(dān)。
把 NodeJS 應(yīng)用在核心場景下，上面提到的第一種方式當(dāng)然是完全不夠的，我們需要的不僅僅是一個(gè)簡單的通信的方式，而是一個(gè)完整的微服務(wù)的解決方案。恰好螞蟻的 NodeJS 團(tuán)隊(duì)的技術(shù)實(shí)力也非常地深厚，所以就想到了可以通過將 Java 體系中的各個(gè)微服務(wù)的組件做一個(gè) NodeJS 的版本，比如對于通信協(xié)議 Bolt，在 NodeJS 這邊，也搞了一個(gè) sofa-bolt-node，對于 Hessian 序列化的協(xié)議，也搞了一個(gè) NodeJS 的 Hessian 的支持 sofa-hessian-node，對于 SOFARPC，也搞了一個(gè) sofa-rpc-node，其他的能力，比如服務(wù)發(fā)現(xiàn)，負(fù)載均衡，限流/熔斷，鏈路追蹤等等，都有對應(yīng)的 NodeJS 的實(shí)現(xiàn)。
這種對應(yīng)的一個(gè)語言重復(fù)造一遍輪子的方式比較好的支撐了 NodeJS 在螞蟻金服作為 BFF 層的發(fā)展，并且通過這種方式，各項(xiàng)功能基本上沒有太大的損失，基本上 Java 能夠?qū)崿F(xiàn)的能力，NodeJS 也都能夠?qū)崿F(xiàn)。
但是隨著時(shí)間的推移，我們發(fā)現(xiàn)這種造輪子的方式也有一些無法繞過的問題，前面說到 Java 的微服務(wù)框架的能力 Node 基本上都能夠?qū)崿F(xiàn)，但是對于一些能力已經(jīng)深入地使用了 Java 語言特性的一些能力，比如注解，在 NodeJS 中是無法直接實(shí)現(xiàn)的，導(dǎo)致 NodeJS 這一端只能用一些非常 Hack 的方式來解決這種類型的問題。另外，就是在多語言的維護(hù)成本上，同樣的功能，需要 Java 和 NodeJS 維護(hù)兩套，這種方式不但對于每個(gè)語言的團(tuán)隊(duì)的要求比較高，而最終也導(dǎo)致同一個(gè)功能，往往需要相比于原來兩倍的能力來實(shí)現(xiàn)，同樣的 Bug，可能也需要 Fix 兩次。
總結(jié)來說，這種方式可以讓大部分的功能在不同的語言中都得到比較好的實(shí)現(xiàn)，但是一旦一些功能和特定的語言特性綁定，別的語言實(shí)現(xiàn)起來就會(huì)非常 Hack，并且不容易維護(hù)。另外，這種方式需要整個(gè)團(tuán)隊(duì)付出比較多的成本，成本往往和語言的個(gè)數(shù)成正比，兩個(gè)語言可能還好，但是一旦出現(xiàn)更多的語言需要支持，成本可能就難以承受。
多語言網(wǎng)關(guān)
相信每個(gè)公司多多少少都有一個(gè) API 網(wǎng)關(guān)，這個(gè)網(wǎng)關(guān)往往負(fù)責(zé)多端的接入，并且也會(huì)有多協(xié)議的支持，瀏覽器端可能會(huì)采用 HTTPS 來接入，iOS 和 Android 可能會(huì)采用私有的協(xié)議來對接，API 網(wǎng)關(guān)會(huì)將接入端的協(xié)議最終再轉(zhuǎn)換成內(nèi)部的協(xié)議，并且作為一個(gè) API 網(wǎng)關(guān)，往往也會(huì)有鑒權(quán)，限流等等能力。
API 網(wǎng)關(guān)作為微服務(wù)體系里面的一部分，其需要解決的問題和整個(gè)微服務(wù)體系需要去解決的問題非常類似，作為 API 網(wǎng)關(guān)，本身就需要去對接多語言的客戶端（iOS，Android），可以說非常適合用 API 網(wǎng)關(guān)類似的方式來解決多語言問題。
我們可以基于 API 網(wǎng)關(guān)改造出一個(gè)作用于內(nèi)部的多語言的網(wǎng)關(guān)出來，在多語言網(wǎng)關(guān)這一層來實(shí)現(xiàn)微服務(wù)上的一些限流，熔斷，服務(wù)鑒權(quán)，負(fù)載均衡等等能力，這樣，這些能力就不用每個(gè)語言單獨(dú)去實(shí)現(xiàn)，只需要實(shí)現(xiàn)一次就夠了。但是對于服務(wù)發(fā)現(xiàn)這一塊，業(yè)務(wù)系統(tǒng)還是需要用某種服務(wù)發(fā)現(xiàn)的機(jī)制來發(fā)現(xiàn)多語言網(wǎng)關(guān)，這部分還是需要選擇一個(gè)通用的方案，比如 DNS + F5，或者每個(gè)語言單獨(dú)實(shí)現(xiàn)。
除此之外，多語言網(wǎng)關(guān)因?yàn)槭羌惺降夭渴?，還會(huì)引入一個(gè)新的問題，就是資源隔離的問題，假設(shè)多語言網(wǎng)關(guān)后端的一個(gè)服務(wù)突然變慢了，那么可能會(huì)將多語言網(wǎng)關(guān)自己給拖垮掉，進(jìn)而影響到多語言網(wǎng)關(guān)代理的其他服務(wù)。
要解決這個(gè)問題，有兩種方式可以去解決，一種是做線程池的隔離，可以給一些重要的業(yè)務(wù)一些單獨(dú)的線程池，不重要的業(yè)務(wù)再放到一個(gè)大的單獨(dú)的線程池里面。
線程池隔離的方案里面僅僅做到了線程池的隔離，其他的資源的隔離其實(shí)并沒有做，比如 CPU 和 Memory 之類的隔離等等，如果想要更加徹底的隔離方式，可以采用和線程池隔離類似的方式，給重要的服務(wù)用獨(dú)立的多語言網(wǎng)關(guān)來為其服務(wù)，不重要的服務(wù)，再給一個(gè)大的獨(dú)立的集群去服務(wù)。
Service Mesh
如果說要進(jìn)一步地去解決多語言網(wǎng)關(guān)資源隔離的問題，能否進(jìn)一步地將集中式的網(wǎng)關(guān)分布式化呢，假設(shè)每一個(gè)應(yīng)用的實(shí)例都能夠給它單獨(dú)地配置一個(gè)多語言網(wǎng)關(guān)的話，那么就可以徹底解決多語言網(wǎng)關(guān)的資源隔離的問題。
實(shí)際上，最近在業(yè)界非常火的 Service Mesh 就是這樣的方法，在 Service Mesh 里面，這個(gè)「分布式的多語言網(wǎng)關(guān)」叫做 Sidecar。
在 Service Mesh 的體系下，我們可以讓微服務(wù)里面的一些能力下沉到 Sidecar，不管是什么語言開發(fā)的系統(tǒng)接入到整個(gè)微服務(wù)體系中，都只需要接入這個(gè)Sidecar 就可以了，這個(gè) Sidecar 里面可以做服務(wù)發(fā)現(xiàn)，限流熔斷，服務(wù)鑒權(quán)等等的能力，對于特定語言的業(yè)務(wù)系統(tǒng)來說，只需要和另一個(gè)語言的協(xié)議能夠?qū)悠饋砭涂梢粤?，其他的一些能力都交給 Sidecar 即可。
但是，對于 Service Mesh 這樣的架構(gòu)，雖然只需要實(shí)現(xiàn)一次就可以達(dá)到支持多語言的目的，并且沒有多語言網(wǎng)關(guān)那樣的資源的瓶頸，但是相對來說，運(yùn)維成本卻高上不少，畢竟，Sidecar 是需要和業(yè)務(wù)系統(tǒng)部署在一起。在 VM 的場景下，Sidecar 和業(yè)務(wù)系統(tǒng)部署在同一個(gè) VM 下，那么對于 Sidecar 的?；睿?，回滾都是需要單獨(dú)去解決的。如果在 K8s 的體系下，那么 Sidecar 的運(yùn)維的問題就比較好解決了，K8s 的 Pod 的概念非常適合于 Sidecar 這種方式，Sidecar 和業(yè)務(wù)可以跑在不同的 Container 里面，可以做到 Sidecar 和業(yè)務(wù)之間的資源的進(jìn)一步的隔離。
在 Service Mesh 這個(gè)方向上，SOFA 也開源了自己的 ServiceMesh 的方案 SOFAMesh，歡迎大家詳細(xì)了解。
總結(jié)
在這篇文章中，一共列舉了 SOFA 在發(fā)展過程中四種多語言的支持方式：
1. 簡單的方式：直接使用 JSON over HTTP + DNS，可以解決基本的通信的問題，但是缺失了微服務(wù)下的其他的高級能力。
2. 造輪子的方式：每個(gè)語言單獨(dú)實(shí)現(xiàn)微服務(wù)的各種能力，適合需要適配的語言比較少的情況，需要投入比較大的人力，并且個(gè)別特性可能無法在多個(gè)語言中完全實(shí)現(xiàn)。
3. 多語言網(wǎng)關(guān)的方式：可以實(shí)現(xiàn)一次，把微服務(wù)里面的大部分的能力集中到多語言網(wǎng)關(guān)里實(shí)現(xiàn)，需要用額外的手段去解決資源隔離的問題，多語言系統(tǒng)依舊需要面臨如何發(fā)現(xiàn)多語言網(wǎng)關(guān)的問題。
4. Service Mesh 方式：相當(dāng)于「分布式多語言網(wǎng)關(guān)」，給每一個(gè)服務(wù)的實(shí)例都加上一個(gè) Sidecar，由 Sidecar 來提供微服務(wù)需要的能力，業(yè)務(wù)系統(tǒng)只需要專注于選擇通信以及序列化協(xié)議即可，這種模式在沒有 K8s 的支持下有比較大的運(yùn)維難度。
這些都是我們實(shí)踐過程中的一些做法和體會(huì)，希望大家可以結(jié)合自己的業(yè)務(wù)階段來參考。
補(bǔ)充
SOFA 中間件是螞蟻金服自主研發(fā)的金融級分布式中間件，包含了構(gòu)建金融級云原生架構(gòu)所需的各個(gè)組件，包括微服務(wù)研發(fā)框架，RPC 框架，服務(wù)注冊中心，分布式定時(shí)任務(wù)，限流/熔斷框架，動(dòng)態(tài)配置推送，分布式鏈路追蹤，Metrics 監(jiān)控度量，分布式高可用消息隊(duì)列，分布式事務(wù)框架，分布式數(shù)據(jù)庫代理層等組件，也是在金融場景里錘煉出來的最佳實(shí)踐。
聯(lián)系客服
