php微服务教你应用 PHP 实现微办事

我们必须采纳方法,按运用拆分，便是把原来的运用按照业务特点拆分成多个运用。
比如一个大型电商系统可能包含用户系统、商品系统、订单系统、评价系统等等，我们可以把他们独立出来形成一个个单独的运用。
多运用架构的特点是运用之间各自独立，不相互调用。

多运用虽然办理了运用臃肿问题，但运用之间相互独立，有些共同的业务或代码无法复用。

单一运用的办理方案

php微服务教你应用 PHP 实现微办事 SQL

对付一个大型的互联网系统，一样平常会包含多个运用，而且运用之间每每还存在共同的业务，并且运用之间还存在调用关系。
除此之外，对付大型的互联网系统还有一些其它的寻衅，比如如何应对急剧增长的用户，如何管理好研发团队快速迭代产品研发，如何保持产品升级更加稳定等等。

因此，为了使业务得到很好的复用，模块更加随意马虎拓展和掩护，我们希望业务与运用分离，某个业务不再属于一个运用，而是作为一个独立的做事单独进行掩护。
运用本身不再是一个臃肿的模块堆积，而是由一个个模块化的做事组件组合而成。

做事化

特点

那么采取做事化给有那些亮点的特色呢 ?

运用按业务拆分成做事

各个做事均可独立支配

做事可被多个运用共享

做事之间可以通信

架构上系统更加清晰

核心模块稳定，以做事组件为单位进行升级，避免了频繁发布带来的风险

开拓管理方便

单独团队掩护、事情分明，职责清晰

业务复用、代码复用

非常随意马虎拓展

做事化面临的寻衅

系统做事化之后, 增加了依赖关系繁芜, 也会增加做事与做事之间交互的次数. 在 fpm 的开拓模式下. 由于无法常驻内存给我们带来了, 每一次要求都要从零开始加载到退出进程, 增加了很多无用的开销, 数据库连接无法复用也得不到保护, 由于fpm因此进程为单位的fpm的进程数也决定了并发数, 这也是是fpm开拓大略给我们带来的问题. 以是说为什么现在互联网平台Java比较盛行了，.NET和PHP在这方面都弗成。
PHP非内存常驻的就不用说了。
除此之外，还有很多其他问题须要办理。

那么有没有好的方案呢？答案是有的，它便是-Swoft。
Swoft便是一个带有做事管理功能的RPC框架。
Swoft是首个 PHP常驻内存协程全栈框架, 基于高性能协程swoole打造的一个 PHP界的Spring Boot

Swoft 供应了类似 Dubbo 更为优雅的办法利用 RPC 做事, Swoft 性能是非常棒的有着类似Golang性能, 下面是对Swoft 性能的压测情形.

