分布式-微服务是什么? woniuxy84仅仅一篇带你浅入深出

一.分布式简介

  什么是分布式系统?

  分布式系统就是一组部署在同一网络下通过网络通信和协调的组件,对外形同一个系统.

举一个例子来说:假如原来咱们做了一个电商系统,里面包含了权限模块,员工模块,收银模块,商品模块等等,一个项目里面包含了一堆模块,通过一台服务器部署,模块之间相互调用.

  那现在咱们将这个电商系统拆分为:权限系统,员工系统,收银系统,商品系统 等等,分别部署在四台机器上.

  然后用户一个请求过来,咱们要完成和这个请求:员工系统通过网络去调用权限系统,接着调用商品系统,最后调用收银系统,为了完成这一件事 分别调用了四个系统.

  最后这四个系统全部响应完成后,才认为这个请求已经完成.用户体验起来就好像调用了一个系统,这就是所谓的分布式系统 当然我也画了一张图来感受一下上述的过程:

二.分布式架构-微服务出现的意义

  有的同学估计就会觉得一台服务跑的好好的,一个简单的需要何必搞的这么麻烦 一个系统就可以解决,为甚还要去搞什么分布式架构?

  当然 这位同学说的也没有错 一些简单的项目可以直接走垂直架构.但是现在都是21世纪了 随着互联网的发展,贵公司的业务也在不断发展例如:注册用户增加,各种层出不同的渠道访问,app 微信,抖音,小红书等等,随着用户量的增大,各种新的业务,新的需求也就不断涌入了 量变引起了质变,之前的单体垂直项目修改起来就特别麻烦.

   首先单体项目会变得特别的臃肿,今天增加一个业务,明天就新增一个模块,经常会有各种代码合并冲突需要解决,非常的耗时间,代码冗余非常的大,异常处理起来也非常麻烦 业内简称si代码.如果你进入这样的公司,恭喜这位同学,你的异常处理能力将变得异常强大.

  其次是随着用户注册的增多,访问系统的流量就增加,那么单个系统处理起来就变得异常的乏力.周而复始,效率低下,公司的战略发展需要也无法满足.

   单体项目问题总结来说就是以下几个方面:

   1.代码耦合非常严重,功能拓展维护相当麻烦

   2. 需求开发的交付周期延长,测试工作量大

   3. 升级维护也很困难

   4. 系统性能提升困难,可用性低,不稳定

   既然咱们谈到了单体垂直项目的缺点,按照管理用了分布式系统带来的好处

        1.各个系统维护自己的代码,降低代码的耦合

        2,测试仅仅测试自己的逻辑就可以了

        3.技术上可以随心所欲的升级,仅仅保持接口不变就好了

总结起来就是一句话,在当下互联网时代 分布式架构是必然的趋势

三.微服务架构简介

     微服务要解决的问题: 简单的说就是将单体应用进一步拆分，拆分成更小的服务，每个服务都是一个可以独立运行的项目.

一旦采取了微服务系统架构,那么他也会遇到一些新的问题

1 这么多微服务,如何来管理他们?

2 这么多微服务,客户端如何来访问?

3 这么多微服务 一旦出现问题了,应该如果处理?

4 这么多微服务 他们如何相互访问?

对于以上的问题,是任何一个微服务开发人员无法避免的问题,既是开发人员的新挑战 也是新的机遇

而且大部分的微服务产品都针对每一个问题提供了响应的组件来解决他们.

   有哪些主流的微服务框架?

1 spring Cloud Netfix

2 Spring Cloud Alibaba

3 SpringBoot+Dubbo +ZooKeeper

四 微服务架构的常见解决主键

  4.1微服务之间如何相互访问?

服务调用 微服务之间通信采用RestTemplate调用，现在通常用 Open Feign 封装的Rest调用，Rest(Representational State Transfer)：这是一种HTTP调用的格式，更标准，更通用，无论哪种语言都支持http协议 

 openfeign 这里我们吧调用服务称为消费者 提供服务的叫做提供方 消费者调用提供方的接口是通过spring Aop 通过反射生成代理对象 根据请求信息生成服务调用.

这里面还有一个新的问题 当用户访问服务端的时候,如果不做一定的处理 某一台机器就会被击穿,或者说某一些机器就会空闲.

