基于DDD思想的微服务架构学习导向

Posted DotNet开发跳槽

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了基于DDD思想的微服务架构学习导向相关的知识,希望对你有一定的参考价值。

原文链接:https://www.cnblogs.com/ms27946/archive/2018/02/08/ApiGateway-Architecture-Learning.html

架构学习前言

因为公司架构组决定在后续的项目系统开发中采用 “微服务架构+.netcore” 模式,这个模式直接用于实践,对于我们公司这些没有实践经验的人来说,开发难度是显而易见的。正因为如此,公司架构师才数次为我们研发人员进行架构培训,讲关于这套架构所涉及的知识,比如.net core,efcore,consul,cap等。

现在这套系统我们已经比较熟悉了,开发也逐渐走上了正轨,所以我想回过头来总结一下公司目前所采用的这套框架,分析流程以及其中使用的知识点,开源项目等。

架构解析

前端

  1. npm + webpack 开发工作流

  2. react 为UI层,以及antd作为基础控件实现

  3. react route 路由实现

  4. 公共状态用的是 redux

  5. redux-saga 编写 redux 业务流

  6. 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 异常重试

希望有个生活精彩的程序人生


以上是关于基于DDD思想的微服务架构学习导向的主要内容,如果未能解决你的问题,请参考以下文章

如何构建基于 DDD 领域驱动的微服务?

如何构建基于 DDD 领域驱动的微服务?

为啥DDD是设计微服务的最佳实践

DDD兴起的原因以及与微服务的关系

DDD 领域驱动设计落地实践系列:微服务拆分之道

微服务入门|微服务架构怎么设计