PRC服务治理组件封装

Posted 2021-04-25 家园叮咚

一、RPC启动之前准备

  配置文件启动的时候，通过指定要启动的监听服务，使用多端口监听的方式启动rpc服务

   组件扫描等信息，src/AutoLoader.php 是一个组件必须存在的文件，swoft依据它来确定要扫描的目录，并且把相应在框架启动的时候会加载beans方法所返回的信息，放入到bean容器当中

Client启动时通过注解rpc接口的注解，通过代理类解析接口，并且加载对象附加到容器当中，在控制器调用方法时

二、RPC启动之后的流程

请求过来之后触发dispatch

在服务分发类当中调用serviceHandle处理请求

请求在handle当中对应加载中间件去处理

通过获取发送过来的打包数据，决定调用相应的接口方法

三、服务熔断跟降级

   熔断技术可以说是一种“智能化的容错”，当调用满足失败次数，失败比例就会触发熔断器打开，有程序自动切断当前的RPC调用,来防止错误进一步扩大。实现一个熔断器主要是考虑三种模式，关闭，打开，半开。

  我们在处理异常的时候，要根据具体的业务情况来决定处理方式，比如我们调用商品接口，对方只是临时做了降级处理，那么作为网关调用就要切到可替换的服务上来执行或者获取托底数据，给用户友好提示。还有要区分异常的类型，比如依赖的服务崩溃了，这个可能需要花费比较久的时间来解决。也可能是由于服务器负载临时过高导致超时。作为熔断器应该能够甄别这种异常类型，从而根据具体的错误类型调整熔断策略。增加手动设置，在失败的服务恢复时间不确定的情况下，管理员可以手动强制切换熔断状态。最后，熔断器的使用场景是调用可能失败的远程服务程序或者共享资源。如果是本地缓存本地私有资源，使用熔断器则会增加系统的额外开销。还要注意，熔断器不能作为应用程序中业务逻辑的异常处理替代品。

  有一些异常比较顽固，突然发生，无法预测，而且很难恢复，并且还会导致级联失败（举个例子，假设一个服务集群的负载非常高，如果这时候集群的一部分挂掉了，还占了很大一部分资源，整个集群都有可能遭殃）。如果我们这时还是不断进行重试的话，结果大多都是失败的。因此，此时我们的应用需要立即进入失败状态(fast-fail)，并采取合适的方法进行恢复。

  我们可以用状态机来实现CircuitBreaker，它有以下三种状态：

关闭( Closed )：默认情况下Circuit Breaker是关闭的，此时允许操作执行。CircuitBreaker内部记录着最近失败的次数，如果对应的操作执行失败，次数就会续一次。如果在某个时间段内，失败次数（或者失败比率）达到阈值，CircuitBreaker会转换到开启( Open )状态。在开启状态中，Circuit Breaker会启用一个超时计时器，设这个计时器的目的是给集群相应的时间来恢复故障。当计时器时间到的时候，CircuitBreaker会转换到半开启( Half-Open )状态。

开启( Open )：在此状态下，执行对应的操作将会立即失败并且立即抛出异常。

半开启( Half-Open )：在此状态下，Circuit Breaker会允许执行一定数量的操作。如果所有操作全部成功，CircuitBreaker就会假定故障已经恢复，它就会转换到关闭状态，并且重置失败次数。如果其中 任意一次 操作失败了，Circuit Breaker就会认为故障仍然存在，所以它会转换到开启状态并再次开启计时器（再给系统一些时间使其从失败中恢复）