內(nèi)容來源：2017年6月24日瞎饲，當當架構部總監(jiān)在“雙態(tài)運維·烏鎮(zhèn)峰會-數(shù)人云專題研討會”進行《當當彈性化中間件及云化之路》演講分享零聚。本文為整理的文字稿眶蕉，由數(shù)人云公眾號（id：dmesos）編輯勋乾，IT大咖說（id：itdakashuo）作為現(xiàn)場視頻直播提供方，經(jīng)授權轉(zhuǎn)載枕磁。

嘉賓演講視頻回顧及PPT：http://suo.im/5jq1Hm

摘要

6月24日渡蜻，雙態(tài)運維·烏鎮(zhèn)峰會-數(shù)人云專題研討會上，張亮老師從業(yè)務计济、中間件茸苇、云化的方向出發(fā)，分享了當當網(wǎng)實踐落地容器的經(jīng)驗沦寂。小編掐指一算学密，稀缺好文，宜收藏和分享传藏！

今天主分享的內(nèi)容分為三部分——

第一部分：當當業(yè)務體系簡介则果。受限于時間幔翰，只做簡單概述。

第二部分：介紹當當?shù)膹椥曰虚g件∥髯常現(xiàn)階段遗增，無狀態(tài)容器已趨于成熟，需要進一步開發(fā)和優(yōu)化的是運行在容器里面的部分款青，即中間件做修。

第三部分：當當?shù)脑苹贰?/p>

業(yè)務特征

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

海量用戶當當面向的是完全開放的饰及、整個互聯(lián)網(wǎng)的億級用戶量。

品類繁多當當是賣書起家的康震，書的品類是很多的燎含。除了書，當當還有百貨腿短、服裝等屏箍。與垂直電商不同，水平電商由于品類繁多橘忱，因此數(shù)據(jù)架構也會有很大區(qū)別赴魁。

7*24互聯(lián)網(wǎng)公司基本都是如此要求，盡量縮短宕機時間钝诚。

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

業(yè)務復雜下圖是業(yè)務框架圖凝颇，分為三部分潘拱，中間部分是當當主業(yè)務流程，從用戶查看選擇商品的賣場模塊拧略，到購物車芦岂、結算的交易模塊，最后發(fā)至訂單工作流系統(tǒng)辑鲤；然后通過倉儲系統(tǒng)生產(chǎn)訂單盔腔，并交由物流系統(tǒng)配送貨品。上面部分是用戶相關的系統(tǒng)月褥，如搜索弛随、推薦、促銷宁赤、會員等舀透。下面部分是為當當運營人員與合作伙伴提供的系統(tǒng)，如商品决左、價格愕够、庫存等走贪。

這僅是縮略版的系統(tǒng)架構圖，當當實際系統(tǒng)要復雜的多惑芭、用到的語言也各異坠狡，大部分如：前端PHP、后端Java遂跟、搜索系統(tǒng)用C++逃沿，推薦系統(tǒng)用Go和Python。因此它是一個由異構語言組成的復雜系統(tǒng)集合幻锁。?

業(yè)務特征·互聯(lián)網(wǎng)架構核心問題

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

海量數(shù)據(jù)：包括但不限于用戶數(shù)據(jù)哄尔、商品數(shù)據(jù)假消、交易數(shù)據(jù)、訂單數(shù)據(jù)岭接、用戶行為數(shù)據(jù)等富拗。由于數(shù)據(jù)量巨大，因此不能僅使用單一的數(shù)據(jù)存儲結構亿傅，也不能以單數(shù)據(jù)節(jié)點的方式存儲所有數(shù)據(jù)媒峡。

響應遲緩：大量的用戶訪問瘟栖，使得系統(tǒng)承載了更多流量葵擎，處理過多的請求會導致系統(tǒng)響應變的遲緩。

系統(tǒng)繁多：通過上一張圖可以得知半哟，系統(tǒng)是由非常多的子系統(tǒng)組成的酬滤，每個子系統(tǒng)各司其職。合理的系統(tǒng)拆分可以靈活的分離冷熱數(shù)據(jù)寓涨、擴容重點系統(tǒng)等盯串。

