▼

首先，介紹下當(dāng)當(dāng)?shù)臉I(yè)務(wù)特征，這也是互聯(lián)網(wǎng)行業(yè)的共有特征：

海量用戶 當(dāng)當(dāng)面向的是完全開(kāi)放的、整個(gè)互聯(lián)網(wǎng)的億級(jí)用戶量。

品類繁多 當(dāng)當(dāng)是賣(mài)書(shū)起家的，書(shū)的品類是很多的。除了書(shū)，當(dāng)當(dāng)還有百貨、服裝等。與垂直電商不同，水平電商由于品類繁多，因此數(shù)據(jù)架構(gòu)也會(huì)有很大區(qū)別。

7X24 互聯(lián)網(wǎng)公司基本都是如此要求，盡量縮短宕機(jī)時(shí)間。

流量突增 如“雙11”或“書(shū)香節(jié)”，其流量是平時(shí)的幾倍到幾十倍不等。

業(yè)務(wù)復(fù)雜 下圖是業(yè)務(wù)框架圖，分為三部分，中間部分是當(dāng)當(dāng)主業(yè)務(wù)流程，從用戶查看選擇商品的賣(mài)場(chǎng)模塊，到購(gòu)物車(chē)、結(jié)算的交易模塊，最后發(fā)至訂單工作流系統(tǒng)；然后通過(guò)倉(cāng)儲(chǔ)系統(tǒng)生產(chǎn)訂單，并交由物流系統(tǒng)配送貨品。上面部分是用戶相關(guān)的系統(tǒng)，如搜索、推薦、促銷(xiāo)、會(huì)員等。下面部分是為當(dāng)當(dāng)運(yùn)營(yíng)人員與合作伙伴提供的系統(tǒng)，如商品、價(jià)格、庫(kù)存等。

這僅是縮略版的系統(tǒng)架構(gòu)圖，當(dāng)當(dāng)實(shí)際系統(tǒng)要復(fù)雜的多、用到的語(yǔ)言也各異，大部分如：前端PHP、后端Java、搜索系統(tǒng)用C++，推薦系統(tǒng)用Go和Python。因此它是一個(gè)由異構(gòu)語(yǔ)言組成的復(fù)雜系統(tǒng)集合。

▼

互聯(lián)網(wǎng)核心問(wèn)題和企業(yè)級(jí)開(kāi)發(fā)不一樣的地方在于規(guī)模。互聯(lián)網(wǎng)公司的規(guī)模由以下幾點(diǎn)組成的——

海量數(shù)據(jù)：包括但不限于用戶數(shù)據(jù)、商品數(shù)據(jù)、交易數(shù)據(jù)、訂單數(shù)據(jù)、用戶行為數(shù)據(jù)等。由于數(shù)據(jù)量巨大，因此不能僅使用單一的數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)，也不能以單數(shù)據(jù)節(jié)點(diǎn)的方式存儲(chǔ)所有數(shù)據(jù)。

響應(yīng)遲緩：大量的用戶訪問(wèn)，使得系統(tǒng)承載了更多流量，處理過(guò)多的請(qǐng)求會(huì)導(dǎo)致系統(tǒng)響應(yīng)變的遲緩。

系統(tǒng)繁多：通過(guò)上一張圖可以得知，系統(tǒng)是由非常多的子系統(tǒng)組成的，每個(gè)子系統(tǒng)各司其職。合理的系統(tǒng)拆分可以靈活的分離冷熱數(shù)據(jù)、擴(kuò)容重點(diǎn)系統(tǒng)等。

開(kāi)發(fā)困難：各個(gè)系統(tǒng)都是由異構(gòu)語(yǔ)言的不同技術(shù)棧構(gòu)成，開(kāi)發(fā)成本較高。

