lanlin
关于事件驱动及实时消息的思考，分布式消息订阅发布
背景
程序员普遍面临这样的场景，随着项目规模的增大，交互的复杂越高，开发难度也越来越大。架构问题越来越尖锐，为了解决各种耦合性和灵活性等等的问题，大家想出了各种各样的招数。什么模块化，微服务之类的也随之诞生。
总之，我们既希望某些东西是分散（甚至是分布的）的，又希望以统一的方式来组织起他们运行。从字面上看，模块化以及微服务是做到了分散的问题，貌似缺乏统一协调的解决办法。
从实际的应用来看，貌似也是这个样子，大家在分散这一块的理解和做法很多地方都很相似（比如切分成模块，切分成微服务等等）。但在统一协调方面的处理方式就千差万别了。比如可能通过各自模块的接口来直接相互调用，比如架设一层专门的控制层来编排调用逻辑，比如直接由客户端自己来调用和组织交互等等。也许我理解和学习不到位，反正看到的这些情况很多。
但是，我们往往会遇到一些这样的情况，在某些关键节点之后，我们需要对不确定的服务或模块进行调用。或者叫做通知更恰当。
比如，当一个用户完成注册后，下一步可能会进行一系列的数据初始化，而这些操作可能是分散在不同的模块或者服务中的，以及某些可能会在以后开发和扩展的模块或者服务中。这个时候如何保证后续调用的一致性，以及不会来回折腾和补充呢？
我由此想到了事件驱动这个东西，但是现在的项目，往往动不动就是云啊，分布啊之类的。所以事件的总线一定需要单独存在，单独维护，因此像很多框架本身自带的事件管理是无法满足这个需求的。
方案
基于以上的一些思考，找到了两个东西能够满足。
以上两个东西都有很多大厂实际验证了其可行性和可靠性。
其他
事件驱动好像逐渐走俏，连带的消息订阅发布的玩法也逐渐推陈出新。 基于对 “解耦” 的追求，我还是备忘一下，需要进一步研究一下，这两个玩意，看能得否。