ab压力测试处理速率十分惊人, 在 i78代CPU, 16GB 内存下100000万个要求只用了5s韶光在fpm开拓模式下基本不可能达到. 这也足以证明Swoft` 的高性能和稳定性,

优雅的做事管理

做事注册与创造

微做事管理过程中，常常会涉及注册启动的做事到第三方集群，比如 consul / etcd 等等，以 Swoft 框架中利用 swoft-consul 组件，实现做事注册与创造为例。

实现逻辑

<?php declare(strict_types=1);namespace App\Common;use ReflectionException;use Swoft\Bean\Annotation\Mapping\Bean;use Swoft\Bean\Annotation\Mapping\Inject;use Swoft\Bean\Exception\ContainerException;use Swoft\Consul\Agent;use Swoft\Consul\Exception\ClientException;use Swoft\Consul\Exception\ServerException;use Swoft\Rpc\Client\Client;use Swoft\Rpc\Client\Contract\ProviderInterface;/ Class RpcProvider @since 2.0 @Bean() /class RpcProvider implements ProviderInterface{ / @Inject() @var Agent / private $agent; / @param Client $client @return array @throws ReflectionException @throws ContainerException @throws ClientException @throws ServerException @example [ 'host:port', 'host:port', 'host:port', ] / public function getList(Client $client): array { // Get health service from consul $services = $this->agent->services(); $services = [ ]; return $services; }}

做事熔断

在分布式环境下，特殊是微做事构造的分布式系统中，一个软件系统调用其余一个远程系统是非常普遍的。
这种远程调用的被调用方可能是其余一个进程，或者是跨网路的其余一台主机, 这种远程的调用和进程的内部调用最大的差异是，远程调用可能会失落败，或者挂起而没有任何回应，直到超时。
更坏的情形是，如果有多个调用者对同一个挂起的做事进行调用，那么就很有可能的是一个做事的超时等待迅速蔓延到全体分布式系统，引起连锁反应，从而花费掉全体分布式系统大量资源。
终极可能导致系统瘫痪。

断路器（Circuit Breaker）模式便是为了防止在分布式系统中涌现这种瀑布似的连锁反应导致的灾害。

基本的断路器模式下，担保了断路器在open状态时，保护supplier不会被调用，但我们还须要额外的方法可以在supplier规复做事后，可以重置断路器。
一种可行的办法是断路器定期探测supplier的做事是否规复，一旦规复，就将状态设置成close。
断路器进行重试时的状态为半开（half-open）状态。

熔断器的利用想到大略且功能强大，利用一个 @Breaker 表明即可，Swoft 的熔断器可以用于任何场景, 例如做事调用的时候利用, 要求第三方的时候都可以对它进行熔断降级

<?php declare(strict_types=1);namespace App\Model\Logic;use Exception;use Swoft\Bean\Annotation\Mapping\Bean;use Swoft\Breaker\Annotation\Mapping\Breaker;/ Class BreakerLogic @since 2.0 @Bean() /class BreakerLogic{ / @Breaker(fallback="loopFallback") @return string @throws Exception / public function loop(): string { // Do something throw new Exception('Breaker exception'); } / @return string @throws Exception / public function loopFallback(): string { // Do something }}

做事限流

限流、熔断、降级这个强调多少遍都不过分，由于确实很主要。
做事弗成的时候一定要熔断。
限流是一个保护自己最大的利器，如果没有自我保护机制，不管有多少连接都会吸收，如果后端处理不过来，前端流量又很大的时候肯定就挂了。

限流是对稀缺资源访问时，比如秒杀，抢购的商品时，来限定并发和要求的数量，从而有效的进行削峰并使得流量曲线平滑。
限流的目的是对并发访问和并发要求进行限速，或者一个韶光窗口内要求进行限速从而来保护系统，一旦达到或超过限定速率就可以谢绝做事，或者进行排队等待等。

Swoft 限流器底层采取的是令牌桶算法，底层依赖于 Redis 实现分布式限流。

Swoft 限速器不仅可以限流掌握器，也可以限定任何 bean 里面的方法，可以掌握方法的访问速率。
这里以下面利用示例详解

<?php declare(strict_types=1);namespace App\Model\Logic;use Swoft\Bean\Annotation\Mapping\Bean;use Swoft\Limiter\Annotation\Mapping\RateLimiter;/ 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是携程框架部门研发的分布式配置中央，能够集中化管理运用不同环境、不同集群的配置，配置修正后能够实时推送到运用端，并且具备规范的权限、流程管理等特性，适用于微做事配置管理场景。

以Apollo 为例，从远端配置中央拉取配置以及安全重启做事。
如果对 Apollo 不熟习，可以先看Swoft 扩展 Apollo 组件以及阅读 Apollo 官方文档。

以 Swoft 中利用 Apollo 为例，当 Apollo 配置变更后，重启做事(http-server / rpc-server/ ws-server)。
如下是一个 agent 例子：

<?php declare(strict_types=1);namespace App\Model\Logic;use Swoft\Apollo\Config;use Swoft\Apollo\Exception\ApolloException;use Swoft\Bean\Annotation\Mapping\Bean;use Swoft\Bean\Annotation\Mapping\Inject;/ Class ApolloLogic @since 2.0 @Bean() /class ApolloLogic{ / @Inject() @var Config / private $config; / @throws ApolloException / public function pull(): void { $data = $this->config->pull('application'); // Print data var_dump($data); }}