穩(wěn)定性差：由于系統(tǒng)間交互增多，系統(tǒng)之間會(huì)形成一個(gè)復(fù)雜的交互網(wǎng)。任一系統(tǒng)出現(xiàn)問(wèn)題，都可能導(dǎo)致部分不可用，進(jìn)而增加整體不可控的風(fēng)險(xiǎn)。系統(tǒng)拆分的越多，出問(wèn)題的可能性就越大，系統(tǒng)穩(wěn)定性就會(huì)越差。

伸縮性差：電商公司不可能常備“雙11”的機(jī)器體量。因此遇到大促等需要承載突發(fā)流量的場(chǎng)景，系統(tǒng)需要可以彈性伸縮。在流量增加的時(shí)候擴(kuò)張容量，用于承接更多的購(gòu)買(mǎi)需求；在流量下降的時(shí)候收縮容量，節(jié)省成本。

▼

解決方案是中間件+云平臺(tái)。

中間件解決的主要問(wèn)題是服務(wù)化、彈性化和異步化。

服務(wù)化：眾多系統(tǒng)間應(yīng)該提供一致的交互和治理方式。

彈性化：讓系統(tǒng)具備根據(jù)實(shí)際需要靈活的擴(kuò)縮容的能力。

異步化：將同步調(diào)用鏈?zhǔn)崂頌橥铰浔P(pán) + 異步處理的方式以提升吞吐量。

云平臺(tái)解決的主要問(wèn)題是部署自動(dòng)化和監(jiān)控一體化。

中間件缺乏對(duì)運(yùn)行環(huán)境搭建，App部署分發(fā)等能力，也難以提供統(tǒng)一的監(jiān)控一體化系統(tǒng)，因此云平臺(tái)在這方面是對(duì)中間件的有益補(bǔ)充。

▼

這里介紹最主要的三個(gè)中間件：服務(wù)中間件、作業(yè)中間件和數(shù)據(jù)中間件。中間件遠(yuǎn)遠(yuǎn)不止這三種，限于時(shí)間，無(wú)法涵蓋全部的中間件：如消息中間件、緩存中間件、NoSQL以及離線大數(shù)據(jù)等因時(shí)間關(guān)系不在分享范圍之內(nèi)。

▼

服務(wù)中間件有很多優(yōu)秀的開(kāi)源產(chǎn)品，從早期的Finagle, Dubbo，到近期出現(xiàn)的Motan，Spring Cloud都是個(gè)中翹楚。服務(wù)中間件的核心功能主要包括：

遠(yuǎn)程調(diào)用：分為長(zhǎng)連接調(diào)用和短連接調(diào)用兩種方式。長(zhǎng)鏈接采用Socket + 二進(jìn)制序列化的方式居多，短連接以HTTP RESTFul + JSON的方式為主。無(wú)論采用何種調(diào)用方式，都應(yīng)在服務(wù)中間件中封裝為統(tǒng)一接口。

服務(wù)發(fā)現(xiàn)：自動(dòng)感知上線和下線的應(yīng)用，并分配和截?cái)嘞鄳?yīng)的請(qǐng)求。標(biāo)準(zhǔn)實(shí)現(xiàn)方案是通過(guò)一個(gè)注冊(cè)中心管理和協(xié)調(diào)分布式應(yīng)用，常見(jiàn)的注冊(cè)中心有Zookeeper，etcd和Eureka。

負(fù)載均衡：合理的將流量分配給權(quán)重不盡相同的分布式節(jié)點(diǎn)。

服務(wù)治理：包括服務(wù)調(diào)動(dòng)鏈?zhǔn)崂怼⒎?wù)降級(jí)、服務(wù)版本控制等功能。

限流：將過(guò)載的流量擋在后端系統(tǒng)之外，讓部分不過(guò)載的請(qǐng)求可以繼續(xù)提供服務(wù)。保證系統(tǒng)不會(huì)因?yàn)橥辉龅牧髁慷煌耆珱_垮，而是任何情況下都能提供對(duì)核心用戶的平穩(wěn)服務(wù)能力。

