序:StreamId是storm中实现DAG有向无环图的重要一个特性,但是从实际生产环境来看，这个功能其实蛮影响生产环境的稳定性的，我们系统在迭代时会带来整体服务的不可用。
StreamId是storm中实现DAG有向无环图的重要一个特性，官方也提供对应的接口实现让开发者自己灵活化构造自己的ADG图。但是从我这一年从事流式计算的工作中以及从我的200人大数据圈子（最低从事大数据行业2年）得到的结果也很尴尬的，很多人不知道storm的这一个特性。当然这也比较幸运，不知道这个特性就可以少踩点坑了。因为从实际生产环境来看，这个功能其实蛮影响生产环境的稳定性的，为什么这么说，hey,hey,look dowm。
实际开发中，很多人没有用streamid,其实只是没有显示指定罢了，默认streamid的名称为default，这也就是为什么消息可以由一个bolt发往另一个bolt了。我们自己显示指定streamid可以实现进入某一个bolt的消息，某些消息发给下游的Abolt，另一些消息发给下游的Bbolt。
比如有这样一个需求砸向你的脸上，有很多其他系统的消息发送到kafka某一个主题中，现在用storm去kafka消费该主题，在bolt-业务这个节点进行消息类型的判断，然后根据判断将消息发送到不同的下游bolt进行处理以便将这些消息发往不同的渠道接口中。这样一个需求我们利用streamid很容易实现，看起来也没有什么问题。关于sreamid的使用稍后可以看我的下一篇文章或者自行百度资源。
为什么在实际生产我不建议这样使用，生产中经常会面对迭代开发的情况，业务不断的变化，你的代码也要不断的修改，第三方接口的变动，你也要不断的修改与第三方交互的程序。如果这周要修改bolt-微信，然后到发布的时候，你必须停掉整个拓扑任务这明显不是我们想要的，我们期望的是只停掉bolt-微信而不影响其他的业务线。这个时候就会发现这个实现方式很鸡肋的。那我们应该怎么做，看一下我在某信用卡中心的实现方案，看了后，你会替我庆幸我没有为了图前期的简单而采用显示streamid导致后面每该一处很小的功能导致整个拓扑任务不提供服务一段时间。
我们的系统会收到交易信息，然后根据业务bolt进行处理，然后形成话术推送给不同的渠道bolt,这些渠道bolt对接各个部门（这些部门接受到我们的话术后，将话术推送给微信用户，支付宝用户等），而我们的对外渠道多大15个左右。同时应为业务的不断提出，以及对接部门接口的变化我们这些渠道bolt也要跟随变化。所以我们在业务bolt和渠道bolt中引入了第三方消息系统kafka队列，而不是用storm内部的Disruptor队列。这样原本一个拓扑任务，我们进行拆分为一个业务拓扑，以及多个其渠道拓扑，渠道拓扑与业务拓扑通信通过kafka的主题来协调。如果某一天我们要修改微信渠道的业务，我们只需要停掉微信拓扑即可，整个系统并不会受到影响，原本推送给微信渠道的消息也不会因此丢失它保存在kafka主题中，一旦微信拓扑上线即可立马消费掉。
后话，我这样说有点绝对了，具体看系统的情况来权衡。