開發(fā)困難：各個系統(tǒng)都是由異構語言的不同技術棧構成，開發(fā)成本較高戒良。

穩(wěn)定性差：由于系統(tǒng)間交互增多体捏，系統(tǒng)之間會形成一個復雜的交互網(wǎng)。任一系統(tǒng)出現(xiàn)問題糯崎，都可能導致部分不可用几缭，進而增加整體不可控的風險。系統(tǒng)拆分的越多沃呢，出問題的可能性就越大年栓，系統(tǒng)穩(wěn)定性就會越差。

伸縮性差：電商公司不可能常備“雙11”的機器體量薄霜。因此遇到大促等需要承載突發(fā)流量的場景某抓，系統(tǒng)需要可以彈性伸縮纸兔。在流量增加的時候擴張容量，用于承接更多的購買需求否副；在流量下降的時候收縮容量汉矿，節(jié)省成本。

中間件·解決方案=中間件+云平臺

解決方案是中間件+云平臺备禀。

中間件解決的主要問題是服務化负甸、彈性化和異步化。

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

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

異步化：將同步調(diào)用鏈梳理為同步落盤?+ 異步處理的方式以提升吞吐量。

云平臺解決的主要問題是部署自動化和監(jiān)控一體化队腐。

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

中間件·基礎3件套

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

中間件·服務中間件

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

遠程調(diào)用：分為長連接調(diào)用和短連接調(diào)用兩種方式。長鏈接采用Socket?+ 二進制序列化的方式居多斋攀，短連接以HTTP?RESTFul + JSON的方式為主橡淑。無論采用何種調(diào)用方式，都應在服務中間件中封裝為統(tǒng)一接口。

服務發(fā)現(xiàn)：自動感知上線和下線的應用，并分配和截斷相應的請求。標準實現(xiàn)方案是通過一個注冊中心管理和協(xié)調(diào)分布式應用桥爽，常見的注冊中心有Zookeeper，etcd和Eureka碉渡。

負載均衡：合理的將流量分配給權重不盡相同的分布式節(jié)點聚谁。

服務治理：包括服務調(diào)動鏈梳理、服務降級滞诺、服務版本控制等功能形导。

限流：將過載的流量擋在后端系統(tǒng)之外环疼，讓部分不過載的請求可以繼續(xù)提供服務。保證系統(tǒng)不會因為突增的流量而被完全沖垮朵耕，而是任何情況下都能提供對核心用戶的平穩(wěn)服務能力炫隶。

監(jiān)控報警：提供將內(nèi)部指標通過API對接到外部系統(tǒng)的能力，內(nèi)部指標一般有SLA阎曹、服務狀態(tài)伪阶、節(jié)點承載量等。

上圖是當當采用的服務框架——DubboX处嫌。

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

使用DubboX部署的程序骗卜，在邏輯上分為兩部分宠页。上面部分是服務的提供者；下面部分是服務的消費者膨俐。服務消費者在REST協(xié)議的場景勇皇，是直接通過Nginx代理訪問服務提供者的罩句。如果采用Java同構應用焚刺，可以使用Dubbo原生的長鏈接+Dubbo協(xié)議，并通過注冊中心服務發(fā)現(xiàn)门烂，以及客戶端負載均衡乳愉。

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

中間件·服務中間件

當當系統(tǒng)中很多業(yè)務是由作業(yè)實現(xiàn)的屯远，如拉單作業(yè)蔓姚、價格同步作業(yè)等。因為公司系統(tǒng)較多慨丐，很難通過唯一的方案實現(xiàn)坡脐，因此也有部分系統(tǒng)通過消息中間件完成。作業(yè)中間件的核心功能主要包括：

定時調(diào)度：根據(jù)cron表達式的時間調(diào)度應用房揭。

任務分片：將一個大任務拆分成為多個任務片段备闲，分布運行晌端。此功能后文會重點介紹。

彈性擴容：與任務分片息息相關恬砂，一并在后文中介紹咧纠。

作業(yè)治理：管控作業(yè)生命周期，如：執(zhí)行泻骤、禁用漆羔、啟用以及更復雜的行為，如：失效轉(zhuǎn)移狱掂、錯過任務重觸發(fā)等演痒。

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

