微服务架构总结与日后学习导向

发布时间:2018/2/8 16:59:30 次浏览

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

架构学习前言

因为公司架构组决定在后续的项目系统开发中采用 “微服务架构+.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 异常重试