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

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

还记得第一次跟师傅打交道，他问我“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