監(jiān)控報(bào)警：提供將內(nèi)部指標(biāo)通過(guò)API對(duì)接到外部系統(tǒng)的能力，內(nèi)部指標(biāo)一般有SLA、服務(wù)狀態(tài)、節(jié)點(diǎn)承載量等。

上圖是當(dāng)當(dāng)采用的服務(wù)框架——DubboX。

該項(xiàng)目Fork了阿里開(kāi)源的Dubbo，并內(nèi)置了Web服務(wù)器且增加REST協(xié)議，用于支持異構(gòu)語(yǔ)言間的調(diào)用。每個(gè)基于DubboX的應(yīng)用均可通過(guò)內(nèi)置的Web服務(wù)器提供服務(wù)，每個(gè)Web服務(wù)器通過(guò)Nginx實(shí)現(xiàn)負(fù)載均衡。并且在Nginx通過(guò)OpenResty實(shí)現(xiàn)了基于漏桶和令牌桶兩種算法的限流插件。請(qǐng)求調(diào)用信息通過(guò)Agent的本地匯總之后，定期發(fā)送至一個(gè)Kafka的消息隊(duì)列，并通過(guò)Storm的二次匯總計(jì)算出SLA，存儲(chǔ)至數(shù)據(jù)庫(kù)中。最終由監(jiān)控系統(tǒng)定期抓取報(bào)警數(shù)據(jù)。

使用DubboX部署的程序，在邏輯上分為兩部分。上面部分是服務(wù)的提供者；下面部分是服務(wù)的消費(fèi)者。服務(wù)消費(fèi)者在REST協(xié)議的場(chǎng)景，是直接通過(guò)Nginx代理訪問(wèn)服務(wù)提供者的。如果采用Java同構(gòu)應(yīng)用，可以使用Dubbo原生的長(zhǎng)鏈接+Dubbo協(xié)議，并通過(guò)注冊(cè)中心服務(wù)發(fā)現(xiàn)，以及客戶端負(fù)載均衡。

下圖是當(dāng)當(dāng)?shù)腟LA監(jiān)控系統(tǒng)以及限流系統(tǒng)的Dashboard。

▼

當(dāng)當(dāng)系統(tǒng)中很多業(yè)務(wù)是由作業(yè)實(shí)現(xiàn)的，如拉單作業(yè)、價(jià)格同步作業(yè)等。因?yàn)楣鞠到y(tǒng)較多，很難通過(guò)唯一的方案實(shí)現(xiàn)，因此也有部分系統(tǒng)通過(guò)消息中間件完成。作業(yè)中間件的核心功能主要包括：

定時(shí)調(diào)度：根據(jù)cron表達(dá)式的時(shí)間調(diào)度應(yīng)用。

任務(wù)分片：將一個(gè)大任務(wù)拆分成為多個(gè)任務(wù)片段，分布運(yùn)行。此功能后文會(huì)重點(diǎn)介紹。

彈性擴(kuò)容：與任務(wù)分片息息相關(guān)，一并在后文中介紹。

作業(yè)治理：管控作業(yè)生命周期，如：執(zhí)行、禁用、啟用以及更復(fù)雜的行為，如：失效轉(zhuǎn)移、錯(cuò)過(guò)任務(wù)重觸發(fā)等。

監(jiān)控報(bào)警：提供將作業(yè)運(yùn)行狀態(tài)、歷史統(tǒng)計(jì)和查詢對(duì)接至外部系統(tǒng)的能力。

當(dāng)當(dāng)采用的作業(yè)中間件是自研的Elastic-Job，它可以將一個(gè)完整的作業(yè)拆分為多個(gè)相互獨(dú)立的任務(wù)。一個(gè)完整的作業(yè)運(yùn)行時(shí)間可能較長(zhǎng)，但很難通過(guò)增加機(jī)器實(shí)例提升運(yùn)行效率。通過(guò)Elastic-Job將作業(yè)拆分為多個(gè)任務(wù)，可以并行的在分布式的環(huán)境中運(yùn)行，提升其處理速度。用戶可以實(shí)現(xiàn)自己的分片策略，將任務(wù)分配至合適的節(jié)點(diǎn)運(yùn)行。

