來自京東、唯品會對微服務(wù)編排、API網(wǎng)關(guān)、持續(xù)集成的實(shí)踐分享（上）

架構(gòu)師小組交流會：每期選一個時下最熱門的技術(shù)話題進(jìn)行實(shí)踐經(jīng)驗(yàn)分享。

第三期：微服務(wù)。微服務(wù)架構(gòu)以其高度的彈性、靈活性和效率的巨大提升，快速受到各領(lǐng)域架構(gòu)師和技術(shù)決策者的關(guān)注。它的基本理念是將一個肥大的系統(tǒng)拆分成若干小的服務(wù)組件，組件之間的通訊采用輕量的協(xié)議完成。我們本期小組交流會來探討一下，現(xiàn)在互聯(lián)網(wǎng)公司的微服務(wù)實(shí)踐情況。

嘉賓：京東章耿、原唯品會石廷鑫、七牛陳愛珍

本文是對此次交流的整理，分了上下兩篇文章。

第一輪：自由交流

京東章耿：大家好，我是京東基礎(chǔ)架構(gòu)部平臺中間件的章耿，主要負(fù)責(zé)京東的服務(wù)框架，配置中心等項(xiàng)目。京東11年底進(jìn)行.NET轉(zhuǎn)Java的技術(shù)變革，當(dāng)時就提出了接口的SOA化的概念。那時京東業(yè)務(wù)發(fā)展非?？?，項(xiàng)目越來越多，服務(wù)化是必然的趨勢。京東的服務(wù)化框架是一共有兩代。第一代是12年開始，我們使用開源的一個實(shí)現(xiàn)，用Dubbo作為RPC框架，Zookeeper 作為注冊中心，那時應(yīng)該算一個主流的技術(shù)選型。我們在開源的基礎(chǔ)上做了一些易用性和功能擴(kuò)展，比如說支持REST、支持kryo/thrift等序列化，服務(wù)監(jiān)控等，這個框架在那時的業(yè)務(wù)規(guī)模和節(jié)點(diǎn)數(shù)量下面還是比較穩(wěn)定的。14年初我們開始自研服務(wù)框架。為什么這么做呢？一個是之前的服務(wù)框架還是有很多可以提升的地方，不管是性能還是服務(wù)治理的一些功能，因?yàn)榫〇|的機(jī)器數(shù)，機(jī)房也在不停的建，網(wǎng)絡(luò)拓?fù)涞膹?fù)雜直接需要高級的服務(wù)治理功能；還有一個就是接口節(jié)點(diǎn)等數(shù)量級的增加，當(dāng)時我們的接口規(guī)模慢慢的已經(jīng)好幾千了，接口的實(shí)例也幾十萬；另外就是用開源的有些內(nèi)部系統(tǒng)打通比較麻煩，所以我們要做升級換代。當(dāng)時也是考量了用開源的改改，還是全部自己重新做的抉擇。后來覺得一個是有時間，二是覺得自己有能力做一個符合京東自己的定制化的服務(wù)框架，所以14年我們就開始自研框架，做了整整一年。15年初我們上線新版的服務(wù)框架。

