分布式与集群
分布式
分布式就是把一个系统拆分成多个服务节点,每个节点部署在不同的服务器上,可以理解为串联模式(多个电池串联起来电压增加电池容量不变)
集群
集群就把一个服务复制部署在多台电脑上,多台电脑同时执行同一个服务的功能,可以理解为并联模式(多个电池并联电压不变电池容量增加)
微服务中先分布式后集群
先分布式:例如12306,会把分成登录、查票、订单、支付等多个服务。
后集群:根据请求访问量多的服务弄成集群模式,例如12306中的查票服务。
微服务是什么
微服务是一个支持特定业务场景的独立部署单元。它借助语义化版本管理、定义良好的 API 与其他后端服务交互。它的天然特点就是严格遵守单一职责原则。
包含以下特点
- 每个微服务独立完整性:,虽然每个微服务会有重复部分,但是不能提取出来放到公共服务中,因为要保证每个微服务都有独立性完整的功能,以便于横向集群扩展
- 公共服务:包括注册、通信、认证、限流、负载均衡、熔断、日志等,这些公共服务有变化时不会影响到单个微服务
架构四要素:
- 问题:确定问题,怎么做
- 问题边界 (约束 ):谁的问题,给出约束
- 生命周期:从生到死
- 拆分:根据问题的生命周期拆分
设计模式
聚合器微服务设计模式
这是一种最常用也最简单的设计模式,目前学习的微服务系列都是选择这种设计模式,如下图所示:
聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的Web页面,将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务,对检索到的数据增加业务逻辑后进一步发布成一个新的微服务,这符合DRY原则。另外,每个服务都有自己的缓存和数据库。如果聚合器是一个组合服务,那么它也有自己的缓存和数据库。聚合器可以沿X轴和Z轴独立扩展。
数据共享微服务设计模式
代理微服务设计模式
链式微服务设计模式
分支微服务设计模式
异步消息传递微服务设计模式
根据下面条件选择微服务设计模式
- 根据业务特点
- 根据公司组织
- 根据公司集体利益
分层法
以文件分层法为主,以程序集分层法为次
架构说明:
- 微服务网关层:路由、认证、限流、日志、监控、、负载均衡、缓存等功能负载均衡:代理多个网关,做网关集群问题:负载均衡用nginx好还是直接用网关好???nginx是针对整个系统的,ocelot是针对单个微服务的?oclet:熔断降级:问题?网关也能做熔断降级,到底是做在网关层好还是坐在工具层好???
- 微服务聚合层(又叫边界层):
- 微服务层(又叫基础服务层):
- 微服务数据层:DB、cache
- 工具基础层:服务发现、熔断降级、日志、分布式事务、配置中心服务发现 consul:客户端发现模式、服务端发现模式、服务注册表熔断降级 Polly:熔断:作用就是在特定的场景下关掉当前的通路,从而起到保护整个系统的效果降级:保证系统核心服务正常运行,暂停非核心的一些外围服务日志:分布式事务:配置中心 consul:
层次调用说明
先后顺序:【网关层】=》【聚合层】=》【数据层】
工具层(基础层):没有先后先后顺序,其他层有需要就直接调用
项目结构说明:
主项目src结构
- AggregateService(聚合服务)
- CommonService()???
- LocationService(成员位置服务)
- MemberService(成员服务)
- MicroService.Core(核心服务/公共服务/工具层)
- MicroService.Gateway(网关服务)
- MicroService.IdentityServer4(认证、授权服务)
- MicroService.MVCClient(MVC客户端)
- MicroService.VideoService(视频服务)
- TeamService(团队微服务)
项目依赖
项目依赖:AggregateService [ æɡrɪɡeɪt ]、TeamService、MicroService.VideoService都是依赖MicroService.Core
项目依赖与集群问题
问题:
如果每个服务都是独立部署到一台服务器上做集群,那怎么依赖MicroService.Core项目啊?难道每个服务都要带着MicroService.Core?例如部署TeamService的服务器同时要有MicroService.Core???
答疑:
主要区分清楚项目依赖和微服务之间的通讯就好:
- 项目依赖是程序集依赖,发布时会直接打包了依赖项目的相关文件
- 微服务之间通讯是通过http或grpc的方式进行服务之间的通讯,相互之间没有依赖
项目依赖的时候,在发布是会自动把依赖的项目打包进来,包括.dll、.exe、.pdb等文件,如下图:
AggregateService(聚合服务)结构说明
- 聚合服务是怎么指向TeamService(团队微服务)???
TeamService(团队微服务)结构说明
- Program:程序入口
ASP.NET Core 应用在启动时构建主机。 主机封装应用的所有资源,例如:HTTP 服务器实现中间件组件Logging依赖关系注入 (DI) 服务Configuration主机加载Starup启动类,参考:泛型主机 - Startup:启动配置类,两个配置方法:ConfigureServices:配置应用的服务,一般通过注入接口、接口的方式配置服务Configure:创建应用的请求处理管道配置,一般是通过方法配置
参考:Startup 类 - appsettings.json配置文件
- 连接字符配置:例如数据库连接配置DefaultConnection
- 日志配置:Logging
- 自定义配置:例如Consul注册配置ConsulRegistry
参考:配置
- Controllers:控制器层 / 接口层(resful api)接受前端请求依赖Server层:构造函数注入时依赖依赖appsettings文件的ConsulRegistry配置:构造函数时依赖,在Starup类的Configure方法中有注入Consul相关配置依赖Models层
- Models:领域模型层数据库模型:数据库根据它生产对应的表的字段、关系等视图模型 / 领域模型:提供前端使用到的视图模型 / 领域模型
- Services:领域服务层(数据交互,包含业务逻辑)依赖仓储层:构造函数注入时依赖增、删、改、查方法,方法内只有调用仓储层的方法
- Repositories:领域仓储层增、删、改、查的方法,方法内有具体实现,没有业务逻辑依赖数据库上下文:构造函数注入时依赖方便更换数据库?
- Context:数据库上下文
分布式事务omega
备注:omega文件夹下的4个类库不需要手工创建,下载源码中包含有,在项目中添加一个文件夹然后添加现有项目,然后在微服务层引用
- Servicecomb.Saga.Omega.Abstractions:抽象层
- Servicecomb.Saga.Omega.AspNetCore:AspNetCore层
- Servicecomb.Saga.Omega.Core:核心层
- Servicecomb.Saga.Omega.Protocol:协议层
测试Test
- TeamService.Tests:团队服务测试
微服务通讯方式
http通讯(REST API)
备注:此系列微服务都是使用http通讯方式
rpc通信(rpc、grpc)
微服务如何拆分:
架构演进
- 单体架构
- 单数据库多应用架构
- 主从数据库读写分离架构
- 主从数据库读写分离+缓存架构
- 消息队列架构
- 面向服务(SOA)架构
- 微服务架构