分布式单体架构

当我们需要设计一套在线课程发布和订阅系统（以下简称“在线课程”系统）时，传统做法就是采用早已烂熟的逻辑三层架构：用户界面层、业务逻辑层和数据访问层，如果遵循领域驱动设计（DDD）的经典分层架构，基本上也就是四层：表现层、应用层、业务层以及基础结构层。在系统刚刚开始发布上线的时候，用户量和每日请求量并不是特别大，所以我们可以将来自于各个层的组件全部部署在一台物理机器上，因此，层（Layers，逻辑层）与层（Tiers，物理层）之间并非是一对一的关系。当然，也有可能会将用户界面层、业务逻辑层以及数据访问层分别部署在不同的物理机器上，实现层（Layer）与层（Tier）的一一对应，从而一定程度上减轻单台物理机器的负载。多年来，这种架构形式被反复地实现、反复地验证，并且反复地、成功地被应用在很多生产环境中。在绝大多数情况下，大家并不觉得这样的架构形式有什么问题，只要设计合理，比如通过引入依赖注入框架、面向方面编程等技术，各个层之间可以完全做到解耦，实现热插拔式的功能升级和替换也不是什么难事。其实，这种架构形式还是有很多优点的：

1. 结构简单，容易理解：对于开发人员而言，这是非常重要的一点。经典的分层架构已经相对比较成熟，更容易被更多的开发人员所理解和接受，学习成本也相对比较低，对团队本身的要求也不是特别高。这不仅使得系统的设计和开发都相对比较容易，而且出错的几率会相对低一些。用现在时髦的词语说，就是“坑相对较少”，开发实现都可以“踩在踩坑人的背上前进”
2. 实现数据一致性相对比较容易，通过本地事务或者分布式事务可以方便有效地保证数据一致性
3. 部署简单方便：比如这里的在线课程系统，可以方便快速地打包成WAR包，部署到Jetty或者Tomcat容器中，也可以是一个部署在IIS中的.NET解决方案。无论哪种，一次部署完成即可运行整个应用程序
4. 持续集成策略的设计相对容易：基本上团队可以根据项目的实际情况很容易地设计出持续集成方案，很多情况下，整套解决方案会放在同一个代码库中，根据持续集成策略，项目的持续交付也不会有太大压力

总结起来，这种架构大致可以使用下图表示，各层组件可以通过相互引用进行相互调用，也可以通过IoC/DI实现解耦，进而实现应用程序“一体化”，这也是“单体架构”一词的由来：