abp运行机制分析
基于DDD思想的微服务架构学习导向
架构学习前言
因为公司架构组决定在后续的项目系统开发中采用 “微服务架构+.netcore” 模式，这个模式直接用于实践，对于我们公司这些没有实践经验的人来说，开发难度是显而易见的。正因为如此，公司架构师才数次为我们研发人员进行架构培训，讲关于这套架构所涉及的知识，比如.net core，efcore，consul，cap等。
现在这套系统我们已经比较熟悉了，开发也逐渐走上了正轨，所以我想回过头来总结一下公司目前所采用的这套框架，分析流程以及其中使用的知识点，开源项目等。
架构解析
前端
- npm + webpack 开发工作流
- react 为UI层，以及antd作为基础控件实现
- react route 路由实现
- 公共状态用的是 redux
- redux-saga 编写 redux 业务流
- postal 来实现事件驱动来解耦
目前我们前端框架所用到的就是上面这些，因为我这次主要是讲后端框架的一些实现细节，所以前端后面有机会在细说
后端
后端框架总的来说还算比较好理解的，我首先来回顾一下架构总的流程设计思路。
首先从前端发出请求开始，首先会经过 Nginx 负载均衡到我们的Host层（我个人理解为 “api转接，数据包装” 层，这里是不含任何业务逻辑的，以下称为Host层），然后Host层经过Api网关服务器分发到各个领域服务，这里面的过程是用的是开源的 consul 分布式服务注册和发现的工具，经过api网关分发到具体的领域服务之后，就到了我们的重点的 “业务层” 了，所有的业务都是在这里编写开发的，业务领域层与值持久化层交互，而我们的数据库方面也是集群的，采用读写分离的原则（因为mysql在这方面配置使用起来简单，比如主从库同步等，这也是我们使用 mysql 的一个主要原因），用 efcore 对 dbwrite 写数据，dapper 对 dbread 读数据。除此之外，缓存，报表等需要对数据进行特定的加工也都是在这个数据存储层。
接着我们回过头来到领域服务层，这里包含了所有的业务逻辑，自然也包含了领域事件，在架构中，事件分两种：
- 领域事件（Domain Event）
- 集成事件（Integration Event）
领域事件我们是用的 MediatR 开源组件来解耦领域与领域之间的交互。
集成事件我们是用的 CAP + kafka 来实现进程级别的领域服务交互来保证最终一致性，这里面的幂等提交，容错，阶段提交，重试措施，熔断等就不说了，这方面是个大内容我也仅仅只是了解，不过是我日后学习的一个方面。
讲到这里整个微服务架构的流程就差不多了，但是这仅仅只是我们公司架构的运行过程，比较简单，但是于我们来说又复杂，也不跟其他公司的架构做对比了
总结
现在来简要概括一下后端的流程架构
- 前端开始请求
- 进过 Nginx 负载均衡来到Host层（实现高负载）
- Host层在由 Consul api网关服务器 分配到各个领域层
- Domain layer 负责业务的编写与 db 的交互
- Domain layer 中由 MediatR 和 CAP 实现同进程，垮进程间的领域交互
- 数据，缓存都在 持久化层
- 另外还有单独的业务级别的任务调度（HangFire，Quartz等）
所涉及的知识点，也就是我后面要分析以及学习的知识
- MediatR 实现同进程间的领域交互
- FluentValidation 验证组件（独立验证）来解耦业务
- CAP 实现跨进程的领域事件调度
- Autofac
- Dapper（NPoco）
- Polly 异常重试