九色国产,午夜在线视频,新黄色网址,九九色综合,天天做夜夜做久久做狠狠,天天躁夜夜躁狠狠躁2021a,久久不卡一区二区三区

打開APP
userphoto
未登錄

開通VIP,暢享免費電子書等14項超值服

開通VIP
專訪當當網張亮:深度解讀分布式作業(yè)調度框架elastic

【編者按】互聯(lián)網從誕生到現(xiàn)在,網站的規(guī)模不斷擴大,存儲和處理的數(shù)據量也遠遠超出了人們的想象,又隨著對信息實時性、多媒體需求大幅增長的現(xiàn)象,互聯(lián)網架構面臨越來越大的挑戰(zhàn)。CSDN致力于解決這一問題,在剛剛結束的 SDCC 2015中國軟件開發(fā)者大會上,特舉辦了架構專場(上午報報道、下午報道),以及《程序員》電子刊10月B開設了架構專題。在接下來也將繼續(xù)深耕架構師、服務于開發(fā)者,推出更多的大牛訪談、知名互聯(lián)網公司架構實踐、技術公開課等,敬請期待。

日前,筆者采訪了當當網架構師、當當技術委員會成員張亮,在本次采訪中他主要分享了對架構師的理解,以及重點解讀了分布式作業(yè)調度框架Elastic-job是什么、架構設計思路、具體模塊的底層及如何實現(xiàn)等。

張亮對架構設計、消息中間件、分布式等領域興趣濃厚。目前主導當當應用框架ddframe研發(fā)和推廣以及技術白皮書撰寫。其中ddframe的分布式作業(yè)部分elastic-job已經正式開源。

CSDN:請簡單介紹下您和目前的工作,以及說說您自己曾經的計算機經歷?

張亮:我目前在當當架構部任職,主要的工作是ddframe的設計、開發(fā)和推廣;技術白皮書撰寫;重點項目的跟進支持,如:TMS,WMS重構;還有一些零散的技術調研工作,如,消息中間件,日志中心,圖數(shù)據庫等。

職業(yè)生涯初期我在外企工作。外企對技術人員要求更多的是設計,規(guī)范和對業(yè)務的理解能力。一般外企都有成型的技術組織架構,相對較重。流程規(guī)范但缺乏靈活性,對新技術使用非常謹慎。我本人更喜歡技術本身,所以于三年前加入互聯(lián)網行業(yè)。在我看來,靈活性、高性能、輕量級、分布式、高可用是互聯(lián)網企業(yè)更關注的東西。

CSDN:當當有自己架構部,并設有架構師一職,作為其中的一員,能夠談談什么是架構?什么是架構師?

張亮:架構種類很多,從公司宏觀看,可分為業(yè)務架構,數(shù)據架構,技術架構,運維架構;微觀看,每個系統(tǒng)都會有自己的應用架構。既然架構的種類很多,那么架構師的種類就更多,共同點是架構師一般都會以更高的視點關注一些通用的東西,或者在從無到有的演進中規(guī)劃合理的藍圖。

CSDN:架構師的工作是什么?又該有著怎樣的素養(yǎng)?

張亮:架構師的主要工作是提供面向抽象的較高層級解決方案,而非面向具體業(yè)務,對細節(jié)點進行處理。拿我們公司舉例,主要是劃分系統(tǒng)邊界,設計系統(tǒng)交互路徑,規(guī)劃底層框架,規(guī)范開發(fā)流程等。

架構師對素質的要求比較均衡,不能有短板。前瞻性和領悟力,將決定系統(tǒng)是否符合潮流,便于演進。如何時實行SOA,何時推進微服務等;對業(yè)務的理解將決定系統(tǒng)能否貼近公司實情;對技術的理解力和闡述力將直接影響系統(tǒng)的設計;協(xié)調力和溝通力將影響系統(tǒng)的開發(fā)和實施,畢竟任何系統(tǒng)都不能由個人完成。

CSDN:當當在今年9月份開源了分布式作業(yè)調度框架elastic-job,能夠簡單介紹下它是什么、來歷、架構設計思路等?和ddframe是怎樣的關系?以及該項目的團隊情況?

張亮:elastic-job原本是當當java應用框架ddframe的一部分,本名dd-job。ddframe包括編碼規(guī)范,開發(fā)框架,技術規(guī)范,監(jiān)控以及分布式組件。ddframe規(guī)劃分為4個演進階段,目前處于第2階段。3、4階段涉及的技術組件不代表當當沒有使用,只是ddframe還未統(tǒng)一規(guī)劃。

