基于消息传递的软件架构模型演变

一个优秀的架构师总是能对各种解决方案的优点和对应成本之间取得良好的平衡，而这种能力背后是架构师丰富的经验和广阔的知识体系。基于消息的软件建构模型则是架构师必备的知识点，本文将详细描述该模型的演变过程。

还记得第一次跟师傅打交道，他问我“Hi yang，你的功能设计的怎么样了？”我有点不以为然，不就是个很小的功能么，为什么要用“设计”一词，为什么不是“你的代码写的怎么样了？”。我后来明白了，“设计”一词代表了他对软件的态度，在他眼中任何功能都应该是设计出来的，没有经过设计的代码如同流水帐一样，只能应付眼前，久而久之代码变得不可扩展和维护。本文会随着架构模型的演变过程，对同一个需求进行不断设计和演变，最终成型。

 

本系列文章包含以下内容：

• 三种观察者模式的C#实现——在代码层面实现观察者模式
• .net中事件引起的内存泄漏分析——理解为何要使用弱引用来实现EventBus
• 响应式编程(Reactive programming)——观察者模型的函数式实现
• EventAggregator, EventBus的实现——对MVVM light中EventBus代码分析
• 使用Akka.net开发第一个分布式应用——使用基于Actor模型的框架开发分布式应用
• 企业服务总线(ESB)-EventBus的进一步抽象——使用NServiceBus构建高伸缩性，低耦合的分布式应用

 

看了这个目录，也许有人会有疑问，为什么前三条都是在说观察者模式和事件，这跟基于消息的架构有什么关系？

            var watcher = new FileSystemWatcher();
            watcher.Created += (object sender, FileSystemEventArgs e) =>
            {
                MessageBox.Show(string.Format("I am interesting in fileName={0} and path={1} which was created", e.Name,e.FullPath));
            };

这是一段使用事件的代码，.Net中的事件模型是一个观察者模式，这段代码可以描述为：观察者(observer)-匿名lambda函数观察了一个主题(subject)Created。每当有文件被创建的时候watcher会遍历所有的观察者并将主题的数据通知给观察者。

而消息则是观察者模式的进一步抽象。主题（subject)中的FileSystemEventArgs中包含有我们感兴趣的信息，我们可以将FileSystemEventArgs理解为消息，当FileSystemWatcher发现有新文件被创建时发送一个类型为FileSystemEventArgs的消息即可，不同的组件可以订阅这个消息获得被创建文件的名称和路径等信息。当FileSystemEventArgs能够序列化并且可以在网络上传输时，不同的子系统都可以订阅这个消息，最终演变为一个分布式系统。

最终架构图如下：

各子系统将自己的消息发送到ESB上，同时订阅其他系统中感兴趣的消息。各子系统不再直接相互依赖，后期有新的系统直接接入ESB即可。整个架构最终演变为松耦合，高伸缩性的分布式系统。

 

整个系列的代码地址：https://git.oschina.net/richieyangs/EventArchitecture