性能瓶颈原因分析

我们在不考虑硬件瓶颈的情况，只从软件角度来分析，系统的瓶颈产生的过程如下：

软件系统上线以后随着数据的不断积累和需求的不断变化，将面临两个不同维度的主要问题：

1. 随着时间积累，用户量的上升与数据量的积累

2. 随着系统的使用反馈，带来的需求变更与升级

对应的解决方案：

1. 数据量与请求量的上升，我们可以采用的解决方案就是负载均衡。

   例如通过容器化技术实现负载均衡。

2. 面对需求的调整与反馈，那我们只能提供不断的调整系统来应对。

基于上述的两种解决方案，最终系统的瓶颈，将主要产生在如下的两个地方：

1. 由于设计缺陷，导致业务不可控

2. 底层大量有状态的服务依赖，导致无法无限的负载均衡。

性能瓶颈的解决方案

其实这两个这两个问题本质上也是一个问题，上帝的归上帝，凯撒的归凯撒。

系统业务设计应该由业务模型来解决，有状态的服务的依赖，要做到可拆分。

    在Command中业务的交互，这个过程中将需要通过业务模型的交互完成业务逻辑的处理，同时要将模型数据与查询数据存储起来。通过事件机制实现对数据的广播，然后由各Query模块订阅并同步其数据，利用事件的广播机制同步数据，实现对有状态的数据分散。

    在这个过程中其实，domain-storage 、EventBus 、 QueryStorage 这些概念都不重要，因为这些都是技术，具体方案时取决于你的选型，而CQRS也非常容易落地，其实最复杂的是DomainModel的建立过程，也就是业务模型的建立过程，而业务模型的建立也是解决第一个问题的根本，所以说上述的两个瓶颈其实都可以归结到一个问题上。

如下代码演示domain生命周期的监控与事件发布

Demo模型代码：

模型交互代码：

打印日志如下:

上述代码来源codingapi的开源框架 https://github.com/codingapi/springboot-framework

本框架基于springboot为提供领域驱动设计与事件风暴开发落地，提供的范式开源框架。