将请求流量均衡的发送给服务提供方,就有了负载均衡

•         轮询 roundrobbin 轮询是将客户端的请求轮流分配到每一个节点上，当有5台机器的时候，来5个请求，每台机器都将得到一次请求，并不会关心服务器实际的连接数和当前的系统负载。
  • 响应时间加权 WeightedResponseTime  不同的后端服务器配置可能不同，因此能承受的流量也不同，使用加权法，可以让配置高的机器得到更大的权重，处理更多的请求。降低配置低的机器的请求
  • 最小并发数 BestAvailiable 选择一个最小的并发请求的server
  • 随机 random  随机法顾名思义就是客户端请求会随机选取一台服务器进行访问，当客户端调用服务器的次数增多的时候，每台机器获得的请求数是差不多的，也就是平均分配了。

  4.2微服务之间如何管理?     

服务管理就是进行服务的自动化管理，其核心是服务的注册与发现。

• 服务发现： nacos 找到服务的地址

1. 1. 生产者启动时进行服务注册
   2. 消费者拉取服务列表
   3. 服务注册表对生产者进行健康检测
   4. 如果发生变更，服务注册表则通知消费者
   5. 消费者重新拉取服务列表

4.3微服务一旦出现问题了,应该如果处理?

在微服务当中，一个请求经常会涉及到调用几个服务，如果其中某个服务不可用，没有做服务容错的话，极有可能会造成一连串的服务不可用，这就是雪崩效应。

我们没法预防雪崩效应的发生，只能尽可能去做好容错。服务容错的三处理是：

1. 超时[调用方]， 限制资源的占用，给资源（线程、cpu时间）占用设置上线
2. 限流[提供方]，控制进入系统的流量，不超过本机最大处理能力
3. 仓壁模式[调用方/提供方]，利用线程池或者信号量等其他手段进行资源隔离，确保不会产生级联故障

4.4 这么多微服务 客户端如何来访问?

随着微服务的不断增多，不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求，这肯定不利于公司的战略发展对吧 为了解决这些问题，服务网关顺势而生。

     API网关直面意思是将所有API调用统一接入到API网关层，由网关层统一接入和输出。一个网关的基本功能有：安全防护、协议适配、流量管控、长短链接支持、容错能力。有了网关之后，各个API服务提供团队可以专注于自己的的业务逻辑处理，而API网关更专注于安全、流量、路由等问题。
 

4.5 这么多微服务 如何保证数据的一致性?

微服务架构下，一个业务操作必须经过多个服务，每个服务有自己独立的数据库，造成一个业务操作必然在多个数据库实例中执行，必须达到多个数据库实例同时成功或者失败的效果，才能实现这个业务操作。必须对数据库进行协调,那么分布式事务就出来了.

分布式事务分为两段

阶段一： 预备阶段

• TC通知所有分支事务执行业务操作
• 所有分支事务处理完成后告知TC

阶段二： 提交阶段

• TC如果收到所有的分支事务提交都是完成，则全局事务提交，通知所有分支事务提交
• TC如果有收到存在部分提交失败或者超时，则全局事务回滚，通知所有分支事务回滚

常见的解决方案有:

 1.XA协议 数据库层面解决 :多个数据库，同步打开事务，不提交，等待TC协调，等所有事务确认提交之后，再提交.

 2 TCC ： Try-Confirm-Cancel 

        阶段一： 执行 Try操作 锁定资源

        阶段二：根据一阶段Try结果，决定执行confirm 提交（全部尝试成功）或者cancel（没有全部尝试成功）回滚

 3 SAGAS

        务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现

 4 AT模式

阶段一：预备阶段

• 1.执行业务
• 2. 获取并持久化回滚数据
• （1）seata代理数据源（javax.sql.DataSource），拦截所有的数据库操作（SQL）
• （2）获取到操作执行前后的数据镜像，生成insert SQL，插入到undo_log表
• （3）加入到当前事务，提交

阶段二：提交阶段

• 正常提交：删除undo_log表中的记录
• 异常回滚：

• • seata提取对应的undo_log表中的记录，计算生成回滚用sql
  • 执行回滚SQL，提交事务

 5 重试+幂等性校验   

        幂等性校验，区分出请求是重复请求，一般通过外部的ID区分

        重试不能成功，需要告警，人工介入