我們新的注冊中心，是無狀態(tài)的一些節(jié)點(diǎn)，基于數(shù)據(jù)庫做最終一致性。為什么選數(shù)據(jù)庫，替換以前的Zookeeper？因?yàn)閆ookeeper是樹狀結(jié)構(gòu)，從某些維度查詢它要遍歷整棵數(shù)，用數(shù)據(jù)庫的好處就是可以從多維度的查詢分析過濾，不管是機(jī)房、 IP，都可以去查詢，分析，過濾比較結(jié)果。然后Zookeeper在跨機(jī)房的時候有一個問題，它是半數(shù)節(jié)點(diǎn)存活才可以用，所以如果跨機(jī)房部署的話，最起碼得3個機(jī)房，才能保證集群整體可用。還有Zookeeper它是強(qiáng)一致性的的，比較依賴網(wǎng)絡(luò)。如果網(wǎng)絡(luò)不好，如果跨機(jī)房斷網(wǎng)的時候，它其實(shí)是不可用的，讀都不能讀，所以會帶來一定的問題。以前用zookeeper注冊服務(wù)端，就是寫一個臨時節(jié)點(diǎn)，等服務(wù)端死了節(jié)點(diǎn)自動消失的。但是你在網(wǎng)絡(luò)一抖的時候，或者是服務(wù)端和Zookeeper之間有網(wǎng)絡(luò)故障的時候，它其實(shí)會不小心把它摘掉，因?yàn)閆ookeeper認(rèn)為它死了，但其實(shí)它不一定真的死了，所以這個時候就需要有一些輔助的去判斷它是不是真的死了。第一次遇到的情況是那個臨時節(jié)點(diǎn)，后來我們是把它改成永久節(jié)點(diǎn)，然后定時的去telnet 它的端口，像Dubbo是直執(zhí)行l(wèi)s 命令，我們也是直接執(zhí)行一個命令，看它有沒有響應(yīng)，那是第一代的時候。在JSF的框架里有一個哨兵的組件，我們的Provider會定時的發(fā)心跳，對于注冊中心來說，它知道最后的心跳時間，然后定時刷到數(shù)據(jù)庫里面，看哨兵的情況，如果沒有哨兵，數(shù)據(jù)庫里面保存一個最后心跳時間，這時候你可以用定時任務(wù)去找它，這是我們最早的一個版本。后來我們改進(jìn)了，因?yàn)橛袝r斷網(wǎng)了，這個心跳時間就不準(zhǔn)了。所以在每個機(jī)房還布了一套獨(dú)立的程序，沒心跳的同時再由它來判斷是否可用，如果這個同機(jī)房的程序都連不上，我們再把它置成一個不可用的狀態(tài)，雙重保證。另外以前Zookeeper的時候服務(wù)列表是下發(fā)的全量列表，例如1000臺加一臺，下發(fā)的是1001臺，而新版注冊中心我們是推變化的部分，只推加1臺，大大節(jié)省了數(shù)據(jù)的推送量。

RPC框架，我們內(nèi)部叫杰夫，JSF，京東服務(wù)框架的簡稱。我們是用基于Netty自己研發(fā)的。為了兼容上一代版本，兼容之前的dubbo協(xié)議，所以我們也是用的無代碼***的；我們在同一個端口支持多協(xié)議，包括自定義的JSF協(xié)議，http協(xié)議，dubbo協(xié)議等。目前我們只有C++和Java的客戶端，然后如果是其它語言例如Golang，python，PHP的話，我們都會讓他向我們的一個HTTP的網(wǎng)關(guān)發(fā)請求，這個網(wǎng)關(guān)主要就是轉(zhuǎn)發(fā)。把前面的http請求轉(zhuǎn)換到后面一個JSF請求，也是基于Netty做的。序列化默認(rèn)是Message Pack，是個跨語言的協(xié)議，也支持hessian，json，Java，Protobuf等。注冊中心和RPC框架直接是長連接，可以進(jìn)行一個通訊。

唯品會石廷鑫：大家好，我是石廷鑫，原來在京東、唯品會，現(xiàn)在在宅急送。我基本上都是在倉儲物流這方面。以前在亞洲一號是按照倉庫的整個操作細(xì)節(jié)分成各個模塊來做的服務(wù)拆分，每個模塊是單獨(dú)部署的。倉儲的每個倉，根據(jù)種品類不一樣，整個的操作流程是不一樣的。但是核心的東西，如庫存、訂單管理，都是一樣的，只是一些組合不一樣。舉個例子，小件商品上下架都要做的，但是對于大件商品，比如說大家電，基本上都不需要放架。打訂單也不需要，完成配送才需要訂單，實(shí)際上是到了最后才綁定訂單。所以每個流程不一樣，需要的組合也不一樣。那時我們就想到了，把每個模塊先拆出來，主要是用KVM運(yùn)行整個節(jié)點(diǎn)，業(yè)務(wù)部分就用這些節(jié)點(diǎn)來整個串聯(lián)起來。核心的東西比如說庫存、訂單、商品資料，基本上都是用這個簡單的模塊。