通過(guò)上圖舉例，作業(yè)分為4片，由兩臺(tái)服務(wù)器執(zhí)行，每臺(tái)執(zhí)行兩片。當(dāng)增加一臺(tái)服務(wù)器時(shí)，如下圖所示，分片項(xiàng)被稀釋為服務(wù)器1和3各執(zhí)行一片，服務(wù)器2執(zhí)行兩片，那么服務(wù)器1和3由于執(zhí)行的分片項(xiàng)減少，從而提升性能。

而一旦有服務(wù)器宕機(jī)，如下圖所示，僅剩余一臺(tái)服務(wù)器可以提供服務(wù)，那么所有的分片都將指向該服務(wù)器。集群的整體處理能力會(huì)下降，但作業(yè)的完整性不會(huì)受到影響，從而提供高可用的能力。

因此，隨著運(yùn)行實(shí)例的增加和減少，Elastic-Job可以動(dòng)態(tài)的調(diào)整分片來(lái)提升性能和保證可用性。

這是Elastic-Job的部署架構(gòu)圖。

▼

接下來(lái)介紹的是數(shù)據(jù)庫(kù)中間件。關(guān)系型數(shù)據(jù)庫(kù)在大數(shù)據(jù)量的情況下，單庫(kù)單表難以支撐。解決方案是將單一的數(shù)據(jù)庫(kù)拆分為分布式數(shù)據(jù)庫(kù)，而讓開(kāi)發(fā)和運(yùn)維人員像訪問(wèn)一個(gè)數(shù)據(jù)庫(kù)一樣訪問(wèn)分布式數(shù)據(jù)庫(kù)，屏蔽其復(fù)雜度，是數(shù)據(jù)庫(kù)中間件的基本功能。數(shù)據(jù)庫(kù)中間件的核心功能主要包括：

分庫(kù)分表：通過(guò)打散數(shù)據(jù)的方式有效的減少每個(gè)表的數(shù)據(jù)量，減少索引的深度以提升查詢性能。并且拆分?jǐn)?shù)據(jù)庫(kù)來(lái)有效的疏導(dǎo)請(qǐng)求流量。

讀寫(xiě)分離：進(jìn)一步提升數(shù)據(jù)庫(kù)的性能可以采用讀寫(xiě)分離。讀庫(kù)僅負(fù)責(zé)響應(yīng)查詢，寫(xiě)庫(kù)相應(yīng)更新，通過(guò)異步數(shù)據(jù)同步的方式保持讀寫(xiě)庫(kù)的數(shù)據(jù)一致性。這種方式可以有效的減低行鎖，進(jìn)一步提升效率。

內(nèi)聯(lián)事務(wù)：數(shù)據(jù)庫(kù)一旦打散，就必須使用分布式事務(wù)而導(dǎo)致性能急劇下降。因此如何合理的分庫(kù)分表，盡量將操作保證落在同一個(gè)庫(kù)，而使用內(nèi)聯(lián)事務(wù)，是更好的選擇。

柔性事務(wù)：在內(nèi)聯(lián)事務(wù)不適用的跨庫(kù)場(chǎng)景，犧牲強(qiáng)一致性來(lái)?yè)Q取性能的提升，然后采用異步補(bǔ)償?shù)臋C(jī)制來(lái)達(dá)到最終一致性，是柔性事務(wù)的核心理念。

SQL審核：先期過(guò)濾出不符合OLTP的非法SQL。如：DELETE語(yǔ)句沒(méi)有WHERE等。

