Azure 软件架构选择

1. 传统的分层结构+message broker + worker
传统的层结构老生常谈了： UI 层，service，业务逻辑，数据层。就不赘述了
与worker形成producer-consumer模式，可*控制worker的数量
业务上异步
使用不同队列管理不同业务请求，业务上可横向扩展

优势： 开发效率比较高，业务和应用扩展性都还可以。
劣势： 运维监控以及上线部署流程不适用于互联网应用。
适用： 中小型项目，大型项目如果不对业务分离部署也可考虑使用。


2. CQRS
从业务上划分读写请求model，也就是query和command。
读请求一般直接读缓存。而缓存和主库之间采用单向同步，有些应用也会考虑在写的时候同时更新缓存。
写请求会进入event source，然后更新主库。

优势： 架构简单，开发速度快。
劣势： 没有消息中间件，使得业务上很难分离也无法独立扩展，靠纯异步提高并发能力导致数据库压力大（相比于上面一种架构）
适用： 短平快项目


3. Microservice
最近流行的一种架构，特征是服务间完全分离。程序入口会有一个api gateway来做对接。
优势： 业务和应用的扩展性，性能，运维监控，以及上线都不是问题。
劣势： 搭建环境和开发的难度较大，需要大量人力资源来完成。
适用： 大型应用。


总结： 没有一成不变的架构，可以说是因公司业务，团队而异，架构一旦确定，也是一个演化的过程。就拿微服务来说，对于业务简单的软件项目而言，根本没有必要，盲目跟风只会导致不必要的复杂度。Steve McConnell的《代码大全》中说过： 管理复杂度是程序员的首要使命。对于设计而言，也是一样。