ddframe由各種模塊組成,均已dd-開頭,如dd-container、dd-soa、dd-rdb、dd-job等。當當希望將ddframe的各個模塊與公司環(huán)境解耦并開源以反饋社區(qū)。之前開源的Dubbo擴展版本DubboX即是dd-soa的核心模塊。而本次介紹的elastic-job則是dd-job的開源部分,其中監(jiān)控(但開源了監(jiān)控方法)和ddframe核心接入等部分并未開源。

elastic-job主要的設計理念是無中心化的分布式定時調度框架,思路來源于Quartz的基于數(shù)據庫的高可用方案。但數(shù)據庫畢竟沒有分布式協(xié)調功能,所以在高可用方案的基礎上增加了彈性擴容和數(shù)據分片的思路,以便于更大限度的利用分布式服務器的資源。

團隊目前由3個部分組成,第一部分是開發(fā)團隊,由架構部的架構師曹昊、高洪濤和我組成,主要負責設計和編碼;第二部分是來自于各個研發(fā)團隊的應用架構師、開發(fā)工程師和架構部總監(jiān)史海峰,他們負責推廣落地,整理需求并貢獻當當已經存在的最佳實踐代碼;第三部分由架構部性能測試團隊組成,負責框架的性能和穩(wěn)定性測試。

另,如果你精通Java,并具備大型項目、復雜系統(tǒng)架構經驗,歡迎加入當當架構部,簡歷發(fā)送郵箱:shihaifeng@dangdang.com

CSDN:能不能和我們詳細的介紹下elastic-job具體模塊的底層及如何實現(xiàn)以及它們的作用?

張亮:elastic-job的主要分為注冊中心、數(shù)據分片、分布式協(xié)調,定時任務處理和多作業(yè)模式等模塊。

注冊中心模塊目前直接使用Zookeeper,用于記錄作業(yè)的配置,服務器信息以及作業(yè)運行狀態(tài)。Zookeeper雖然很成熟,但原理復雜,使用較難,在海量數(shù)據支持的情況下也會有性能和網絡問題。目前elastic-job已經抽象出注冊中心的接口,下一步將會考慮支持多注冊中心,如etcd,或由用戶自行實現(xiàn)注冊中心。無臨時節(jié)點和監(jiān)聽機制的注冊中心需要自行實現(xiàn)定時心跳監(jiān)測等功能。

數(shù)據分片是elastic-job中實現(xiàn)分布式的重要概念,將真實數(shù)據和邏輯分片對應,用于解耦作業(yè)框架和數(shù)據的關系。作業(yè)框架只負責將分片合理的分配給相關的作業(yè)服務器,而作業(yè)服務器需要根據所分配的分片匹配數(shù)據進行處理。服務器分片目前都存儲在注冊中心中,各個服務器根據自己的IP地址拉取分片。

分布式協(xié)調模塊用于處理作業(yè)服務器的動態(tài)擴容縮容。一旦集群中有服務器發(fā)生變化,分布式協(xié)調將自動監(jiān)測并將變化結果通知給各個仍存活的作業(yè)服務器。協(xié)調時將會涉及主節(jié)點選舉,重分片等操作。目前使用的Zookeeper的臨時節(jié)點和監(jiān)聽器實現(xiàn)主動檢查和通知功能。

定時任務處理根據cron表達式定時觸發(fā)任務,目前有防止任務同時觸發(fā),錯過任務重出發(fā)等功能。主要還是使用Quartz本身的定時調度功能,為了便于控制,每個任務都使用獨立的線程池。

多作業(yè)模式將定時任務分為多種流程,有不經任何修飾的簡單任務;有用于處理數(shù)據的fetchData/processData的數(shù)據流任務;以后還將增加消息流任務,文件任務,工作流任務等。用戶能以插件的形式擴展并貢獻代碼。

CSDN:elastic-job是分布式作業(yè)調度框架,何為分布式作業(yè)?以及為什么需要作業(yè)?

張亮:作業(yè)即定時任務。一般來說,系統(tǒng)可使用消息傳遞代替部分使用作業(yè)的場景。兩者確有相似之處??苫ハ嗵鎿Q的場景,如隊列表。將待處理的數(shù)據放入隊列表,然后使用頻率極短的定時任務拉取隊列表的數(shù)據并處理。這種情況使用消息中間件的推送模式可更好的處理實時性數(shù)據。而且基于數(shù)據庫的消息存儲吞吐量遠遠小于基于文件的順序追加消息存儲。