當當采用的作業(yè)中間件是自研的Elastic-Job嫡霞，它可以將一個完整的作業(yè)拆分為多個相互獨立的任務。一個完整的作業(yè)運行時間可能較長希柿，但很難通過增加機器實例提升運行效率诊沪。通過Elastic-Job將作業(yè)拆分為多個任務，可以并行的在分布式的環(huán)境中運行曾撤，提升其處理速度端姚。用戶可以實現(xiàn)自己的分片策略，將任務分配至合適的節(jié)點運行挤悉。

通過上圖舉例渐裸，作業(yè)分為4片，由兩臺服務器執(zhí)行装悲，每臺執(zhí)行兩片昏鹃。當增加一臺服務器時，如下圖所示诀诊，分片項被稀釋為服務器1和3各執(zhí)行一片洞渤，服務器2執(zhí)行兩片，那么服務器1和3由于執(zhí)行的分片項減少属瓣，從而提升性能载迄。

而一旦有服務器宕機，如下圖所示抡蛙，僅剩余一臺服務器可以提供服務护昧，那么所有的分片都將指向該服務器。集群的整體處理能力會下降粗截，但作業(yè)的完整性不會受到影響惋耙，從而提供高可用的能力。

因此，隨著運行實例的增加和減少绽榛，Elastic-Job可以動態(tài)的調(diào)整分片來提升性能和保證可用性遥金。

這是Elastic-Job的部署架構圖。

中間件·服務中間件

接下來介紹的是數(shù)據(jù)庫中間件蒜田。關系型數(shù)據(jù)庫在大數(shù)據(jù)量的情況下稿械，單庫單表難以支撐。解決方案是將單一的數(shù)據(jù)庫拆分為分布式數(shù)據(jù)庫冲粤，而讓開發(fā)和運維人員像訪問一個數(shù)據(jù)庫一樣訪問分布式數(shù)據(jù)庫美莫，屏蔽其復雜度，是數(shù)據(jù)庫中間件的基本功能梯捕。數(shù)據(jù)庫中間件的核心功能主要包括：

分庫分表：通過打散數(shù)據(jù)的方式有效的減少每個表的數(shù)據(jù)量厢呵，減少索引的深度以提升查詢性能。并且拆分數(shù)據(jù)庫來有效的疏導請求流量傀顾。

讀寫分離：進一步提升數(shù)據(jù)庫的性能可以采用讀寫分離襟铭。讀庫僅負責響應查詢，寫庫相應更新短曾，通過異步數(shù)據(jù)同步的方式保持讀寫庫的數(shù)據(jù)一致性寒砖。這種方式可以有效的減低行鎖，進一步提升效率嫉拐。

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

柔性事務：在內(nèi)聯(lián)事務不適用的跨庫場景儒鹿，犧牲強一致性來換取性能的提升，然后采用異步補償?shù)臋C制來達到最終一致性几晤，是柔性事務的核心理念约炎。

SQL審核：先期過濾出不符合OLTP的非法SQL。如：DELETE語句沒有WHERE等锌仅。

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

Sharding-JDBC的內(nèi)部結構包括：JDBC規(guī)范重寫报腔、SQL解析株搔、 SQL改寫、SQL路由纯蛾、SQL執(zhí)行以及結果集歸并纤房。

上面兩個圖是Sharding-JDBC的性能測試報告，在單庫時翻诉，由于SQL解析帶來的損耗炮姨，Sharding-JDBC比原生JDBC慢了0.02%。而將數(shù)據(jù)拆分至雙庫碰煌，Sharding-JDBC比原生JDBC的性能提升了94%舒岸，因此，拆分的數(shù)據(jù)庫實例越多芦圾，其對性能的提升也越顯著蛾派。

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

分布式的事務處理方案有三種：XA洪乍，弱XA和柔性事務。

XA即分布式事務夜焦，他對業(yè)務代碼完全沒有侵入性典尾，而且也可以保證分布式場景下事務的強一致性，但其性能低下糊探，在互聯(lián)網(wǎng)的場景下非常不適用钾埂。

