內容來源：2017年6月24日，噹噹架構部總監在“雙態運維·烏鎮峰會-數人云專題研討會”進行《噹噹彈性化中介軟體及雲化之路》演講分享。本文轉自數人云公眾號（dmesos）。
摘要
6月24日，雙態運維·烏鎮峰會-數人云專題研討會上，張亮老師從業務、中介軟體、雲化的方向出發，分享了當當網實踐落地容器的經驗。小編掐指一算，稀缺好文，宜收藏和分享！
今天主分享的內容分為三部分——
第一部分：噹噹業務體系簡介。受限於時間，只做簡單概述。
第二部分：介紹噹噹的彈性化中介軟體。現階段，無狀態容器已趨於成熟，需要進一步開發和優化的是執行在容器裡面的部分，即中介軟體。
第三部分：噹噹的雲化之路。
嘉賓演講視訊地址：t.cn/R96OZby
業務特徵
首先，介紹下噹噹的業務特徵，這也是網際網路行業的共有特徵：
-
海量使用者 噹噹面向的是完全開放的、整個網際網路的億級使用者量。
-
品類繁多 噹噹是賣書起家的，書的品類是很多的。除了書，噹噹還有百貨、服裝等。與垂直電商不同，水平電商由於品類繁多，因此資料架構也會有很大區別。
-
7*24 網際網路公司基本都是如此要求，儘量縮短當機時間。
-
流量突增 如“雙11”或“書香節”，其流量是平時的幾倍到幾十倍不等。
-
業務複雜 下圖是業務框架圖，分為三部分，中間部分是噹噹主業務流程，從使用者檢視選擇商品的賣場模組，到購物車、結算的交易模組，最後發至訂單工作流系統；然後通過倉儲系統生產訂單，並交由物流系統配送貨品。上面部分是使用者相關的系統，如搜尋、推薦、促銷、會員等。下面部分是為噹噹運營人員與合作伙伴提供的系統，如商品、價格、庫存等。
這僅是縮略版的系統架構圖，噹噹實際系統要複雜的多、用到的語言也各異，大部分如：前端PHP、後端Java、搜尋系統用C++，推薦系統用Go和Python。因此它是一個由異構語言組成的複雜系統集合。
業務特徵·網際網路架構核心問題
網際網路核心問題和企業級開發不一樣的地方在於規模。網際網路公司的規模由以下幾點組成的——
海量資料：包括但不限於使用者資料、商品資料、交易資料、訂單資料、使用者行為資料等。由於資料量巨大，因此不能僅使用單一的資料儲存結構，也不能以單資料節點的方式儲存所有資料。
響應遲緩：大量的使用者訪問，使得系統承載了更多流量，處理過多的請求會導致系統響應變的遲緩。
系統繁多：通過上一張圖可以得知，系統是由非常多的子系統組成的，每個子系統各司其職。合理的系統拆分可以靈活的分離冷熱資料、擴容重點系統等。
開發困難：各個系統都是由異構語言的不同技術棧構成，開發成本較高。
穩定性差：由於系統間互動增多，系統之間會形成一個複雜的互動網。任一系統出現問題，都可能導致部分不可用，進而增加整體不可控的風險。系統拆分的越多，出問題的可能性就越大，系統穩定性就會越差。
伸縮性差：電商公司不可能常備“雙11”的機器體量。因此遇到大促等需要承載突發流量的場景，系統需要可以彈性伸縮。在流量增加的時候擴張容量，用於承接更多的購買需求；在流量下降的時候收縮容量，節省成本。
中介軟體·解決方案=中介軟體+雲平臺
解決方案是中介軟體+雲平臺。
中介軟體解決的主要問題是服務化、彈性化和非同步化。
-
服務化：眾多系統間應該提供一致的互動和治理方式。
-
彈性化：讓系統具備根據實際需要靈活的擴縮容的能力。
-
非同步化：將同步呼叫鏈梳理為同步落盤 + 非同步處理的方式以提升吞吐量。
雲平臺解決的主要問題是部署自動化和監控一體化。
中介軟體缺乏對執行環境搭建，App部署分發等能力，也難以提供統一的監控一體化系統，因此雲平臺在這方面是對中介軟體的有益補充。
中介軟體·基礎3件套
這裡介紹最主要的三個中介軟體：服務中介軟體、作業中介軟體和資料中介軟體。中介軟體遠遠不止這三種，限於時間，無法涵蓋全部的中介軟體：如訊息中介軟體、快取中介軟體、NoSQL以及離線大資料等因時間關係不在分享範圍之內。
中介軟體·服務中介軟體
服務中介軟體有很多優秀的開源產品，從早期的Finagle, Dubbo，到近期出現的Motan，Spring Cloud都是個中翹楚。服務中介軟體的核心功能主要包括：
遠端呼叫：分為長連線呼叫和短連線呼叫兩種方式。長連結採用Socket + 二進位制序列化的方式居多，短連線以HTTP RESTFul + JSON的方式為主。無論採用何種呼叫方式，都應在服務中介軟體中封裝為統一介面。
服務發現：自動感知上線和下線的應用，並分配和截斷相應的請求。標準實現方案是通過一個註冊中心管理和協調分散式應用，常見的註冊中心有Zookeeper，etcd和Eureka。
負載均衡：合理的將流量分配給權重不盡相同的分散式節點。
服務治理：包括服務調動鏈梳理、服務降級、服務版本控制等功能。
限流：將過載的流量擋在後端系統之外，讓部分不過載的請求可以繼續提供服務。保證系統不會因為突增的流量而被完全沖垮，而是任何情況下都能提供對核心使用者的平穩服務能力。
監控報警：提供將內部指標通過API對接到外部系統的能力，內部指標一般有SLA、服務狀態、節點承載量等。
上圖是噹噹採用的服務框架——DubboX。
該專案Fork了阿里開源的Dubbo，並內建了Web伺服器且增加REST協議，用於支援異構語言間的呼叫。每個基於DubboX的應用均可通過內建的Web伺服器提供服務，每個Web伺服器通過Nginx實現負載均衡。並且在Nginx通過OpenResty實現了基於漏桶和令牌桶兩種演算法的限流外掛。請求呼叫資訊通過Agent的本地彙總之後，定期傳送至一個Kafka的訊息佇列，並通過Storm的二次彙總計算出SLA，儲存至資料庫中。最終由監控系統定期抓取報警資料。
使用DubboX部署的程式，在邏輯上分為兩部分。上面部分是服務的提供者；下面部分是服務的消費者。服務消費者在REST協議的場景，是直接通過Nginx代理訪問服務提供者的。如果採用Java同構應用，可以使用Dubbo原生的長連結+Dubbo協議，並通過註冊中心服務發現，以及客戶端負載均衡。
下圖是噹噹的SLA監控系統以及限流系統的Dashboard。
中介軟體·服務中介軟體
噹噹系統中很多業務是由作業實現的，如拉單作業、價格同步作業等。因為公司系統較多，很難通過唯一的方案實現，因此也有部分系統通過訊息中介軟體完成。作業中介軟體的核心功能主要包括：
-
定時排程：根據cron表示式的時間排程應用。
-
任務分片：將一個大任務拆分成為多個任務片段，分佈執行。此功能後文會重點介紹。
-
彈性擴容：與任務分片息息相關，一併在後文中介紹。
-
作業治理：管控作業生命週期，如：執行、禁用、啟用以及更復雜的行為，如：失效轉移、錯過任務重觸發等。
-
監控報警：提供將作業執行狀態、歷史統計和查詢對接至外部系統的能力。
噹噹採用的作業中介軟體是自研的Elastic-Job，它可以將一個完整的作業拆分為多個相互獨立的任務。一個完整的作業執行時間可能較長，但很難通過增加機器例項提升執行效率。通過Elastic-Job將作業拆分為多個任務，可以並行的在分散式的環境中執行，提升其處理速度。使用者可以實現自己的分片策略，將任務分配至合適的節點執行。
通過上圖舉例，作業分為4片，由兩臺伺服器執行，每臺執行兩片。當增加一臺伺服器時，如下圖所示，分片項被稀釋為伺服器1和3各執行一片，伺服器2執行兩片，那麼伺服器1和3由於執行的分片項減少，從而提升效能。
而一旦有伺服器當機，如下圖所示，僅剩餘一臺伺服器可以提供服務，那麼所有的分片都將指向該伺服器。叢集的整體處理能力會下降，但作業的完整性不會受到影響，從而提供高可用的能力。
因此，隨著執行例項的增加和減少，Elastic-Job可以動態的調整分片來提升效能和保證可用性。
這是Elastic-Job的部署架構圖。
中介軟體·服務中介軟體
接下來介紹的是資料庫中介軟體。關係型資料庫在大資料量的情況下，單庫單表難以支撐。解決方案是將單一的資料庫拆分為分散式資料庫，而讓開發和運維人員像訪問一個資料庫一樣訪問分散式資料庫，遮蔽其複雜度，是資料庫中介軟體的基本功能。資料庫中介軟體的核心功能主要包括：
分庫分表：通過打散資料的方式有效的減少每個表的資料量，減少索引的深度以提升查詢效能。並且拆分資料庫來有效的疏導請求流量。
讀寫分離：進一步提升資料庫的效能可以採用讀寫分離。讀庫僅負責響應查詢，寫庫相應更新，通過非同步資料同步的方式保持讀寫庫的資料一致性。這種方式可以有效的減低行鎖，進一步提升效率。
內聯事務：資料庫一旦打散，就必須使用分散式事務而導致效能急劇下降。因此如何合理的分庫分表，儘量將操作保證落在同一個庫，而使用內聯事務，是更好的選擇。
柔性事務：在內聯事務不適用的跨庫場景，犧牲強一致性來換取效能的提升，然後採用非同步補償的機制來達到最終一致性，是柔性事務的核心理念。
SQL稽核：先期過濾出不符合OLTP的非法SQL。如：DELETE語句沒有WHERE等。
噹噹採用自研的Sharding-JDBC作為資料庫中間層。它直接修改JDBC協議，因此可以相容各種資料庫以及ORM框架，應用工程師幾乎沒有學習成本，和使用原生JDBC沒有區別。應用工程師僅需要配置分片規則，用於告訴Sharding-JDBC哪一個分片鍵的資料應該路由至哪個庫的哪個表，即可。
Sharding-JDBC的內部結構包括：JDBC規範重寫、SQL解析、 SQL改寫、SQL路由、SQL執行以及結果集歸併。
上面兩個圖是Sharding-JDBC的效能測試報告，在單庫時，由於SQL解析帶來的損耗，Sharding-JDBC比原生JDBC慢了0.02%。而將資料拆分至雙庫，Sharding-JDBC比原生JDBC的效能提升了94%，因此，拆分的資料庫例項越多，其對效能的提升也越顯著。
Sharding-JDBC定位是面向線上業務的框架。因此OLTP涉及到的SQL基本都相容。
分散式的事務處理方案有三種：XA，弱XA和柔性事務。
XA即分散式事務，他對業務程式碼完全沒有侵入性，而且也可以保證分散式場景下事務的強一致性，但其效能低下，在網際網路的場景下非常不適用。
弱XA是分庫分表資料庫的中間層所提出來的概念，簡單說就是單片事務。它僅能控制單節點事務的一致性，對於分散式的事務完全沒有控制能力。他不會對效能帶來任何影響，但沒有一致性的能力，在分散式的場景下極易造成資料不一致。
柔性事務是對弱XA的補充。它使用非同步補償的方式，將短期內不一致的資料修復，達到最終一致性。它用犧牲強一致性的方式提升了效能，因此內聯事務 + 柔性事務成為了最受青睞的網際網路事務處理方案。
柔性事務有兩種比較成熟實現方案，最大努力送達型和TCC（Try Confirm Cancel）。
最大努力送達型可以保證事務最終成功，業務入侵較小，僅需要業務方實現冪等性即可。它要求事務最終一定會成功，無法回滾，因此會反覆嘗試，直至最終成功。
TCC類似原生事務，事務可以提交，也可以回滾。但事務的提交和回滾操作均需要業務工程師去實現，因此對業務入侵極大，TCC同樣需要業務程式碼實現冪等性。
上圖是最大努力送達型的流程圖。它在SQL執行前記錄事務日誌，在SQL執行成功後清理相應事務日誌。一旦SQL執行失敗，事務管理器就會通過同步和非同步執行的方式從日誌庫中獲取當前的SQL反覆嘗試，直至到達最大重試次數為止。超過最大重試次數的資料需要人工介入處理。
雲化
-
首先，應用執行時環境是通過容器來實現的，不同程式語言編寫的應用需要不同的執行時環境，將環境、應用及相關依賴一起打包釋出是容器的主要作用，在噹噹採用的容器解決方案是Docker。另外，容器還可以用於隔離執行環境，讓執行在同一宿主機的不同映象可以安全和獨立的使用既有資源。
-
其次，僅通過容器無法做到應用治理。中介軟體是應用彈性化的關鍵，它分別針對服務、作業以及資料庫訪問進行有效的增強。服務和作業中介軟體是兩種截然不同的應用型別，而資料中介軟體則是它們的有力支撐。無狀態的服務更易彈性擴充套件；而有狀態的作業則通過分片項隔離與資料的依賴；資料庫中介軟體則用於簡化分散式資料庫的訪問以及事務處理。
-
最後，一個可快速執行且高度彈性化方案的最後一塊拼圖，即是需要一個平臺去合理分配資源以及自動分發應用。目前比較流行的是Kubernetes和Mesos兩種方案。在使用的複雜度上Kubernetes要更加簡潔和一站式，但Mesos所採用兩級排程概念，通過其Framework定製化非常簡單，因此噹噹選擇Mesos作為資源排程系統。
分散式排程系統當前有三種架構：單體式，兩階段以及狀態共享。
單體式排程較為簡單，排程邏輯可以在沒有任何併發的情況下使用全部資源。但由於網際網路業務需求多、變化快，因此這種架構雖然效能高，但不利於業務的快速變化。Hadoop V1即採用此種架構。
兩階段排程將資源通過Offer的形式分發給註冊在排程系統中的各個Framework，由Framework負責處理接收到的Offer，排程底層系統僅用於資源的收集和治理。因此此種架構更易於通過Framework定製化擴充套件業務需求。Mesos即是兩階段排程的典型代表。
狀態共享排程功能看似最為強大，但實現起來卻更加複雜。它的每一個Framework都可以看到資源邏輯檢視的全集，採用樂觀鎖的方式使用資源，每次資源使用時，需要根據資源的佔用狀態進行類似於事務方式的提交和回滾。它的優點是可以更加有效的利用資源，缺點是實現難度高。除了Google閉源的Omega系統論文，開源產品中目前很少見成熟的實現方案。
上圖是噹噹雲平臺的架構圖。中介軟體API與業務應用一起打包至Docker映象或tar檔案，並放入應用倉庫。服務型應用噹噹採用Marathon管理，由DubboX治理服務，並與應用一同放入Docker映象；作業型應用噹噹使用自研的Mesos Framework Elastic-Job-Cloud代替Marathon進行瞬時和常駐作業的治理。
在Elastic-Job-Cloud中採用了自定義Executor和Mesos原生容器，它能夠追加資源。利用此功能，可以有效的聚合作業，進一步簡化開發並節省資源。Elastic-Job-Cloud排程的應用使用tar包存入應用倉庫。雖然Marathon與Elastic-Job-Cloud所管理的容器不同，但Mesos都會採用同樣的介面將其分發至相應Mesos Agent執行。
上圖是更加全面的整體雲化架構圖。可以從運維、構建、日誌和監控4個方面說明。
運維通過自研的控制檯，向Mesos Framework傳送信令和讀取資料來達到控制業務應用上下線、暫停執行等功能，並可檢視執行時狀態。
構建是通過當當自研的盤古系統，控制灰度釋出，一鍵回滾等功能，並由盤古系統將待部署上線的應用映象推送至Nexus或Docker倉庫。由Mesos Agent自動從Nexus獲取tar檔案、或由Docker倉庫獲取應用映象並執行。
日誌採用的標準的ELK的方式，不過獲取日誌並未使用Logstash，而是採用效能更佳的Filebeat代替。
監控是由多個維度組成。首先使用Mesos Exporter暴露Mesos的狀態資料，然後由時序資料庫Prometheus定期抓取，並由Grafana展現結果。Prometheus也通過Alertmanager向當當自研的雷達系統傳送報警資料，由雷達系統負責最終的報警。其次，雷達系統還負責抓取elasticsearch的報警日誌以及執行歷史記錄、SLA等資訊一併報警。
剛才介紹的DubboX、Elastic-Job以及Sharding-JDBC都已開源。
Elastic-Job經不完全統計，有30家以上的公司在使用。Elastic-Job目前是Mesosphere官方認可的Framework，在Apache Mesos的官方文件中可以查到，目前已經進行到對接DC/OS的最終階段。
Sharding-JDBC僅僅開源1年多，即獲取了2016年最受歡迎的國產開源第17名。
三個開源專案均採用Apache協議，有興趣的同學請自由使用，歡迎提供寶貴意見。