有贊雲如何支持多語言

1、背景

有贊是Saas公司，向商家提供了全方位的軟件服務，支撐商家進行採購、店鋪、商品、營銷、訂單、物流等等管理服務。

在這個軟件服務裏，可以知足大部分的商家，爲商家保駕護航。

Saas造成是追求共性的過程，Saas生態化是求同存異的過程，因此當咱們可以知足大部分客戶需求時，咱們得考慮大客戶的個性化需求場景。

1.1 客戶分析

上面講到咱們要求同存異，咱們要知足個性化需求，這裏簡單講解一下大客戶的價值，下面就不區分優點和劣勢了，都放一塊兒：

• 中小客戶
  • 企業規模小，付費能力相對弱一些；
  • 企業週期短，沒法很好的保證續費；
  • 大部分停留使用產品基本能力，說明軟件可替代性強，難造成粘性；
  • 可是數量龐大；
  • 獲客成本相對低一些；
• 大客戶
  • 企業規模大，付費能力強；
  • 發展穩定，企業週期長，可以保證續費；
  • 有利於造成標杆案例，用於推廣；
  • 只要能實現需求，對資金要求和價格不敏感；
  • 定製需求多，一旦定製，替代成本高，粘性好；

簡單羅列了一下，固然其餘點還有不少，對比會發現，Saas會知足大部分客戶的需求，尤爲是中小客戶，並且中小客戶量可能會達到90%以上，可是中小客戶續費能力弱會致使銷售成本高，同時沒法造成標杆，很難有行業影響力；大客戶付費能力很強，只要可以知足需求，可能不太會對相對高的價格說不，可是基本上每一個大客戶都有定製需求，並且一旦達成合做，能夠穩定的續費。

1.2 有贊雲是幹嗎的

前面簡單的分析了一下中小客戶和大客戶，因爲本篇的重點在於多語言，因此就不過多的講解，實際上一些中小客戶也有定製需求，但願本身的店鋪標新立異，但願可以用低成本而且快速知足本身的需求，當成長爲大客戶時再有更多的需求。

Saas傳統狀況下是怎麼作定製的呢？

//核心業務流程
	............
    ...........
  if (店鋪Id.equeals(0023423)) {
      //do custom logic
  } else if (店鋪Id.equeals(0056673)) {
      //do custom logic
  } else {
      //do stardand logic
  }
	............
    ...........
複製代碼

做爲一個技術人員，可能會對上述代碼很熟悉，客戶是上帝，當客戶提各類各樣的需求時，若是不知足可能會致使客戶遠走他鄉，若是去知足，那麼咱們的核心業務代碼耦合性會很高，並且代碼擴展性不好，定製代碼愈來愈多，愈來愈約束業務的發展，致使系統出現瓶頸；固然上面的代碼有點直白，通常狀況下會運用規則引擎、會獨立一個定製應用來處理噁心的業務，可是問題依舊；更難受的一點是客戶要定製頁面，難道在node層作業務判斷嗎？看到這裏相信你們都會說不，這個系統將無法擴展，業務沒辦法大步向前走。

這個時候有贊雲出現了，因此有贊雲的初衷是解決客戶的個性定製需求，讓各類各樣的客戶都可以和有贊合做，有贊提供的軟件能夠應用於各行各業，覆蓋全部場景。

圖相對抽象，可是更好理解。從圖中的箭頭能夠看出，有贊雲就是核心業務的擴展，咱們的核心業務系統將交易流程輸出到有贊雲，開發者或者商家能夠本身定製交易流程，如賣電影票的商家能夠在下單流程中加一個選座的流程；同時在流程中的各個業務關鍵點輸出擴展能力，讓開發者能夠去實現這個擴展能力，如價格計算，原來價格計算是核心系統作的事情，如今開發者能夠本身寫價格計算邏輯，這個價格計算的結果可能就是商品的實際成交價格；前端頁面組件化，開發者能夠定製本身的組件，修改原有組件的行爲。固然還有不少不少更加複雜的定製。

因此有贊雲是一個平臺，提供了定製能力，而且把定製能力市場化，開發者開發各類各樣的工具型App，實現了各類奇思妙想的功能，而後發佈到有贊雲的應用市場；商家瀏覽應用市場，發現某個或者幾個應用的功能和本身的需求很匹配，而後購買應用，快速又低成本的完成了本身的店鋪的定製。除此以外，咱們還提供行業解決方案定製，若是你足夠有能力，你能夠定製整個行業的方案，好比有贊除了微信商城還有有贊教育，你能夠定製一套有贊教育，這是難以想象的；大客戶每每但願可以私有定製，由於大客戶的定製每每很特殊，不能推廣，因此大客戶找開發者能夠開發自用型App，最大程度的完成本身的需求。

