微服务架构:介绍、分布式与集群、架构四要素、设计模式、架构说明、项目结构说明、通讯方式、架构演进

分布式与集群

分布式

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

集群

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

微服务中先分布式后集群

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

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

微服务是什么

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

包含以下特点

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

架构四要素:

  1. 问题:确定问题,怎么做    
  2. 问题边界 (约束 ):谁的问题,给出约束
  3. 生命周期:从生到死
  4. 拆分:根据问题的生命周期拆分

设计模式

聚合器微服务设计模式

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

微服务架构:介绍、分布式与集群、架构四要素、设计模式、架构说明、项目结构说明、通讯方式、架构演进_第1张图片

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

数据共享微服务设计模式

代理微服务设计模式

链式微服务设计模式

分支微服务设计模式

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

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

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

分层法

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

架构说明:

  • 微服务网关层:路由、认证、限流、日志、监控、、负载均衡、缓存等功能负载均衡:代理多个网关,做网关集群问题:负载均衡用nginx好还是直接用网关好???nginx是针对整个系统的,ocelot是针对单个微服务的?oclet:熔断降级:问题?网关也能做熔断降级,到底是做在网关层好还是坐在工具层好???
  • 微服务聚合层(又叫边界层):
  • 微服务层(又叫基础服务层):
  • 微服务数据层:DB、cache
  • 工具基础层:服务发现、熔断降级、日志、分布式事务、配置中心服务发现 consul:客户端发现模式、服务端发现模式、服务注册表熔断降级 Polly:熔断:作用就是在特定的场景下关掉当前的通路,从而起到保护整个系统的效果降级:保证系统核心服务正常运行,暂停非核心的一些外围服务日志:分布式事务:配置中心 consul:

微服务架构:介绍、分布式与集群、架构四要素、设计模式、架构说明、项目结构说明、通讯方式、架构演进_第2张图片

层次调用说明

先后顺序:【网关层】=》【聚合层】=》【数据层】

工具层(基础层):没有先后先后顺序,其他层有需要就直接调用

项目结构说明:

主项目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通讯方式

微服务架构:介绍、分布式与集群、架构四要素、设计模式、架构说明、项目结构说明、通讯方式、架构演进_第3张图片

rpc通信(rpc、grpc)

微服务架构:介绍、分布式与集群、架构四要素、设计模式、架构说明、项目结构说明、通讯方式、架构演进_第4张图片

微服务如何拆分:

微服务架构:介绍、分布式与集群、架构四要素、设计模式、架构说明、项目结构说明、通讯方式、架构演进_第5张图片

架构演进

  • 单体架构
  • 单数据库多应用架构
  • 主从数据库读写分离架构
  • 主从数据库读写分离+缓存架构
  • 消息队列架构
  • 面向服务(SOA)架构
  • 微服务架构

微服务架构:介绍、分布式与集群、架构四要素、设计模式、架构说明、项目结构说明、通讯方式、架构演进_第6张图片

微服务架构:介绍、分布式与集群、架构四要素、设计模式、架构说明、项目结构说明、通讯方式、架构演进_第7张图片

你可能感兴趣的:(微服务,分布式,架构,分布式,数据库,网关,java,spring)