但在某些場景下則不能互換:

  1. 時間驅動 OR 事件驅動:內部系統(tǒng)一般可以通過事件來驅動,但涉及到外部系統(tǒng),則只能使用時間驅動。如:抓取外部系統(tǒng)價格。每小時抓取,由于是外部系統(tǒng),不能像內部系統(tǒng)一樣發(fā)送事件觸發(fā)事件。
  2. 批量處理 OR 逐條處理:批量處理堆積的數(shù)據更加高效,在不需要實時性的情況下比消息中間件更有優(yōu)勢。而且有的業(yè)務邏輯只能批量處理,如:電商公司與快遞公司結算,一個月結算一次,并且根據送貨的數(shù)量有提成。比如,當月送貨超過1000則額外給快遞公司多1%的快遞費。
  3. 非實時性 OR 實時性:雖然消息中間件可以做到實時處理數(shù)據,但有的情況并不需要。如:VIP用戶降級,如果超過1年無購買行為,則自動降級。這類需求沒有強烈的時間要求,不需要按照時間精確的降級VIP用戶。

系統(tǒng)內部 OR 系統(tǒng)解耦。作業(yè)一般封裝在系統(tǒng)內部,而消息中間件可用于系統(tǒng)間解耦。

CSDN:elastic-job的主要功能有哪些以及目前的部署和使用情況如何?可否用具體數(shù)據來說明。

張亮:

  1. 分布式:重寫Quartz基于數(shù)據庫的分布式功能,改用Zookeeper實現(xiàn)注冊中心。
  2. 并行調度:采用任務分片方式實現(xiàn)。將一個任務拆分為n個獨立的任務項,由分布式的服務器并行執(zhí)行各自分配到的分片項。
  3. 彈性擴容縮容:將任務拆分為n個任務項后,各個服務器分別執(zhí)行各自分配到的任務項。一旦有新的服務器加入集群,或現(xiàn)有服務器下線,elastic-job將在保留本次任務執(zhí)行不變的情況下,下次任務開始前觸發(fā)任務重分片。
  4. 集中管理:采用基于Zookeeper的注冊中心,集中管理和協(xié)調分布式作業(yè)的狀態(tài),分配和監(jiān)聽。外部系統(tǒng)可直接根據Zookeeper的數(shù)據管理和監(jiān)控elastic-job。
  5. 定制化流程型任務:作業(yè)可分為簡單和數(shù)據流處理兩種模式,數(shù)據流又分為高吞吐處理模式和順序性處理模式,其中高吞吐處理模式可以開啟足夠多的線程快速的處理數(shù)據,而順序性處理模式將每個分片項分配到一個獨立線程,用于保證同一分片的順序性,這點類似于kafka的分區(qū)順序性。
  1. 失效轉移:彈性擴容縮容在下次作業(yè)運行前重分片,但本次作業(yè)執(zhí)行的過程中,下線的服務器所分配的作業(yè)將不會重新被分配。失效轉移功能可以在本次作業(yè)運行中用空閑服務器抓取孤兒作業(yè)分片執(zhí)行。同樣失效轉移功能也會犧牲部分性能。
  2. Spring命名空間支持:elastic-job可以不依賴于spring直接運行,但是也提供了自定義的命名空間方便與spring集成。
  3. 運維平臺:提供web控制臺用于管理作業(yè)。
  1. 穩(wěn)定性:在服務器無波動的情況下,并不會重新分片;即使服務器有波動,下次分片的結果也會根據服務器IP和作業(yè)名稱哈希值算出穩(wěn)定的分片順序,盡量不做大的變動。
  2. 高性能:同一服務器的批量數(shù)據處理采用自動切割并多線程并行處理。
  3. 靈活性:所有在功能和性能之間的權衡,都可通過配置開啟/關閉。如:elastic-job會將作業(yè)運行狀態(tài)的必要信息更新到注冊中心。如果作業(yè)執(zhí)行頻度很高,會造成大量Zookeeper寫操作,而分布式Zookeeper同步數(shù)據可能引起網絡風暴。因此為了考慮性能問題,可以犧牲一些功能,而換取性能的提升。
  4. 冪等性:elastic-job可犧牲部分性能用以保證同一分片項不會同時在兩個服務器上運行。
  5. 容錯性:作業(yè)服務器和Zookeeper斷開連接則立即停止作業(yè)運行,用于防止分片已經重新分配,而腦裂的服務器仍在繼續(xù)執(zhí)行,導致重復執(zhí)行。