唯品會的倉儲也是按這種思路來做的。當(dāng)時唯品會用的是Dropwizard，實(shí)際上是我們用了它的一個殼，后面還是用的Spring，也做了一個模塊，把Spring集成到一塊。后來Springboot做了出來，基本上就把Dropwizard拋棄掉了。因?yàn)?/span>Dropwizard版本升級變化比較大。但它有一個好處，就是Bundle比較好，服務(wù)化拆分的時候可以根據(jù)它的大小進(jìn)行可分可合，如果不需要拆分的時候，我們就把Bundle合到一塊，如果需要拆分的話，就把Bundle再拆出來，單獨(dú)這個應(yīng)用是非常容易的。

我去年到的宅急送，我們的服務(wù)注冊、服務(wù)發(fā)現(xiàn)、網(wǎng)關(guān)都使用的Spring Cloud的這一套。目前來說還是不錯的，基本沒發(fā)現(xiàn)大的毛病。唯一的問題是如果前期沒有做好的整個數(shù)據(jù)抽取，整個報表可能會比較麻煩一些。

七牛陳愛珍：大家好，我是七牛的陳愛珍。微服務(wù)架構(gòu)的設(shè)計(jì)理念非常適合七牛的業(yè)務(wù)特點(diǎn)，每個服務(wù)只負(fù)責(zé)單一的職責(zé)。比如音視頻的處理服務(wù)：音視頻轉(zhuǎn)碼 ， 音視頻拼接 ， 視頻幀縮略圖，點(diǎn)播流式轉(zhuǎn)碼，都是以微服務(wù)的方式構(gòu)建，這樣每個服務(wù)都擁有獨(dú)立的運(yùn)行環(huán)境，并且可以根據(jù)自身的業(yè)務(wù)壓力情況進(jìn)行獨(dú)立擴(kuò)展，動態(tài)的彈性擴(kuò)展還可以提高資源的利用率。一個可落地的微服務(wù)架構(gòu)應(yīng)該為微服務(wù)提供獨(dú)立的運(yùn)行環(huán)境，調(diào)度框架，注冊中心，配置管理中心和監(jiān)控平臺。 七牛采用的是Mesos+Docker+自研調(diào)度系統(tǒng)的架構(gòu)。Docker做環(huán)境封將，Mesos做資源調(diào)度，自研的調(diào)度系統(tǒng)負(fù)責(zé)對Docker進(jìn)行彈性的調(diào)度。

我們使用Consul做注冊中心，實(shí)現(xiàn)服務(wù)的注冊與發(fā)現(xiàn)。Consul自帶key/value存儲，可通過DNS接口做服務(wù)發(fā)現(xiàn)，且具體健康檢查的功能，并支持跨數(shù)據(jù)中心的服務(wù)發(fā)現(xiàn)。API Gateway 可以通過 Consul提供的DNS接口查詢到服務(wù)所有的可用實(shí)例的列表信息，并將請求進(jìn)行轉(zhuǎn)發(fā)。流量轉(zhuǎn)發(fā)具有負(fù)載均衡的功能，采用的是輪詢的方式，服務(wù)發(fā)現(xiàn)則是基于Consul做的。用戶請求進(jìn)來后通過Consul查詢到所有可用節(jié)點(diǎn)的訪問地址，再通過輪詢的方式將請求發(fā)給后端的服務(wù)進(jìn)行處理，對于返回的結(jié)果僅作轉(zhuǎn)發(fā)，由請求方解釋和使用。并且在API網(wǎng)關(guān)中帶有監(jiān)控的組件，對請求數(shù)，失敗數(shù)等進(jìn)行監(jiān)控，傳送到Prometheus服務(wù)器上。通過監(jiān)控?cái)?shù)據(jù)對請求進(jìn)行流量控制及服務(wù)降級等相應(yīng)的處理。

當(dāng)需要調(diào)用多個微服務(wù)時，根據(jù)七牛云的數(shù)據(jù)處理的業(yè)務(wù)特點(diǎn)我們使用管道（pipeline）來進(jìn)行串行的處理。每一個微服務(wù)的輸出都是下一個微服務(wù)的輸入，直到最后一個微服務(wù)執(zhí)行結(jié)束才是最終數(shù)據(jù)處理的內(nèi)容。比如上傳一個視頻資源后，需要做兩個數(shù)據(jù)處理操作: 轉(zhuǎn)成mp4資源和進(jìn)行HLS切片，這種場景下不能對原資源同時執(zhí)行兩個數(shù)據(jù)處理的操作，必須按序執(zhí)行。 

