打造內部應用框架
當當技術部現在是按照產品線劃分的，一個產品線的產品、開發、測試都在一個部門，但像項目管理、運維、架構這些技術體系中公用的部分是獨立的部門。架構部里主要分成三部分，一個是架構與規范，一個是性能測試，一個是基礎應用系統研發。
我們花了比較多的精力在技術架構上，去年我們在Dubbo上做了二次開發，做了DubboX并且對外開源，業界反饋還不錯，包括很多來面試的人都知道。
我們的技術體系、核心業務系統明確的方向是Java，去年年底，我們開始做一個基于Java的應用開發框架，DDFrame，用它去對接一些核心 組件，包括SOA、作業調度、緩存、消息隊列、數據庫、配置中心等，現在已經發布了2.0版本。雖然受限于資源，進度比較緩慢，但我們一直在做這件事，未 來也會慢慢完善這個框架，使其成為技術體系的核心。
開源Dubbox，擴展Dubbo服務框架支持REST風格遠程調用
當當網近日開源了Dubbox項目，可為Dubbo服務框架提供多項擴展功能，包括REST風格遠程調用、Kryo/FST序列化等等。
當當網架構部和技術委員會架構師沈理向InfoQ中文站介紹了Dubbox項目，開發背景和主要特點描述如下：
Dubbo是一個被國內很多互聯網公司廣泛使用的開源分布式服務框架，即使從國際視野來看應該也是一個非常全面的SOA基礎框架。作為一個重要的技術研究課題，在當當網我們根據自身的需求，為Dubbo實現了一些新的功能，并將其命名為Dubbox（即Dubbo eXtensions）。
主要的新功能包括：
支持REST風格遠程調用（HTTP + JSON/XML)：基于非常成熟的JBoss RestEasy框架，在dubbo中實現了REST風格（HTTP + JSON/XML）的遠程調用，以顯著簡化企業內部的跨語言交互，同時顯著簡化企業對外的Open API、無線API甚至AJAX服務端等等的開發。事實上，這個REST調用也使得Dubbo可以對當今特別流行的“微服務”架構提供基礎性支持。 另外，REST調用也達到了比較高的性能，在基準測試下，HTTP + JSON與Dubbo 2.x默認的RPC協議（即TCP + Hessian2二進制序列化）之間只有1.5倍左右的差距，詳見下文的基準測試報告。
支持基于Kryo和FST的Java高效序列化實現：基于當今比較知名的Kryo和FST高性能序列化庫，為Dubbo 默認的RPC協議添加新的序列化實現，并優化調整了其序列化體系，比較顯著的提高了Dubbo RPC的性能，詳見下圖。
支持基于嵌入式Tomcat的HTTP remoting體系：基于嵌入式tomcat實現dubbo的HTTP remoting體系（即dubbo-remoting-http），用以逐步取代Dubbo中舊版本的嵌入式Jetty，可以顯著的提高REST等的遠程調用性能，并將Servlet API的支持從2.5升級到3.1。（注：除了REST，dubbo中的WebServices、Hessian、HTTP Invoker等協議都基于這個HTTP remoting體系）。
升級Spring：將dubbo中Spring由2.x升級到目前最常用的3.x版本，減少項目中版本沖突帶來的麻煩。
升級ZooKeeper客戶端：將dubbo中的zookeeper客戶端升級到最新的版本，以修正老版本中包含的bug。
上面很多功能已在當當網內部穩定的使用，現在開源出來，供大家參考和指正。也希望感興趣的朋友也來為Dubbo貢獻更多的改進。
注：dubbox和dubbo 2.x是兼容的，沒有改變dubbo的任何已有的功能和配置方式（除了升級了Spring之類的版本）。另外，dubbox也嚴格遵循了Apache 2.0許可證的要求。
分布式作業調度框架elastic-job的開源
elastic-job原本是當當java應用框架ddframe的一部分，本名dd-job。ddframe包括編碼規范，開發框架，技術規范，監控以及分布式組件。ddframe規劃分為4個演進階段，目前處于第2階段。3、4階段涉及的技術組件不代表當當沒有使用，只是ddframe還未統一規劃。
ddframe由各種模塊組成，均已dd-開頭，如dd-container、dd-soa、dd-rdb、dd-job等。當當希望將ddframe的各個模塊與公司環境解耦并開源以反饋社區。之前開源的Dubbo擴展版本DubboX即是dd-soa的核心模塊。而本次介紹的elastic-job則是dd-job的開源部分，其中監控（但開源了監控方法）和ddframe核心接入等部分并未開源。
elastic-job主要的設計理念是無中心化的分布式定時調度框架，思路來源于Quartz的基于數據庫的高可用方案。但數據庫畢竟沒有分布式協調功能，所以在高可用方案的基礎上增加了彈性擴容和數據分片的思路，以便于更大限度的利用分布式服務器的資源。
團隊目前由3個部分組成，第一部分是開發團隊，由架構部的架構師曹昊、高洪濤和我組成，主要負責設計和編碼；第二部分是來自于各個研發團隊的應用架構師、開發工程師和架構部總監史海峰，他們負責推廣落地，整理需求并貢獻當當已經存在的最佳實踐代碼；第三部分由架構部性能測試團隊組成，負責框架的性能和穩定性測試。
elastic-job的主要分為注冊中心、數據分片、分布式協調，定時任務處理和多作業模式等模塊。
注冊中心模塊目前直接使用Zookeeper，用于記錄作業的配置，服務器信息以及作業運行狀態。Zookeeper雖然很成熟，但原理復雜，使用較難，在海量數據支持的情況下也會有性能和網絡問題。目前elastic-job已經抽象出注冊中心的接口，下一步將會考慮支持多注冊中心，如etcd，或由用戶自行實現注冊中心。無臨時節點和監聽機制的注冊中心需要自行實現定時心跳監測等功能。
數據分片是elastic-job中實現分布式的重要概念，將真實數據和邏輯分片對應，用于解耦作業框架和數據的關系。作業框架只負責將分片合理的分配給相關的作業服務器，而作業服務器需要根據所分配的分片匹配數據進行處理。服務器分片目前都存儲在注冊中心中，各個服務器根據自己的IP地址拉取分片。
分布式協調模塊用于處理作業服務器的動態擴容縮容。一旦集群中有服務器發生變化，分布式協調將自動監測并將變化結果通知給各個仍存活的作業服務器。協調時將會涉及主節點選舉，重分片等操作。目前使用的Zookeeper的臨時節點和監聽器實現主動檢查和通知功能。
定時任務處理根據cron表達式定時觸發任務，目前有防止任務同時觸發，錯過任務重出發等功能。主要還是使用Quartz本身的定時調度功能，為了便于控制，每個任務都使用獨立的線程池。
多作業模式將定時任務分為多種流程，有不經任何修飾的簡單任務；有用于處理數據的fetchData/processData的數據流任務；以后還將增加消息流任務，文件任務，工作流任務等。用戶能以插件的形式擴展并貢獻代碼。
作業即定時任務。一般來說，系統可使用消息傳遞代替部分使用作業的場景。兩者確有相似之處?？苫ハ嗵鎿Q的場景，如隊列表。將待處理的數據放入隊列表，然后使用頻率極短的定時任務拉取隊列表的數據并處理。這種情況使用消息中間件的推送模式可更好的處理實時性數據。而且基于數據庫的消息存儲吞吐量遠遠小于基于文件的順序追加消息存儲。
但在某些場景下則不能互換：
時間驅動 OR 事件驅動：內部系統一般可以通過事件來驅動，但涉及到外部系統，則只能使用時間驅動。如：抓取外部系統價格。每小時抓取，由于是外部系統，不能像內部系統一樣發送事件觸發事件。
批量處理 OR 逐條處理：批量處理堆積的數據更加高效，在不需要實時性的情況下比消息中間件更有優勢。而且有的業務邏輯只能批量處理，如：電商公司與快遞公司結算，一個月結算一次，并且根據送貨的數量有提成。比如，當月送貨超過1000則額外給快遞公司多1%的快遞費。
非實時性 OR 實時性：雖然消息中間件可以做到實時處理數據，但有的情況并不需要。如：VIP用戶降級，如果超過1年無購買行為，則自動降級。這類需求沒有強烈的時間要求，不需要按照時間精確的降級VIP用戶。
系統內部 OR 系統解耦。作業一般封裝在系統內部，而消息中間件可用于系統間解耦。
elastic-job的主要功能
主要功能
分布式：重寫Quartz基于數據庫的分布式功能，改用Zookeeper實現注冊中心。
并行調度：采用任務分片方式實現。將一個任務拆分為n個獨立的任務項，由分布式的服務器并行執行各自分配到的分片項。
彈性擴容縮容：將任務拆分為n個任務項后，各個服務器分別執行各自分配到的任務項。一旦有新的服務器加入集群，或現有服務器下線，elastic-job將在保留本次任務執行不變的情況下，下次任務開始前觸發任務重分片。
集中管理：采用基于Zookeeper的注冊中心，集中管理和協調分布式作業的狀態，分配和監聽。外部系統可直接根據Zookeeper的數據管理和監控elastic-job。
定制化流程型任務：作業可分為簡單和數據流處理兩種模式，數據流又分為高吞吐處理模式和順序性處理模式，其中高吞吐處理模式可以開啟足夠多的線程快速的處理數據，而順序性處理模式將每個分片項分配到一個獨立線程，用于保證同一分片的順序性，這點類似于kafka的分區順序性。
其他功能
失效轉移：彈性擴容縮容在下次作業運行前重分片，但本次作業執行的過程中，下線的服務器所分配的作業將不會重新被分配。失效轉移功能可以在本次作業運行中用空閑服務器抓取孤兒作業分片執行。同樣失效轉移功能也會犧牲部分性能。
Spring命名空間支持：elastic-job可以不依賴于spring直接運行，但是也提供了自定義的命名空間方便與spring集成。
運維平臺：提供web控制臺用于管理作業。
非功能需求
穩定性：在服務器無波動的情況下，并不會重新分片；即使服務器有波動，下次分片的結果也會根據服務器IP和作業名稱哈希值算出穩定的分片順序，盡量不做大的變動。
高性能：同一服務器的批量數據處理采用自動切割并多線程并行處理。
靈活性：所有在功能和性能之間的權衡，都可通過配置開啟/關閉。如：elastic-job會將作業運行狀態的必要信息更新到注冊中心。如果作業執行頻度很高，會造成大量Zookeeper寫操作，而分布式Zookeeper同步數據可能引起網絡風暴。因此為了考慮性能問題，可以犧牲一些功能，而換取性能的提升。
冪等性：elastic-job可犧牲部分性能用以保證同一分片項不會同時在兩個服務器上運行。
容錯性：作業服務器和Zookeeper斷開連接則立即停止作業運行，用于防止分片已經重新分配，而腦裂的服務器仍在繼續執行，導致重復執行。
Elastic-job在當當內部也是剛剛進行推廣，目前支付系統、訂單系統、發票系統、促銷系統都有使用，快遞系統和倉儲系統也即將使用。開源后也得知不少公司有使用計劃。