Elastic-job在當當內部也是剛剛進行推廣,目前支付系統(tǒng)、訂單系統(tǒng)、發(fā)票系統(tǒng)、促銷系統(tǒng)都有使用,快遞系統(tǒng)和倉儲系統(tǒng)也即將使用。開源后也得知不少公司有使用計劃。

CSDN:對該開源項目的未來有什么期待?

張亮:elastic-job的開源主要是為了反饋社區(qū)。開源短短兩個月,我們收到了很多朋友的反饋和支持,非常感謝。目前的elastic-job定位是一個基于Java的定時任務調度框架,未來想發(fā)展成為支持異構語言,高度靈活,可自定制的定時任務調度產品。

未來的展望主要包括幾個方面:

  1. 異構語言支持。目前采用的無中心設計,難于支持多語言,考慮調度中心的可行性。
  2. 完善監(jiān)控體系。增加監(jiān)控維度,metrics統(tǒng)計,全量歷史數(shù)據對接輸出等。
  3. 更多作業(yè)類型和分片策略的支持。

CSDN:最后,能否就開源產品談下你的開發(fā)理念?

張亮:技術類開源項目和一般的業(yè)務型項目不同,更需要對代碼和質量的控制,我們總結出以下幾點:

  1. 用心寫代碼,用代碼講故事。代碼是項目的唯一核心和產出,任何一行的代碼都需要用心思考優(yōu)雅性,可讀性,合理性。
  2. 代碼整潔干凈到極致。簡單點說就是重度代碼潔癖患者。只有代碼漂亮整潔,其他開源愛好者才愿意閱讀代碼,進而找出項目中的bug和貢獻高質量代碼。
  3. 極簡代碼, 高度復用,無重復代碼和配置。Java生態(tài)圈的特點是高質量的開源產品極多。我們盡量考慮復用輪子,比如項目中大量用到lombok簡化代碼;但也不會無原則的使用開源產品,我們傾向于把開源產品分為積木類和大廈類。項目中一般只考慮使用積木類搭建屬于我們自己的大廈,而不會直接用其他已成型的大廈。
  4. 單一需求可不考慮擴展性;兩個類似需求時再提煉。
  5. 模塊抽象劃分合理。
  6. 如無特殊理由, 測試需全覆蓋。elastic-job核心模塊的測試覆蓋率是95%以上。雖然單元測試覆蓋率在分布式的復雜環(huán)境中并無太大說服力,但至少證明項目中很少出現(xiàn)低級邏輯錯誤。
  7. 對質量的定義。代碼可讀性 > 代碼可測性 > 模塊解耦設計 > 功能正確性 > 性能 > 功能可擴展性。只有代碼可讀,可測試,可100%掌控,項目才可持續(xù)發(fā)展。功能有缺陷可以修復,性能不夠可以優(yōu)化,而代碼不清晰則項目會漸漸變?yōu)楹诤?。所以對于框架類產品,我們認為質量 > 時間 > 成本。
  8. 文檔清晰。

(責編/錢曙光,關注架構和算法領域,尋求報道或者投稿請發(fā)郵件qianshg@csdn.net,交流探討可加微信qshuguang2008,備注姓名+公司+職位)

友情提醒:當當分布式作業(yè)框架elastic-job還入選了2015TOP100Summit全球軟件案例,而且2015TOP100Summit全球軟件案研究峰會將于2015年12月5日-7日在北京國家會議中心舉行,屆時會有更多的精彩演講,敬請關注。

本站僅提供存儲服務,所有內容均由用戶發(fā)布,如發(fā)現(xiàn)有害或侵權內容,請點擊舉報
打開APP,閱讀全文并永久保存 查看更多類似文章
猜你喜歡
類似文章
Elastic-Job 簡介
聊聊分布式定時任務中間件架構及其實現(xiàn)
elasticJob
大數(shù)據“分布式調度框架”大集合
分布式定時任務——elastic-job
分布式定時任務調度平臺Elastic-Job技術詳解
更多類似文章 >>
生活服務
熱點新聞
分享 收藏 導長圖 關注 下載文章
綁定賬號成功
后續(xù)可登錄賬號暢享VIP特權!
如果VIP功能使用有故障,
可點擊這里聯(lián)系客服!

聯(lián)系客服