這篇文章要跟大家介紹如何使用 PHP 實作微服務？有一定的參考價值，有需要的朋友可以參考一下，希望對大家有幫助。
為什麼要說服務治理
隨著網路瀏覽越來越大。傳統的MVC 單一架構隨著應用程式規模的不斷擴大，應用模組不斷增加，整個應用也顯得越來越臃腫，維護起來也更加困難.
我們必須採取措施,按應用拆分，就是把原來的應用按照業務特點拆分成多個應用。例如一個大型電商系統可能包含使用者係統、商品系統、訂單系統、評估系統等等，我們可以把他們獨立出來形成一個個單獨的應用。多應用架構的特點是應用程式之間各自獨立 ，不互相呼叫。
多重應用雖然解決了應用臃腫問題，但應用程式之間相互獨立，有些共同的業務或程式碼無法重複使用。
對於一個大型的互聯網系統，一般會包含多個應用，而且應用之間往往還存在共同的業務，並且應用之間還存在調用關係。除此之外 ，對於大型的互聯網系統還有一些其它的挑戰，比如如何應對急劇增長的用戶，如何管理好研發團隊快速迭代產品研發，如何保持產品升級更加穩定等等 。
因此，為了使業務得到很好的複用，模組更加容易拓展和維護，我們希望業務與應用分離，某個業務不再屬於一個應用，而是作為一個獨立的服務單獨進行維護。應用本身不再是一個臃腫的模組堆積，而是由一個個模組化的服務組件組合而成。
那麼採用服務化給有那些亮點的特色呢?
系統服務化之後, 增加了依賴關係複雜, 也會增加服務與服務之間交互的次數. 在fpm 的開發模式下. 因為無法常駐內存給我們帶來了, 每一次請求都要從零開始加載到退出進程, 增加了很多無用的開銷, 資料庫連接無法復用也得不到保護, 由於fpm是以進程為單位的fpm的進程數也決定了並發數, 這也是fpm開發簡單給我們帶來的問題. 所以說為什麼現在互聯網平台Java比較流行了，.NET和PHP在這方面都不行。 PHP非記憶體常駐的就不用說了。除此之外，還有很多其他問題需要解決。
你可以想像常駐記憶體帶給我們的好處例如
#只啟動框架初始化 如果常駐記憶體我們只是在啟動的時候處理化框架初始化在記憶體中,專心處理請求
#連接復用，有些工程師並不能特別理解，如果不用連接池，來一個請求就發一個連線怎麼樣？這樣就會導致後端資源連結過多。對一些基礎服務來說，例如 Redis，資料庫，連線是個昂貴的消耗。
那麼有沒有好的方案呢？答案是有的，而且很多人都在用這個框架，它就是-Swoft。 Swoft就是一個有服務治理功能的RPC架構。 Swoft是首個 PHP常駐記憶體協程全端框架, 基於 Spring Boot提出的約定大於配置的核心概念
Swoft 提供了類似Dubbo 更為優雅的方式使用RPC 服務, Swoft 效能是非常棒的有著類似Golang效能, 下面是我的PC對Swoft 效能的壓力測試情況.
##ab壓力測試處理速度十分驚人, 在i78代CPU, 16GB 記憶體下100000萬個請求只花了5s時間在fpm開發模式下基本上不可能達到. 這也足以證明Swoft` 的高效能與穩定性,
<?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;
}
}@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 方法配置中心
我可以把我們的工作稱之為在快速飛行的飛機上修理零件。我們人類總是無法掌控和預知一切。對於我們系統來說，我們總是需要預留一些控制線條，以便在我們需要的時候做出調整，控制系統方向（如灰階控制、限流調整），這對於擁抱變化的網路產業尤其重要。
對於單機版，我們稱之為配置（檔案）；對於分散式叢集系統，我們稱之為配置中心（系統）;
到底什麼是分散式配置中心
因此，我们需要配置中心来统一管理配置！把业务开发者从复杂以及繁琐的配置中解脱出来，只需专注于业务代码本身，从而能够显著提升开发以及运维效率。同时将配置和发布包解藕也进一步提升发布的成功率，并为运维的细力度管控、应急处理等提供强有力的支持。
关于分布式配置中心，网上已经有很多开源的解决方案，例如：
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);
}
}以上就是一个简单的 Apollo 配置拉取，Swoft-Apollo 除此方法外，还提供了更多的使用方法。
推荐学习：php视频教程
以上是如何使用 PHP 實作微服務？的詳細內容。更多資訊請關注PHP中文網其他相關文章！
