在2017年線上技術峰會——阿裡開源項目最佳實踐上，來自阿裡巴巴中間件的技術專家衛樂分享了jstorm開源最佳實踐。他主要介紹了jstorm的架構，從性能、穩定性、監控系統、大規模部署、反壓、灰階釋出&熱更新、exactly-once、新的視窗機制等方面詳細扥想了jstorm做的優化。以下内容根據直播視訊整理而成。
<b></b>
jstorm從2013年開始開發，曆經了25個版本。從2014年“雙十一”開始，做了管控平台，包括排程、使用者自定義日志等特征。2015年的“雙十一”，對排程進行了優化，并且增加了反壓功能，重新設計了topology master。2016年，除了性能優化之外，還提供了exactly once，包括把社群的sliding window和shade dependency等特性都移植到jstorm，此外還提供了很多新的feature，如重構的視窗機制，灰階釋出等。
jstorm在阿裡集團、螞蟻、優酷、洋芋、高德都使用非常廣泛。有三種部署方式：standalone、jstorm-on-yarn、jstorm-on-docker（主推，可以一鍵部署，擴容縮容友善）。
jstorm已經不是簡單的實時計算了，其應用在很多場景：
反欺詐：nut/velocity；
審計：阿裡媽媽廣告/p4p，amg；
資料統計分析：eagleeye，ae，bi；
監控：tlog（阿裡内部監控），rds-monitor（sql監控），oceanbase-monitor（sql監控）, cainiao radar, yunosmonitor；
資料同步：rds-log-sync, unify-log；
實時推薦：alipay 1315, alipay hyperloop, tpp；
應用排程：ae郵件實時分析，網銷寶。
jstorm的整體架構如上圖所示。最下方是部署模式，jstorm core是jstorm計算架構本身，其上是raw storm api（此接口相對底層）、exactly once、extension api。其上是集團内部廣泛使用的plugin，sql engine上是應用。最右邊是管控平台koala。
上圖是去年jstorm 2.2.0和storm 1.0.2的性能對比圖。硬體是32cpu core/128g實體機，每個worker是6g記憶體。從圖中可以看到在不同的worker已經不同的并發下，jstorm至少是storm兩倍以上的性能。那麼，如何進行的性能優化？
性能優化在現代的流處理領域廣泛認可的一種方式是做batch，batch對性能優化的影響是非常大的。batch是将消息打包，從上遊接收一些消息，處理完後進行batch再往下發，能夠節省很多資源，提高性能。在此基礎上進行了路徑優化，即對jstorm做了jvm層面的profile，檢測架構的hot function部分（調用比較多的部分），進行針對性優化。雖然對jstorm進行了重構metrics體系，但是底層的metrics core庫并沒有優化，是以對meter，histogram等進行了優化。此外，在序列化方面，對常用的序列化都進行了調優。
在穩定性方面，做了以下優化：
多叢集部署方面，由于涉及到異地多機房、同城多機房等問題，是以同城方面使用了zk做多機房的容災，jstorm自動把這些作業調到别的機房，隻要保證别的機房的worker量可以支撐作業量就不會出現問題。跨城情況相對複雜，成本也比較高，在阿裡使用多鍊路來解決，即在多城市部署一模一樣的叢集消費同一份資料，在輸出上做一些災備，輸出到不同的異構資料輸出中，這樣任意一條鍊路挂掉就能實時切換。
隔離方面，standalone提供了天然的隔離性，因為docker本身用cgroup做資源隔離，是以jstorm-on-docker的隔離也相對簡單。jstorm-on-yarn是在yarn上的container中開啟cgroup來做隔離。
ha方面，jstorm的ha是很早的特性，非常穩定。節點自檢是checkhealth，用于檢查supervsior。腳本會在supervsior壓力過大或者記憶體快滿的情況下自動調整可用worker數（降低）。
監控方面，jstorm的自定義metrics重新實作，管控平台koala內建了監控報警。tuple life style能夠根據節點間花費的時間得知拓撲結構中比較慢的環節。
更新/降級方面，降級即jstorm的反壓，更新即熱部署和灰階釋出。
jstorm的監控系統如上圖所示，重新設計的監控系統的優點在于自動聚合的功能。從下往上，一個task有多個stream，task往上是component，再往上是topology，再往上是cluster。重新設計後的優點在于可以統計所有級别的metrics，展現完整的曆史曲線，而不是單點的資料。
上圖是metrics整個分級彙總的實作。具體可見github源碼中最新的metrics設計文檔。
在沒有topology master的情況下，所有的task彙報心跳、發送metrics的時候都需要寫zk，并且storm是把metrics直接zk裡面，這樣zk的壓力更大。有了topology master之後，topology master是task的總節點，task彙報心跳的時候隻需要向task彙報心跳，topology master彙總後再發送給nimbus或者zk，這樣會使zk的壓力縮到拓撲的量級。
storm的反壓，比如bolt處理消息來不及的情況下會向zk寫一個節點進行反壓，監聽bolt上遊的節點停止發送資料直到下遊的bolt能夠正常處理。這樣的問題是資料可能出現驟降的過程，并且反壓結束資料流下來之後容易導緻新一次的反壓，進而導緻tps會一直抖動。
jstorm做了兩級的反壓，第一級和jstorm類似，通過執行隊列來監測，但是不會通過zk來協調，而是通過topology master來協調。在隊列中會标記high water mark和low water mark，當執行隊列超過high water mark時，就認為bolt來不及處理，則向tm發一條控制消息，上遊開始減慢發送速率，直到下遊低于low water mark時解除反壓。此外，在netty層也做了一級反壓，由于每個worker task都有自己的發送和接收的緩沖區，可以對緩沖區設定限額、控制大小，如果spout資料量特别大，緩沖區填滿會導緻下遊bolt的接收緩沖區填滿，造成了反壓。
一個規模很大的拓撲，以前的更新需要先把拓撲kill掉，修改代碼、重新打包、重新送出，導緻應用會有短暫的時間不能使用。此外，有時候隻想更新部分的worker，不想重新開機整個拓撲。灰階釋出和熱更新是做worker内部的重新開機，但是不會kil拓撲。
在jstorm中，exactly-once是通過topology master來做協調的。jstorm中的exactly-once并不像以前那樣每發一條消息一次。spout發一個batch，會有一個batch id，并且立馬發一個checkpoint barrier（控制消息），tm會得知發了一條新的batch，tm會把offset記錄下來。bolt分為兩種，一種是stateless bolt，一種是stateful bolt。stateless bolt比較簡單，就是正常處理，繼續往下遊bolt發。stateful bolt則需要把狀态存起來，把checkpoint發送給topology master，直到ending bolt向tm發送checkpoint barrier。當所有的ending bolt都做完checkpoint後，就會将狀态存在hdfs/hbase中，再通知spout發送下一個batch。
實際上，每一個batch的處理和發送是可以并行的，隻是tm本身的checkpoint是串行的，這樣就可以很好的提高性能。比如中間有一個batch處理失敗了，tm會得知，此時就會做rollback，向spout發送rollback barrier，從hdfs/hbase中找出最近完成的checkpoint，删除曆史無用的checkpoint，spout會從狀态中重新恢複offset，stateless bolt會繼續處理，stateful bolt會把checkpoint所對應的狀态從hdfs/hbase中拉出來恢複，再根據資料計算。
其他的特性包括自定義排程、動态調整日志級别、自定義日志（外部應用可以很友善做日志采集、基于日志的監控報警）、使用者自定義metrics（根據業務日志做監控報警）、優雅shutdown（把所有的消息處理完之後再shutdown）、動态擴容、更新配置。
storm的window有很多問題，所有的資料需要統一處理，在工業級的産品中不可行。重構的視窗機制不會在記憶體憋每個視窗的資料，隻需要存每個視窗的處理結果。重構的視窗機制，支援processing time、ingestion time、event time、watermark (late element)、window early fire。
apache beam提供了一次編寫、多個不同引擎到處運作的特性。jstorm也會适配beam，做apache beam jstorm runner。jstorm sql需要進行重構和優化。将來計劃在jstorm上封裝一些算子、整合架構，使其易于開發、調試，性能更加優化。