教你利用 PHP 实现微服务( 二 ) _小知识

【教你利用 PHP 实现微服务】断路器（Circuit Breaker）模式就是为了防止在分布式系统中出现这种瀑布似的连锁反应导致的灾难。
基本的断路器模式下，保证了断路器在open状态时，保护supplier不会被调用，但我们还需要额外的措施可以在supplier恢复服务后，可以重置断路器。一种可行的办法是断路器定期探测supplier的服务是否恢复，一但恢复，就将状态设置成close 。断路器进行重试时的状态为半开（half-open）状态。
熔断器的使用想到简单且功能强大，使用一个 @Breaker 注解即可，Swoft 的熔断器可以用于任何场景, 例如服务调用的时候使用, 请求第三方的时候都可以对它进行熔断降级
<?php declare(strict_types=1);namespace AppModelLogic;use Exception;use SwoftBeanAnnotationMappingBean;use SwoftBreakerAnnotationMappingBreaker;/** * Class BreakerLogic * * @since 2.0 * * @Bean() */class BreakerLogic{/*** @Breaker(fallback="loopFallback")** @return string* @throws Exception*/public function loop(): string{// Do somethingthrow new Exception('Breaker exception');}/*** @return string* @throws Exception*/public function loopFallback(): string{// Do something}}服务限流
限流、熔断、降级这个强调多少遍都不过分，因为确实很重要。服务不行的时候一定要熔断。限流是一个保护自己最大的利器，如果没有自我保护机制，不管有多少连接都会接收，如果后端处理不过来，前端流量又很大的时候肯定就挂了。
限流是对稀缺资源访问时，比如秒杀，抢购的商品时，来限制并发和请求的数量，从而有效的进行削峰并使得流量曲线平滑。限流的目的是对并发访问和并发请求进行限速，或者一个时间窗口内请求进行限速从而来保护系统，一旦达到或超过限制速率就可以拒绝服务，或者进行排队等待等。
Swoft 限流器底层采用的是令牌桶算法，底层依赖于 redis 实现分布式限流。
Swoft 限速器不仅可以限流控制器，也可以限制任何 bean 里面的方法，可以控制方法的访问速率。这里以下面使用示例详解
<?php declare(strict_types=1);namespace AppModelLogic;use SwoftBeanAnnotationMappingBean;use SwoftLimiterAnnotationMappingRateLimiter;/** * Class LimiterLogic * * @since 2.0 * * @Bean() */class LimiterLogic{/*** @RequestMapping()* @RateLimiter(rate=20, fallback="limiterFallback")** @param Request $request** @return array*/public function requestLimiter2(Request $request): array{$uri = $request->getUriPath();return ['requestLimiter2', $uri];}/*** @param Request $request** @return array*/public function limiterFallback(Request $request): array{$uri = $request->getUriPath();return ['limiterFallback', $uri];}}key 这里支持 symfony/expression-language 表达式，如果被限速会调用 fallback中定义的limiterFallback 方法
配置中心说起配置中心前我们先说说配置文件，我们并不陌生，它提供我们可以动态修改程序运行能力。引用别人的一句话就是：

系统运行时(runtime)飞行姿态的动态调整！

我可以把我们的工作称之为在快速飞行的飞机上修理零件。我们人类总是无法掌控和预知一切。对于我们系统来说，我们总是需要预留一些控制线条，以便在我们需要的时候做出调整，控制系统方向（如灰度控制、限流调整），这对于拥抱变化的互联网行业尤为重要。
对于单机版，我们称之为配置（文件）；对于分布式集群系统，我们称之为配置中心（系统）;
到底什么是分布式配置中心
随着业务的发展、微服务架构的升级，服务的数量、程序的配置日益增多（各种微服务、各种服务器地址、各种参数），传统的配置文件方式和数据库的方式已无法满足开发人员对配置管理的要求：
安全性：配置跟随源代码保存在代码库中，容易造成配置泄漏；
时效性：修改配置，需要重启服务才能生效；
局限性：无法支持动态调整：例如日志开关、功能开关；
因此，我们需要配置中心来统一管理配置！把业务开发者从复杂以及繁琐的配置中解脱出来，只需专注于业务代码本身，从而能够显著提升开发以及运维效率。同时将配置和发布包解藕也进一步提升发布的成功率，并为运维的细力度管控、应急处理等提供强有力的支持。

关于分布式配置中心，网上已经有很多开源的解决方案，例如：
Apollo是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。