【微服务常识】

一、网关

流量网关提供全局性的、与后端业务应用无关的策略，例如 HTTPS证书卸载、Web防火墙、全局流量监控、日志记录、黑白名单控制、接入请求到业务系统的负载均衡等，比如Kong。

业务网关业务紧耦合的、提供单个业务域级别的策略，如服务治理、身份认证,权限控制、日志输出、数据加密、熔断限流等等，比如K8s的Ingress, SpringCloud gateway

随着k8s的普及，Ingress 逐渐成为 K8s 生态的网关标准，促使流量网关和业务网关，合二为一。

二、容错

2.1 常见的容错思路

• 隔离： 将应用（一个进程）分多个模块，各自相对独立，不强依赖。故障发生时，将问题和影响隔离在某个模块内部。
  • 线程池隔离
  • 信号量隔离
    
• 超时
• 限流
• 熔断
  • 上游访问下游，下游不堪负重；上游为保整体可用，暂时“切断” 对下游的调用。如此，牺牲局部，保全整体，谓之熔断。
  • 服务熔断有三种状态：
    • 熔断关闭(closed)：服务无故障，熔断器所处状态，表示对调用方调用不做限制
    • 熔断开启(open)：rpc调用，降级为本地的 fallback方法
    • 半熔断状态(half-open)：尝试恢复调用，允许有限的流量调用，监控调用成功率；若成功率达到预期，说明服务已恢复，进入熔断关闭状态。
• 降级
  • 托底方案

2.2 常见方案

• hystrix
• resilience4j
• sentinel
  阿里的服务容错方案，以流量为切入点，从流量控制、熔断降级、系统过载保护等多个维度保护服务稳定。
  主要分两个部分：
  • java客户端（不依赖任何框架或库，运行在任何java runtime，同时对dubbo、springcloud支持较好）
  • dashboard(console)
  • console是个可选项，即使没有console也能对单机进行限流；但从生产来看，没有可视化UI基本没有可操性

2.3 容错的三个核心思想

• 保证自己不被上游打垮
• 保证自己不被下游拖垮
• 保证外界环境良好
  
  sentinel的三个特性（feature）：
  • 流控
  • 熔断降级
  • 热点规则

2.4 流控规则

流控分三种模式：直接、关联、链路
- 直接：就是最寻常的对资源限流
- 关联：就是优先允许关联资源通过
- 链路：当从某个接口过来的资源（@SentinelResource标记的）到达限流条件时开启限流，有点类似针对来源配置项，区别在于：针对来源是针对上游的服务，而链路流控是针对上游接口，粒度更细

流控效果：

• warm up （？）
• 快速失败
• 排队等待
  

2.5 熔断降级

• 控制并发线程数
• 通过响应时间（rt）对资源降级
• 对比hystirx: 采用线程池隔离 的方案，做到了资源之间的隔离，但是增加了线程切换成本

降级规则：当满足什么条件时对服务降级。sentinel提供了三个条件：

• 平均响应时间：资源平均响应时间超过阈值，资源进入准降级。
• 异常比例
• 异常数
  

2.6 热点规则

更细粒度的流控规则，允许规则作用到参数上。

2.7 授权规则

黑白名单来控制资源的请求来源

2.7 过载保护

提供了系统维度的自适应保护能力（前面都是资源维度）。集群环境下，会将某台机器承载的流量转发到其他节点；若其他节点也在边缘状态，sentinel提供了对应保护机制，让系统入口流量和负载达到平衡，保证系统在能力范围内处理最多请求。

2.8 自定义规则异常返回

扩展UrlBlockHandler

2.9 @SentinelResource

@SentinelResource()可以指定blockHandlerClass,fallbackClass,blockHandler,fallback等降级时会使用到的扩展点。

2.10 sentinel规则持久化

sentinel默认将规则缓存在内存，若需要生产可用，需要自行扩展持久化策略，一种思路是：

不过将规则放到nacos中是一个更好的做法

2.11 sentinel+feign整合

将feign调用的治理交给sentinel
（?）

三、gateway

3.1 route

• id
• uri ： 客户端请求你最终被转发到的微服务
• order ： 多个route间的排序，越小越优先
• predicate： 多个断言，必须全真才路由
• filter： 用于修改请求和响应信息

3.2 执行流程

注意：filter链

3.3 断言

springcloud gateway内置了很多断言工厂，即AbstractRoutePredicateFactory有很多子类，可以基于method、 query请求参数、path、路由权重，等等

自定义断言：

• 通过扩展 AbstractRoutePredicateFactory来实现

3.4 filters

• 过滤器就是在请求传递的过程中，对请求和响应增减“一点东西”。
• 生命周期：pre post 【注意这二个】
• pre: 过滤器在请求被路由之前调用，借此过滤器可实现身份验证、在集群中选择请求的微服务、记录调试信息等
• post: 过滤器在路由到微服务后进行，用来响应添加标准的http header、收集统计信息和指标、将响应从微服务发到客户端

filters 分类：GatewayFilter（局部过滤器，作用在某一个路由）和GlobalFilter（全局过滤器，作用在全部路由上）

局部过滤器

• AddRequestHeader
• AddRequestParameter
• AddResponseHeader
• FallbackHeaders
• PrefixPath
• RequestRatelimter
• RedirectTo
• RequestSize
• …

自定义过滤，可以通过继承 AbstractGatewayFilterFactory来实现

全局过滤器

gateway内置了很多个全局过滤器对整个路由转发。

• LoadBalancer LB过滤器（这个最为重要）
• HttpClient
• WebSocket
• RouteToRequestUrl
• ForwardPath 路径转发过滤器

自定义过滤可实现 GlobalFilter来实现，比如可以定义一个全局过滤器，校验所有请求参数中是否包含token； 若不包含，则不转发请求，否则转发。

网关限流

网关是请求的入口，可以在网关进行限流，方式也多，比如用sentinel组件来限流（下图）；当然也可以利用自身的机制（e.g. RequestRateLimiter ，借助redis做到了全局的限流）

sentinel 提供了两种资源维度的限流：

• route维度：spring配置文件中的路由条目，资源名为对应的(spring.cloud.gateway.routes[0].id)
• 自定义API维度：用户可以利用sentinel提供的API自定义一些API分组 【可问下chatgpt如何进行网关限流，另：一种经典的方式是 不同分组对应不同key ，key 又存在redis里用于分布式限流】

四、治理

4.1 feign会failover吗

4.2

五、