第二輪：話題交流

主持人：服務(wù)與服務(wù)之間的依賴關(guān)系怎么管理？服務(wù)編排怎么做？把這些服務(wù)節(jié)點(diǎn)串起來。

唯品會石廷鑫：比方說不是業(yè)務(wù)的，基礎(chǔ)服務(wù)，如圖片服務(wù)器這些，都是獨(dú)立的。唯一相關(guān)的是下面的業(yè)務(wù)層和底下的基礎(chǔ)服務(wù)有之間調(diào)用，還有是業(yè)務(wù)模塊之間有服務(wù)的調(diào)用，在系統(tǒng)里是沒做體現(xiàn)的，但是我們在服務(wù)和服務(wù)之間，就加了類似于熔斷的那個默認(rèn)的東西。系統(tǒng)之間的依賴關(guān)系，我們自己做了一個簡單的系統(tǒng)進(jìn)行維護(hù)。Spring cloud eureka是都是存在內(nèi)存里，我們改良過，我都改到一個數(shù)據(jù)庫。我們交互全部都是Rest ，我們后邊還寫過一套，Google protobuf。我們倉儲的內(nèi)部的業(yè)務(wù)模塊之間是用Google protobuf來做的。我們自個做了一套虛擬化的在里邊的。

唯品會石廷鑫：我現(xiàn)在用的是Apache camel做編排，可以用DSL描述把服務(wù)串起來。其實(shí)更多的是業(yè)務(wù)的流程怎么組織，怎么去把基礎(chǔ)服務(wù)讓串起來，形成一個真正大的業(yè)務(wù)場景。

京東章耿：目前京東大部分一個接口一個方法就已經(jīng)是操作多張表了，一般認(rèn)為是一個比較原子性的操作了，如果再在外面有一個東西把它包一下，例如把3個方法包成一個方法，其實(shí)意義不大，所以我們現(xiàn)在是沒有做這方面的工作。另外京東有彈性云，用的Docker，不過不是你們想象中那種微服的那個Docker用法，京東現(xiàn)在用叫“胖容器”，更像一個虛擬機(jī)一樣的一個東西。Docker里面運(yùn)行的是一個應(yīng)用，然后這個應(yīng)用，它可能包含多個接口多個方法。可能大家理解微服務(wù)的Docker用法應(yīng)該是一個容器里面，他只跑一個獨(dú)立的邏輯，對數(shù)據(jù)的一個操作，或者對一個資源的操作。比如說下訂單、扣庫存，這兩步操作，他可能跑了兩個容器。把它編排成一個service的這種，我們好像沒有這種。

主持人：服務(wù)拆分是怎么做的？

京東章耿：京東現(xiàn)在的服務(wù)其實(shí)也是沒拆太細(xì)，主要還是業(yè)務(wù)部門自己控制服務(wù)粒度。京東的業(yè)務(wù)還是比較復(fù)雜的，各個應(yīng)用之間互相依賴，互相調(diào)用，每個操作基本都會涉及到很多資源的變更，像微服務(wù)推崇的那種對單一資源的操作，基本上沒有。說實(shí)話，這種大型互聯(lián)網(wǎng)公司里面的服務(wù)根本就微不起來的，不可能像RESTful一樣，對一個資源的一個put post 操作基本不可能，我們現(xiàn)在都是力度還是由使用我們框架的研發(fā)人員自己定的，然后一般他們都是根據(jù)這種方法之間的一些關(guān)聯(lián)性或者原子性，或者是擴(kuò)展性來進(jìn)行組合或者拆分。所以我們一般叫自己服務(wù)化框架，不叫微服務(wù)框架。另外他們可能還會考慮一些服務(wù)是否可以獨(dú)立部署，拆的時候可能會考慮一下這些。

主持人：其實(shí)很多大型電商互聯(lián)網(wǎng)也拆不開，也不能稱之微服務(wù)，是那種服務(wù)力度很粗，然后每個服務(wù)號有若干個接口，其實(shí)耦合性很高的合在一起，相關(guān)度很高，數(shù)據(jù)都在一起。