當(dāng)當(dāng)采用自研的Sharding-JDBC作為數(shù)據(jù)庫(kù)中間層。它直接修改JDBC協(xié)議，因此可以兼容各種數(shù)據(jù)庫(kù)以及ORM框架，應(yīng)用工程師幾乎沒(méi)有學(xué)習(xí)成本，和使用原生JDBC沒(méi)有區(qū)別。應(yīng)用工程師僅需要配置分片規(guī)則，用于告訴Sharding-JDBC哪一個(gè)分片鍵的數(shù)據(jù)應(yīng)該路由至哪個(gè)庫(kù)的哪個(gè)表，即可。

Sharding-JDBC的內(nèi)部結(jié)構(gòu)包括：JDBC規(guī)范重寫(xiě)、SQL解析、 SQL改寫(xiě)、SQL路由、SQL執(zhí)行以及結(jié)果集歸并。

上面兩個(gè)圖是Sharding-JDBC的性能測(cè)試報(bào)告，在單庫(kù)時(shí)，由于SQL解析帶來(lái)的損耗，Sharding-JDBC比原生JDBC慢了0.02%。而將數(shù)據(jù)拆分至雙庫(kù)，Sharding-JDBC比原生JDBC的性能提升了94%，因此，拆分的數(shù)據(jù)庫(kù)實(shí)例越多，其對(duì)性能的提升也越顯著。

Sharding-JDBC定位是面向在線業(yè)務(wù)的框架。因此OLTP涉及到的SQL基本都兼容。

分布式的事務(wù)處理方案有三種：XA，弱XA和柔性事務(wù)。

XA即分布式事務(wù)，他對(duì)業(yè)務(wù)代碼完全沒(méi)有侵入性，而且也可以保證分布式場(chǎng)景下事務(wù)的強(qiáng)一致性，但其性能低下，在互聯(lián)網(wǎng)的場(chǎng)景下非常不適用。

弱XA是分庫(kù)分表數(shù)據(jù)庫(kù)的中間層所提出來(lái)的概念，簡(jiǎn)單說(shuō)就是單片事務(wù)。它僅能控制單節(jié)點(diǎn)事務(wù)的一致性，對(duì)于分布式的事務(wù)完全沒(méi)有控制能力。他不會(huì)對(duì)性能帶來(lái)任何影響，但沒(méi)有一致性的能力，在分布式的場(chǎng)景下極易造成數(shù)據(jù)不一致。

柔性事務(wù)是對(duì)弱XA的補(bǔ)充。它使用異步補(bǔ)償?shù)姆绞剑瑢⒍唐趦?nèi)不一致的數(shù)據(jù)修復(fù)，達(dá)到最終一致性。它用犧牲強(qiáng)一致性的方式提升了性能，因此內(nèi)聯(lián)事務(wù) + 柔性事務(wù)成為了最受青睞的互聯(lián)網(wǎng)事務(wù)處理方案。

柔性事務(wù)有兩種比較成熟實(shí)現(xiàn)方案，最大努力送達(dá)型和TCC（Try Confirm Cancel）。

最大努力送達(dá)型可以保證事務(wù)最終成功，業(yè)務(wù)入侵較小，僅需要業(yè)務(wù)方實(shí)現(xiàn)冪等性即可。它要求事務(wù)最終一定會(huì)成功，無(wú)法回滾，因此會(huì)反復(fù)嘗試，直至最終成功。

TCC類似原生事務(wù)，事務(wù)可以提交，也可以回滾。但事務(wù)的提交和回滾操作均需要業(yè)務(wù)工程師去實(shí)現(xiàn)，因此對(duì)業(yè)務(wù)入侵極大，TCC同樣需要業(yè)務(wù)代碼實(shí)現(xiàn)冪等性。

上圖是最大努力送達(dá)型的流程圖。它在SQL執(zhí)行前記錄事務(wù)日志，在SQL執(zhí)行成功后清理相應(yīng)事務(wù)日志。一旦SQL執(zhí)行失敗，事務(wù)管理器就會(huì)通過(guò)同步和異步執(zhí)行的方式從日志庫(kù)中獲取當(dāng)前的SQL反復(fù)嘗試，直至到達(dá)最大重試次數(shù)為止。超過(guò)最大重試次數(shù)的數(shù)據(jù)需要人工介入處理。