1.2.1 工具型應用

這裏有兩個角色兩種資源，開發者和商家，店鋪和應用。

開發者開發完App上架應用市場，商家購買應用，購買後會產生商家店鋪和應用的受權關係，此時店鋪可使用應用的功能，好比某應用實現了國際地址，那麼該店鋪的買家在下單過程當中選擇地址時能夠選擇全球地址了。

1.2.2 自用型應用

自用型顧名思義是本身使用的，此時商家能夠本身找開發者爲本身開發一個應用來實現本身店鋪的定製，該應用的全部權也屬於商家。

1.2.3 行業解決方案

這是一整套方案，前面提到，你能夠開發一個行業的軟件，好比打車、外賣等等，和工具型應用同樣須要上架應用市場，而後商家購買。

1.2.4 有贊雲的影響

將會全面助力商家成功，大大提高商家成功發展，給商家更多可能性；

給開發者提供平臺，拓展開發者的收入，提高開發能力，拓展影響力。

2、什麼是多語言

2.1 應用

什麼是多語言，多語言應用在什麼地方，離不開一個載體，那就是應用。

應用是開發者開發定製功能的實體，它包含代碼、控制檯、組件（mysql、redis等等）、權限、業務配置等等。

同時這個應用是部署在有贊雲提供的容器裏。

那麼爲何要部署在有贊雲提供的容器裏：

1. 若是部署在私有機房和外部的雲，很難保證公網的穩定和延時；
2. 咱們須要保證應用的質量，防止違規違法現象出現；
3. 部署在有贊雲的容器裏，和有贊核心應用更近，能夠經過RPC的方式進行調用；
4. 這種方式能夠監控整個鏈路，出問題容易排查；
5. 可靠性、穩定性、安全性有保障，這是對商家的保障。

2.2 多語言

咱們但願經過這種模式造成一種生態，支持各類語言進行開發的開發者，因此咱們也上線了開發者社區，方便開發者學習、交流、更好地與有贊雲溝通、與商家溝通。

多語言，此語言非彼語言，不是國家化支持多個國家語言的意思哈。

多語言是指咱們提供一些規範、協議、框架、基礎設施等等來支持開發者進行如Java、Php、Python、NodeJs等等語言的應用開發，而且咱們的調用。

如上圖所示，多語言包含不少模塊，會着重挑幾塊講一下，事實上每一塊內容均可以寫好幾篇文章。

3、如何實現多語言

如何實現多語言，這是一個好問題，也是一個難題，至少作有贊雲是如此，這是一個全新的模式，雖然多語言調用有多種解決方案，可是對於有贊雲這種模式來講沒有前路可參考。

一開始可能還不知道如何上手，思惟導圖是個很好的工具，可以幫助梳理多語言該作哪些事情，如上圖所示，固然下面細分的內容還有不少。

3.1 遠程調用

咱們先來看遠程調用，畢竟這個是主鏈路，沒有這個能力，咱們的擴展能力就沒法實現。

相信大部分Java開發同窗都在用dubbo或者spring cloud體系，可是這些目前基本可以解決Java應用之間的RPC調用，做爲一個公司來講，咱們能夠去限定你們統一用某些技術棧，統一模型。可是有贊雲的用戶是開發者，在有贊雲裏部署的應用是各個語言開發的。

3.1.1 技術選型

首先咱們須要保證遠程調用時低延時的，支持多種開發語言，開發者不用感知服務的註冊、發現；須要用監控和鏈路追蹤能力；有贊雲鬚要在開發者不感知或者不影響開發者實際開發體驗的狀況下去添加功能、完善鏈路並持續升級。

Service Mesh的理念很是符合咱們的場景，接下來看看咱們的多語言實踐。

3.1.2 內部RPC

相信大部分公司的RPC框架使用了Dubbo，在Dubbo的基礎上進行二次開發來知足本身公司的場景，有贊也是如此。

這張圖相信你們都很熟悉，有consumer、provider、registry、monitor，可是這裏有幾個問題：

1. Consumer和Provider須要Java應用；
2. Consumer和Provider的行爲耦合在業務應用裏；
3. 架構上對跨機房、跨網絡的調用沒作支持。

有贊公司內部對Dubbo進行了二次開發來支持前面提到的幾個問題，對於Java應用來講，基本上和圖中的架構相似。因此能夠理解爲有贊本來Java應用之間經過Dubbo來作RPC（這是現狀），而後如今要實現跨網絡而且調用多種語言的應用（目標）。

