分布式与集群

分布式

分布式就是把一个系统拆分成多个服务节点，每个节点部署在不同的服务器上，可以理解为串联模式（多个电池串联起来电压增加电池容量不变）

集群

集群就把一个服务复制部署在多台电脑上，多台电脑同时执行同一个服务的功能，可以理解为并联模式（多个电池并联电压不变电池容量增加）

微服务中先分布式后集群

先分布式：例如12306，会把分成登录、查票、订单、支付等多个服务。

后集群：根据请求访问量多的服务弄成集群模式，例如12306中的查票服务。

微服务是什么

微服务是一个支持特定业务场景的独立部署单元。它借助语义化版本管理、定义良好的 API 与其他后端服务交互。它的天然特点就是严格遵守单一职责原则。

包含以下特点

• 每个微服务独立完整性：，虽然每个微服务会有重复部分，但是不能提取出来放到公共服务中，因为要保证每个微服务都有独立性完整的功能，以便于横向集群扩展
• 公共服务：包括注册、通信、认证、限流、负载均衡、熔断、日志等，这些公共服务有变化时不会影响到单个微服务

架构四要素：

1. 问题：确定问题，怎么做　　　　
2. 问题边界 （约束 ）：谁的问题，给出约束
3. 生命周期：从生到死
4. 拆分：根据问题的生命周期拆分

设计模式

聚合器微服务设计模式

这是一种最常用也最简单的设计模式，目前学习的微服务系列都是选择这种设计模式，如下图所示：

聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的Web页面，将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务，对检索到的数据增加业务逻辑后进一步发布成一个新的微服务，这符合DRY原则。另外，每个服务都有自己的缓存和数据库。如果聚合器是一个组合服务，那么它也有自己的缓存和数据库。聚合器可以沿X轴和Z轴独立扩展。

数据共享微服务设计模式

代理微服务设计模式

链式微服务设计模式

分支微服务设计模式

异步消息传递微服务设计模式

根据下面条件选择微服务设计模式

1. 根据业务特点
2. 根据公司组织
3. 根据公司集体利益

分层法

以文件分层法为主，以程序集分层法为次

架构说明：

• 微服务网关层：路由、认证、限流、日志、监控、、负载均衡、缓存等功能负载均衡：代理多个网关，做网关集群问题：负载均衡用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）架构
• 微服务架构