弱XA是分庫分表數(shù)據(jù)庫的中間層所提出來的概念，簡單說就是單片事務科平。它僅能控制單節(jié)點事務的一致性褥紫，對于分布式的事務完全沒有控制能力。他不會對性能帶來任何影響瞪慧，但沒有一致性的能力髓考，在分布式的場景下極易造成數(shù)據(jù)不一致。

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

柔性事務有兩種比較成熟實現(xiàn)方案榜贴，最大努力送達型和TCC（Try Confirm?Cancel）豌研。

最大努力送達型可以保證事務最終成功，業(yè)務入侵較小，僅需要業(yè)務方實現(xiàn)冪等性即可鹃共。它要求事務最終一定會成功鬼佣，無法回滾，因此會反復嘗試霜浴，直至最終成功晶衷。

TCC類似原生事務，事務可以提交阴孟，也可以回滾晌纫。但事務的提交和回滾操作均需要業(yè)務工程師去實現(xiàn)，因此對業(yè)務入侵極大温眉，TCC同樣需要業(yè)務代碼實現(xiàn)冪等性缸匪。

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

云化

首先蛇耀，應用運行時環(huán)境是通過容器來實現(xiàn)的辩诞，不同編程語言編寫的應用需要不同的運行時環(huán)境，將環(huán)境纺涤、應用及相關依賴一起打包發(fā)布是容器的主要作用译暂，在當當采用的容器解決方案是Docker。另外撩炊，容器還可以用于隔離運行環(huán)境外永，讓運行在同一宿主機的不同鏡像可以安全和獨立的使用既有資源。

其次拧咳，僅通過容器無法做到應用治理伯顶。中間件是應用彈性化的關鍵，它分別針對服務骆膝、作業(yè)以及數(shù)據(jù)庫訪問進行有效的增強祭衩。服務和作業(yè)中間件是兩種截然不同的應用類型，而數(shù)據(jù)中間件則是它們的有力支撐阅签。無狀態(tài)的服務更易彈性擴展掐暮；而有狀態(tài)的作業(yè)則通過分片項隔離與數(shù)據(jù)的依賴；數(shù)據(jù)庫中間件則用于簡化分布式數(shù)據(jù)庫的訪問以及事務處理愉择。

最后劫乱，一個可快速運行且高度彈性化方案的最后一塊拼圖织中，即是需要一個平臺去合理分配資源以及自動分發(fā)應用锥涕。目前比較流行的是Kubernetes和Mesos兩種方案衷戈。在使用的復雜度上Kubernetes要更加簡潔和一站式，但Mesos所采用兩級調(diào)度概念层坠，通過其Framework定制化非常簡單殖妇，因此當當選擇Mesos作為資源調(diào)度系統(tǒng)。

分布式調(diào)度系統(tǒng)當前有三種架構：單體式破花，兩階段以及狀態(tài)共享谦趣。

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

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

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

上圖是當當云平臺的架構圖流济。中間件API與業(yè)務應用一起打包至Docker鏡像或tar文件锐锣，并放入應用倉庫。服務型應用當當采用Marathon管理绳瘟，由DubboX治理服務雕憔，并與應用一同放入Docker鏡像；作業(yè)型應用當當使用自研的Mesos Framework Elastic-Job-Cloud代替Marathon進行瞬時和常駐作業(yè)的治理糖声。

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

上圖是更加全面的整體云化架構圖∏钣迹可以從運維土陪、構建、日志和監(jiān)控4個方面說明肴熏。

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

構建是通過當當自研的盤古系統(tǒng)，控制灰度發(fā)布出刷，一鍵回滾等功能璧疗，并由盤古系統(tǒng)將待部署上線的應用鏡像推送至Nexus或Docker倉庫。由Mesos Agent自動從Nexus獲取tar文件馁龟、或由Docker倉庫獲取應用鏡像并執(zhí)行崩侠。

日志采用的標準的ELK的方式，不過獲取日志并未使用Logstash坷檩，而是采用性能更佳的Filebeat代替却音。

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

剛才介紹的DubboX、Elastic-Job以及Sharding-JDBC都已開源资昧。

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

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

三個開源項目均采用Apache協(xié)議微宝，有興趣的同學請自由使用，歡迎提供寶貴意見凉袱。