固然有贊內部自己就演進過對特定語言的調用方案。

3.1.3 部署架構

如圖，有贊內部核心域和有贊開發者定製域屬於兩個獨立的網絡，兩個網絡之間不能進行相互訪問。

上圖中的Side Car是徹底由有贊自主研發的組件，取名叫Tether，他完成了服務的請求轉發，與有贊監控、日誌對接，實現了對服務化調用的監控和報警，並將服務發現、負載均衡、後端服務的優雅下線等等，所有都下沉到Tether層處理，因此能夠理解爲Tether就是Service Mesh中的Side Car。

3.1.3 Mesh實踐

從上圖中會發現，咱們在覈心域調用App的過程當中沒有采用Dubbo直連的方式進行RPC行爲，而是經過了Side car進行轉發。

Service Mesh架構圖，若是將前面的部署架構圖兩邊的網絡域換成兩個服務器，會發現和Service Mesh圖相似。

Service Mesh的理念是將服務的註冊、發現、服務治理、服務調用等等能力做爲基礎設施，讓應用不用去感知業務邏輯以外的內容，這也是雲原生的一部分。

由於若是讓應用去作這些事情，不少事情變得不可控，好比服務協議版本不一致、出現Bug時不能統一升級。而如今有贊雲的這種微服務化的架構，僅需靜默升級Sidecar便可，無需任何業務開發者的參與和協同，極大的提高了總體架構的靈活性和功能迭代可控性。

前面提到，目前有贊核心域使用的Dubbo RPC協議與Java語言特性耦合嚴重，不適合於跨語言調用的場景。基於此，有贊雲定製域中，咱們設計了基於HTTP1.1和HTTP/2協議的可拓展的RPC協議，用於跨語言調用的場景。其中HTTP/2協議因爲其標準化、異步性、高性能、語義清晰等特性。

3.1.4 調用流程

講了這麼多，給你們一個比較清晰的調用流程圖來理解一下。

舉個例子，好比開發者實現了一個價格計算擴展點，當咱們的核心業務邏輯進行到計算價格時：

1. 價格中心經過Dubbo調用Bep（擴展點網關），這樣作的好處時內部應用自己使用Dubbo框架，無須改造，就按正常Dubbo服務處理就行；
2. Bep直連Side car，當Bep收到請求後進行協議轉換，而後調用Side Car；
   • 若是對方應用是Java應用，那麼仍是按照原有的Dubbo協議進行調用，前文提到過，有贊內部已經作了一些Dubbo支持開發，這套方案早就存在，因此這是最低成本，對於Java開發者來講也是很是熟悉Dubbo，這種方式對於有贊和開發者來講比較合適。
   • 若是對方應用不是Java應用，Bep會將Dubbo協議轉換爲Http協議調用Side Car。
3. Side Car經過網絡規則調用到有贊雲開發者定製域機房的Side Car，這裏有個問題，有贊雲定製域機房的Side Car如何知道該調用那個App呢？
   • 首先定製域裏是一個K8S的集羣，當App發佈的時候，經過K8S提供的能力進行服務註冊；
   • 有贊雲引入了Istio的Pilot，並進行了必定的改造來進行容器中應用的服務發現；
   • 還有一點就是前文提到，App和店鋪之間有受權關係才能調用，因此當核心域發起Dubbo請求時系統知道是哪一個店鋪的操做，知道了店鋪就知道是哪一個App。

因此咱們提供的多語言方案並非一刀切，而是因地制宜，根據實際狀況去作RPC的多語言方案，針對Java應用，咱們使用有贊已有的技術能力放到有贊雲中來實施；對於其餘類型的應用，咱們提供通用的Http1.1/2.0來拓展RPC協議，其中HTTP/2協議因爲其標準化、異步性、高性能、語義清晰等特性可以知足咱們的場景。

3.1.5 RPC監控

傳統Dubbo監控通常會在應用依賴的Jar包裏去作數據上報，也就是應用來上報監控數據，在作多語言時這樣會有一些問題：

1. 每種語言框架都得去作上報，當上報協議發生變化時就得去更新各個框架，而且推進應用去升級；
2. 應用自己作數據上報，若是這個邏輯出現問題，可能致使業務出錯，應用異常；
3. 框架層會佔用太多應用資源；
4. 多種語言得適配；
5. 監控會隨着業務的發展，底層系統的升級，常常性的變動。

