微服务架构与SpringCloud搭建的一个Demo

架构: 系统架构的一个演变的过程 单体架构 -> 集群架构->垂直架构->SOA架构->到现在的微服务架构 

单体架构就是在一台机器上 同一进程

集群就是 抽象点就是开三个后端服务  同一个业务 部署在多个服务器上 这也会产生就是说 比如我同时开三个后端 有时候我的一个服务需要扩展 另外两个服务也需要同时扩展 导致系统的扩展性不好 横向扩展还好

再进行拆分的话就是微服务  分为商品服务 订单服务 用户服务 使得系统的耦合性降低 这样也会产生问题 各个服务之间的调用问题  

微服务架构的优势: 独立开发 独立部署  故障隔离 混合技术堆栈 粒度缩放 

服务注册 : 将服务实例将自身服务信息注册到注册中心

服务发现:  服务实例通过注册中心 获取到注册到其中的服务实例信息  通过这些信息去请求这些提供的服务  

服务剔除: 注册中心把出问题的服务剔除掉  使得其不再被调用 

服务调用 :多个服务之间的;远程调用

服务网关: 服务网关的出现主要是针对于 这些问题出来的  ; 客户端需要调用不同的url增加难度 在一些场景下 存在着跨域请求的问题  每个微服务都需要有单独的身份验证  API网关是将所有的调用都接入API网关层中 和输出 网关会根据你的请求地址去找到其对应的服务

服务容错 : 其中一个服务出现了问题 可能会导致一系列的问题 导致下游不可用 要尽量做好容错 

链路追踪 :就是 链路请求在系统内部的轨迹  

搭建项目 以用户  商品 订单为例 搭建一个springcloud的一个项目

主要模块有 公共模块 common放一些工具类之类的  user微服务 order微服务  product微服务

服务调用 :

通过RestTemplate来实现服务的调用 

例如:

User user = restTemplate.getForObject("http://127.0.0.1:8081/user/findUser/"+uid, User.class);

  这种调用方法虽然可以实现服务的调用 但是会产生新的问题 一旦我的服务地址发生变化 的话就需要手动的去修改代码 多个服务的提供者 无法实现负载均衡 服务越来越多人工维护关系困难

服务治理 : Nacos

服务治理是我们最核心的一个模块 用服务治理来实现我们各个微服务模块之间的自动化 的注册和发现 

 服务注册 ;

服务治理框架中会构建一个注册中心每个服务都会去注册中心登记自己提供的服务  在注册中心中就会有自己的一个服务的清单 可以 在服务中心去剔除不可用的服务 服务中心会去检测这些服务是否可用 

服务发现 : 

服务调用向注册中心去获取所有服务的清单 实现具体服务的实例访问

注册中心一般包含以下的内容: 服务发现 服务配置 服务健康检测 

服务发现  保存服务提供者和服务调用者的信息

常见的注册中心  zookeeper  Eureka  Nacos 

我搭建的使用的是nacos 下载  配置   就可以使用

nacos实现服务的调用使用 discoverClient  通过nacos获取 url和对应的服务

服务调用实现负载均衡 : 通过自定义实现负载;均衡 就是使用随机数策略  负载均衡就是将负载进行分摊到多个操作单元上执行  

基于Ribbon实现负载均衡的策略 调用 策略就是通过服务名去找到对应的对应的服务 总共有七种负载均衡的策略 :

轮询策略  随机数策略 权重策略 最小连接数策略 区域敏感策略 可用敏感性策略 重试策略        

基于feign实现负载均衡策略: 通过接口来实现服务的调用  feign中自动集成了Ribbon 所以可以实现负载均衡策略 通过在 接口上加注解@FeignClient("服务名") 然后通过接口来调用服务 这种写法比较简单而且优雅  

随后就是考虑高并发的问题 : 服务容错   高并发带来的问题  大量的请求过来可能导致服务瘫痪   模拟高并发的场景 用的是jmter  对代码进行压力测试  最终 大量的请求过来会导致无法访问的情况形成 了服务雪崩   各个服务之间有直接依赖性   下游的服务出错可能导致我们之前的服务也没办法进行正常的服务提供  可能会导致服务雪崩 只有做好容错才能保证我们即使一个服务出错之后其它的服务也可以正常的进行运作 : 也就是 "雪落而不崩" 的情况 常见的思路有隔离  超时  限流 熔断 降级

隔离就是 各个模块直接没有强依赖 线程池隔离 信号量隔离

限流 : 1秒钟之内只能有一个请求过来 

熔断; 暂时切断对下游服务的调用 

降级就是使用备用方案

我用Sentinel 主要有熔断控制  流量降级  

GateWay 网关 有那么多服务不知道该调那个 就使用网关来调用  而且调用服务的时候要对用户进行鉴权  也可以用网关来实现  只对外提供一个网关接口供用户去调用 具体调用交给网关 

通过访问网关  然后网关将请求转发给商品服务然后结合nacos可以从注册中心去获取我们的服务加过滤器之类的  也可以使用Sentinel对网关限流 实际上是通过filter来实现的

MQ message queue 消息队列

应用场景

异步解耦 :  耦合就是 比如送快递  快递员把快递送到用户的手里 等待用户来拿快递员才走 这就是耦合 同步的  异步就是快递员把快递送到快递驿站去 用户去快递站拿  就是异步解耦  彼此不联系 也不受影响