京東章耿：都差不多，都是業(yè)務(wù)開發(fā)自己來折分服務(wù)粒度的。就像剛才說的下單。肯定是一次要操作好多表的。業(yè)務(wù)開發(fā)認(rèn)為這是幾次表操作其實(shí)是一個下單的原子操作，那么他就拆到這么細(xì)了。

唯品會石廷鑫：我們服務(wù)不是說一個部一個，實(shí)際上它是和數(shù)據(jù)域相關(guān)的，都擱到一塊。

唯品會石廷鑫：按功能分的，功能跟功能之間調(diào)用，如果不是同一個數(shù)據(jù)域里邊的，還是用RPC來調(diào)用的。

京東章耿：那個聽起來很美好，你想我們現(xiàn)在這樣拆，都已經(jīng)上萬了接口，方法基本都上十萬了。你這樣拆的話，起碼乘以10的接口，而且這樣搞的話就得整個公司都要動用非常非常大的能力去搞好這個事情。

主持人：單體他如果拆成像市場上去提倡的那種微服務(wù)，其實(shí)他對內(nèi)部的消耗是非常大的，因?yàn)槲覀兒芏嗟姆?wù)內(nèi)部的調(diào)用，其實(shí)是非常頻繁，如果都把它拆開了去獨(dú)立部署的話，它其實(shí)對網(wǎng)絡(luò)的消耗是要求非常高的。

唯品會石廷鑫：就是最難的點(diǎn)，一開始你是拆不開這個數(shù)據(jù)。

主持人：數(shù)據(jù)只要能拆開，你什么都好干。你只要能把數(shù)據(jù)粒度拆的很細(xì)的話，那就沒問題了，那也能做的很細(xì)，但就是拆不開。其實(shí)好多數(shù)據(jù)都是陳年老表，都是很都是從原來系統(tǒng)繼承下來的，就很難拆。

唯品會石廷鑫：所以新做一個系統(tǒng)還可以。要做這個老系統(tǒng)計(jì)劃很難的，拆個表就要拆很多天。

京東章耿：而且是數(shù)據(jù)量比較少，然后邏輯比較簡單的，例如那種創(chuàng)業(yè)型公司，使用開源的方案，這種可以很方便。

主持人：在雙11時各個電商肯定會有大型的促銷，這時服務(wù)的壓力肯定會有很大的增長，怎么解決服務(wù)的伸縮的問題？

唯品會石廷鑫：就像我們這邊的話，就看哪個基點(diǎn)的壓力比較大一些，然后你多布幾個基點(diǎn)就可以了?，F(xiàn)在基本上都是中泰的那個，就是Spring cloud那套。擴(kuò)展都是提前先做一步。自動擴(kuò)的話，就是相當(dāng)于我們租了一個類似于簡單的監(jiān)控。就是根據(jù)他的實(shí)例，然后因?yàn)槲⒎?wù)，我們現(xiàn)在是Spring cloud ，基本上都是java -jar，然后自己啟就得了，反正那個jar，你可以放到一個公用的地，遠(yuǎn)程java -jar要干架就起來了，監(jiān)控的時候根據(jù)他的量，然后隨時可以啟就行了。

京東章耿：京東的服務(wù)發(fā)布都是掛在應(yīng)用下面的，而應(yīng)用發(fā)布的平臺其實(shí)會和各個系統(tǒng)打通，比如說數(shù)據(jù)庫授權(quán)的系統(tǒng)，然后自動掛VIP的一些系統(tǒng)，掛監(jiān)控平臺，日志系統(tǒng)等。然后我們還有個監(jiān)控平臺，監(jiān)控一些指標(biāo)，例如機(jī)器情況，應(yīng)用情況，還有自己業(yè)務(wù)埋點(diǎn)的性能等數(shù)據(jù)。至于服務(wù)是否有壓力，都是自己評估，自己提前擴(kuò)展。 一般大促前會進(jìn)行大規(guī)模的壓測，他們自己壓測，然后根據(jù)結(jié)果自己擴(kuò)就可以了。京東是沒有開自動彈性擴(kuò)展的，基本都是大促前提前申請容器，然后提前擴(kuò)完。

唯品會石廷鑫：并發(fā)量大的業(yè)務(wù)都是放在公有云，雙十一比平常多了兩倍的機(jī)器，我們只買 了一個月的云主機(jī)。臨時用幾天，結(jié)束就不用了。