▼

首先，應(yīng)用運(yùn)行時(shí)環(huán)境是通過(guò)容器來(lái)實(shí)現(xiàn)的，不同編程語(yǔ)言編寫(xiě)的應(yīng)用需要不同的運(yùn)行時(shí)環(huán)境，將環(huán)境、應(yīng)用及相關(guān)依賴一起打包發(fā)布是容器的主要作用，在當(dāng)當(dāng)采用的容器解決方案是Docker。另外，容器還可以用于隔離運(yùn)行環(huán)境，讓運(yùn)行在同一宿主機(jī)的不同鏡像可以安全和獨(dú)立的使用既有資源。

其次，僅通過(guò)容器無(wú)法做到應(yīng)用治理。中間件是應(yīng)用彈性化的關(guān)鍵，它分別針對(duì)服務(wù)、作業(yè)以及數(shù)據(jù)庫(kù)訪問(wèn)進(jìn)行有效的增強(qiáng)。服務(wù)和作業(yè)中間件是兩種截然不同的應(yīng)用類型，而數(shù)據(jù)中間件則是它們的有力支撐。無(wú)狀態(tài)的服務(wù)更易彈性擴(kuò)展；而有狀態(tài)的作業(yè)則通過(guò)分片項(xiàng)隔離與數(shù)據(jù)的依賴；數(shù)據(jù)庫(kù)中間件則用于簡(jiǎn)化分布式數(shù)據(jù)庫(kù)的訪問(wèn)以及事務(wù)處理。

最后，一個(gè)可快速運(yùn)行且高度彈性化方案的最后一塊拼圖，即是需要一個(gè)平臺(tái)去合理分配資源以及自動(dòng)分發(fā)應(yīng)用。目前比較流行的是Kubernetes和Mesos兩種方案。在使用的復(fù)雜度上Kubernetes要更加簡(jiǎn)潔和一站式，但Mesos所采用兩級(jí)調(diào)度概念，通過(guò)其Framework定制化非常簡(jiǎn)單，因此當(dāng)當(dāng)選擇Mesos作為資源調(diào)度系統(tǒng)。

分布式調(diào)度系統(tǒng)當(dāng)前有三種架構(gòu)：?jiǎn)误w式，兩階段以及狀態(tài)共享。

單體式調(diào)度較為簡(jiǎn)單，調(diào)度邏輯可以在沒(méi)有任何并發(fā)的情況下使用全部資源。但由于互聯(lián)網(wǎng)業(yè)務(wù)需求多、變化快，因此這種架構(gòu)雖然性能高，但不利于業(yè)務(wù)的快速變化。Hadoop V1即采用此種架構(gòu)。

兩階段調(diào)度將資源通過(guò)Offer的形式分發(fā)給注冊(cè)在調(diào)度系統(tǒng)中的各個(gè)Framework，由Framework負(fù)責(zé)處理接收到的Offer，調(diào)度底層系統(tǒng)僅用于資源的收集和治理。因此此種架構(gòu)更易于通過(guò)Framework定制化擴(kuò)展業(yè)務(wù)需求。Mesos即是兩階段調(diào)度的典型代表。

狀態(tài)共享調(diào)度功能看似最為強(qiáng)大，但實(shí)現(xiàn)起來(lái)卻更加復(fù)雜。它的每一個(gè)Framework都可以看到資源邏輯視圖的全集，采用樂(lè)觀鎖的方式使用資源，每次資源使用時(shí)，需要根據(jù)資源的占用狀態(tài)進(jìn)行類似于事務(wù)方式的提交和回滾。它的優(yōu)點(diǎn)是可以更加有效的利用資源，缺點(diǎn)是實(shí)現(xiàn)難度高。除了Google閉源的Omega系統(tǒng)論文，開(kāi)源產(chǎn)品中目前很少見(jiàn)成熟的實(shí)現(xiàn)方案。