針對這幾個問題，咱們將Tracing、Metrics、Logging能力下層到Side Car，屏蔽多語言，經過這種方式，咱們可讓開發者無感知的去升級底層能力，升級監控；應用層只須要關注服務實現；當一種新的語言加入時，咱們的監控收集不須要作任何改造。

3.2 應用框架

講了遠程調用，那麼應用如何去實現服務呢？咱們但願給開發者提供極致的開發體驗，而不是讓開發者去感知太多協議層的內容，若是無論這些咱們徹底能夠在有贊雲文檔中說明咱們的協議細節，而後讓開發者去理解協議去實現協議，可是這樣體驗太差了，可能開發了好幾天還在調試協議，而沒有進入可以真正產生價值的業務代碼，這是徹底不必浪費的時間。

這就須要有個應用框架來屏蔽這個麻煩。

3.2.1 擴展點調用

無論是Java語言仍是Php或者其餘語言，有贊雲都會提供應用框架，可是在設計之初這是一個艱難的抉擇，提供應用框架意味着咱們的成本會很高，開發成本和維護成本，可是咱們開發的協議咱們本身最清楚，出現問題有贊雲的開發同窗也最瞭解，從長期來看對於有贊雲和開發者來講都是很是有益了，尤爲是對於開發者，大大下降了開發者的開發成本以及和有贊雲技術支持的溝通成本。

從上圖能夠看到，當Side Car調用應用時，框架層會解析協議，將協議還原，經過必要的一些校驗，轉換爲當前語言可讀的對象或者實體，經過規則路由調用到具體的擴展點實現。

一目瞭然，開發者就關注擴展點實現就行，在擴展點實現上，針對各個語言設計了各個語言的方式來進行聲明和實現，好比Java須要採用註解、Php採用Facade等等。

3.2.2 日誌

對於全部語言來講，日誌是開發和運行過程當中最須要的組件，日誌是一個相對穩定的組件，通過這麼多年的發展，已經很明確的可以定義日誌內容包含哪些信息，同時日誌也是應用主動調用去打印的過程，因此咱們將日誌上報能力封裝在了框架裏，由於他離業務更近。

天網，有贊雲應用的日誌平臺，全部開發者的應用日誌都會打印上傳到天網進行計算和存儲；

因此針對日誌，天網提供了統一的日誌協議和端口，應用只須要按照規範封裝日誌格式，就能夠將日誌打印到天網，應用的日誌並非存在在服務器本地文件上；

3.2.2.1 Java應用

import org.slf4j.Logger;
  import org.slf4j.LoggerFactory;
  
  ...........................
    ..............................
        private static final Logger logger = LoggerFactory.getLogger(Xxxxx.class);
  ............................
    ...............................
    		logger.info("test log");
複製代碼

在應用框架層，已經封裝好了日誌協議和上報天網的邏輯，開發者只須要像日常使用Slf4j同樣打印日誌就行。

那麼在實現上咱們使用了Slf4j的規範，經過SPI實現了天網的日誌管道。

3.2.2.2 Php應用

Php框架使用Monolog，在Monolog裏增長了日誌處理器SkynetProcessor來封裝日誌協議，經過SocketHandler來打印日誌到Rsyslog上。

3.3 其餘

回到一開始多語言的思惟導圖，要支持多語言，其實要作不少事情。

咱們在作這些事情的原則就是儘可能讓開發者少感知，保證總體系統的健壯性和擴展能力。

在作這些事情時最麻煩的可能就是升級，當咱們發佈一個新功能或者升級了協議後，推進全部應用去升級是一個漫長的週期，此時咱們的底層可能得作無數的兼容邏輯，這樣會致使系統沒法往前發展，同時開發者也會很反感，頻繁的去手動指定版本並去發佈（此時沒有修改一行業務代碼、並且可能還得改造代碼）。

關注其餘的一些模塊，本期暫時就先略過了。

4、規劃與展望

規劃的目標是但願提高開發者的體驗，助力商家成功。

因此會開放更多擴展能力，真正作到全流程每一個細節點均可以定製。

在開發體驗上，須要實現WebIDE，方便開發調試，甚至讓開發者不用感知項目，Faas也多是一條很好的路。

在多語言上，儘可能得作到統一底層，而不是新增一種語言給咱們帶來浩大的工做量。

同時樂見各路開發者的奇思妙想，開發出各類很是有意思、有價值的應用。基於此，有贊雲在6月5日上線了有贊雲開發者大賽，面向全國發出"英雄帖"，一個優質應用可獎勵40萬，歡迎你們報名參加。www.youzanyun.com/contest