# 在生產集群上運行 Topology 在生產集群上運行 Topology 類似于在 [本地模式](Local-mode.html) 下運行.以下是步驟： 1）定義 Topology （如果使用 Java 定義, 則使用 [TopologyBuilder](javadocs/org/apache/storm/topology/TopologyBuilder.html) ） 2）使用 [StormSubmitter](javadocs/org/apache/storm/StormSubmitter.html) 將 topology 提交到集群. `StormSubmitter` 以 topology 的名稱, topology 的配置和 topology 本身作為輸入.例如： ``` Config conf = new Config(); conf.setNumWorkers(20); conf.setMaxSpoutPending(5000); StormSubmitter.submitTopology("mytopology", conf, topology); ``` 3）創建一個包含你的代碼和代碼的所有依賴項的 jar （除了 Storm - Storm jar 將被添加到 worker 節點上的 classpath 中）. 如果您使用 Maven, [Maven Assembly Plugin](http://maven.apache.org/plugins/maven-assembly-plugin/) 插件可以為您做包裝.只需將其添加到您的 pom.xml 中即可： ``` <plugin> <artifactId>maven-assembly-plugin</artifactId> <configuration> <descriptorRefs> <descriptorRef>jar-with-dependencies</descriptorRef> </descriptorRefs> <archive> <manifest> <mainClass>com.path.to.main.Class</mainClass> </manifest> </archive> </configuration> </plugin> ``` 然后運行 mvn assembly:assembly 來獲取適當打包的 jar. 確保您 [排除了](http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/including-and-excluding-artifacts.html) Storm jar, 因為群集已經在類路徑上有 Storm. 4）使用 `storm` 客戶端將 topology 提交到集群, 指定您的 jar 的路徑, 要運行的類名以及將使用的任何參數: `storm jar path/to/allmycode.jar org.me.MyTopology arg1 arg2 arg3` `storm jar` 將 jar 提交到集群并配置 `StormSubmitter` 該類與正確的集群進行通信.在這個例子中, 上傳 jar 后 `storm jar` , `org.me.MyTopology` 使用參數 "arg1", "arg2", and "arg3" 調用 main 函數. 您可以找到如何配置 `storm` 客戶端與 Storm 集群進行交流, 以 [設置開發環境](Setting-up-development-environment.html). ### 常用配置 您可以根據 topology 設置各種配置.您可以在 [這里](javadocs/org/apache/storm/Config.html) 找到您可以設置的所有配置的列表. 以 "TOPOLOGY" 為前綴的可以在 topology 特定的基礎上被覆蓋（其他的是集群配置, 不能被覆蓋）. 以下是為 topology 設置的一些常見的: 1. **Config.TOPOLOGY_WORKERS**: 設置用于執行 topology 的 worker 進程數. 例如, 如果將其設置為25, 則集群中將有25個 Java 進程執行所有任務. 如果 topology 中的所有組件都具有150個并行度, 則每個 worker 進程將在其中運行6個任務作為線程. 2. **Config.TOPOLOGY_ACKER_EXECUTORS**: 這將設置跟蹤元組樹 executor 的數量, 并檢測出 spout 元組何時完全處理. Ackers 是 Storm 可靠性模型的組成部分, 您可以在 [保證消息處理](Guaranteeing-message-processing.html) 中閱讀更多信息. 通過不設置此變量或將其設置為 null, Storm 將 executor 的數量設置為等于為此 topology 配置的 worker 數. 如果這個變量設置為0, 那么 Storm 會立即從元器件脫落出來, 使其可靠性降低. 3. **Config.TOPOLOGY_MAX_SPOUT_PENDING**: 這將一次設置單個 spout 任務中可以掛起的 spout 元組的最大數量（掛起意味著元組尚未被確認或失敗）. 強烈建議您設置此配置以防止隊列爆炸. 4. **Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS**: 這是一個 spout 元組在被認為失敗之前必須完全完成的最長時間. 此值默認為30秒, 這對大多數拓撲結構都是足夠的. 有關 Storm 的可靠性模型如何工作的更多信息, 請參閱 [保證消息處理](Guaranteeing-message-processing.html). 5. **Config.TOPOLOGY_SERIALIZATIONS**: 您可以使用此配置向 Storm 注冊更多序列化程序, 以便您可以在元組內使用自定義類型. ### Killing 一個 topology 要 kill 一個 topology, 只需運行: `storm kill {stormname}` 提供與 `storm kill` 提交 topology 時使用的名稱相同的名稱. Storm不會立即殺死 topology. 相反, 它會停用所有的端口, 以使它們不再發出任何元組, 然后 Storm 會在銷毀 所有 workers 之前等待 Config. TOPOLOGY_MESSAGE_TIMEOUT_SECS 秒.這給了 topology 足夠的時間來完成它被殺死時處理的任何元組. ### Updating 一個正在運行的 topology 要更新正在運行的 topology, 目前唯一的選項是終止當前 topology 并重新提交新的 topology. 一個計劃的功能是實現一個 `storm swap` 交換正在運行的 topology 結構的命令, 以確保最短的停機時間, 并且兩個 topology 不會同時處理元組. ### Monitoring topologies 監控 topology 的最佳位置是使用 Storm UI. Storm UI 提供有關每個運行 topology 的每個組件的吞吐量和延遲性能的任務和精細統計信息中發生的錯誤的信息. 您還可以查看群集機器上的 worker 日志.