上圖是當(dāng)當(dāng)云平臺(tái)的架構(gòu)圖。中間件API與業(yè)務(wù)應(yīng)用一起打包至Docker鏡像或tar文件，并放入應(yīng)用倉(cāng)庫(kù)。服務(wù)型應(yīng)用當(dāng)當(dāng)采用Marathon管理，由DubboX治理服務(wù)，并與應(yīng)用一同放入Docker鏡像；作業(yè)型應(yīng)用當(dāng)當(dāng)使用自研的Mesos Framework Elastic-Job-Cloud代替Marathon進(jìn)行瞬時(shí)和常駐作業(yè)的治理。

在Elastic-Job-Cloud中采用了自定義Executor和Mesos原生容器，它能夠追加資源。利用此功能，可以有效的聚合作業(yè)，進(jìn)一步簡(jiǎn)化開(kāi)發(fā)并節(jié)省資源。Elastic-Job-Cloud調(diào)度的應(yīng)用使用tar包存入應(yīng)用倉(cāng)庫(kù)。雖然Marathon與Elastic-Job-Cloud所管理的容器不同，但Mesos都會(huì)采用同樣的接口將其分發(fā)至相應(yīng)Mesos Agent執(zhí)行。

上圖是更加全面的整體云化架構(gòu)圖。可以從運(yùn)維、構(gòu)建、日志和監(jiān)控4個(gè)方面說(shuō)明。

運(yùn)維通過(guò)自研的控制臺(tái)，向Mesos Framework發(fā)送信令和讀取數(shù)據(jù)來(lái)達(dá)到控制業(yè)務(wù)應(yīng)用上下線、暫停執(zhí)行等功能，并可查看運(yùn)行時(shí)狀態(tài)。

構(gòu)建是通過(guò)當(dāng)當(dāng)自研的盤(pán)古系統(tǒng)，控制灰度發(fā)布，一鍵回滾等功能，并由盤(pán)古系統(tǒng)將待部署上線的應(yīng)用鏡像推送至Nexus或Docker倉(cāng)庫(kù)。由Mesos Agent自動(dòng)從Nexus獲取tar文件、或由Docker倉(cāng)庫(kù)獲取應(yīng)用鏡像并執(zhí)行。

日志采用的標(biāo)準(zhǔn)的ELK的方式，不過(guò)獲取日志并未使用Logstash，而是采用性能更佳的Filebeat代替。

監(jiān)控是由多個(gè)維度組成。首先使用Mesos Exporter暴露Mesos的狀態(tài)數(shù)據(jù)，然后由時(shí)序數(shù)據(jù)庫(kù)Prometheus定期抓取，并由Grafana展現(xiàn)結(jié)果。Prometheus也通過(guò)Alertmanager向當(dāng)當(dāng)自研的雷達(dá)系統(tǒng)發(fā)送報(bào)警數(shù)據(jù)，由雷達(dá)系統(tǒng)負(fù)責(zé)最終的報(bào)警。其次，雷達(dá)系統(tǒng)還負(fù)責(zé)抓取elasticsearch的報(bào)警日志以及運(yùn)行歷史記錄、SLA等信息一并報(bào)警。

剛才介紹的DubboX、Elastic-Job以及Sharding-JDBC都已開(kāi)源。

Elastic-Job經(jīng)不完全統(tǒng)計(jì)，有30家以上的公司在使用。Elastic-Job目前是Mesosphere官方認(rèn)可的Framework，在Apache Mesos的官方文檔中可以查到，目前已經(jīng)進(jìn)行到對(duì)接DC/OS的最終階段。

Sharding-JDBC僅僅開(kāi)源1年多，即獲取了2016年最受歡迎的國(guó)產(chǎn)開(kāi)源第17名。

三個(gè)開(kāi)源項(xiàng)目均采用Apache協(xié)議，有興趣的同學(xué)請(qǐng)自由使用，歡迎提供寶貴意見(jiàn)。