這篇文章要跟大家介紹如何使用 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` 的高效能與穩定性,
優雅的服務治理
#服務註冊與發現微服務治理過程中,經常涉及註冊啟動的服務到第三方集群,例如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); } }
以上就是一个简单的 Apollo 配置拉取,Swoft-Apollo
除此方法外,还提供了更多的使用方法。
官方链接
- Github
- Doc
- swoft-cloud/community
推荐学习:php视频教程
以上是如何使用 PHP 實作微服務?的詳細內容。更多資訊請關注PHP中文網其他相關文章!

本文比較了酸和基本數據庫模型,詳細介紹了它們的特徵和適當的用例。酸優先確定數據完整性和一致性,適合財務和電子商務應用程序,而基礎則側重於可用性和

本文討論了確保PHP文件上傳的確保,以防止諸如代碼注入之類的漏洞。它專注於文件類型驗證,安全存儲和錯誤處理以增強應用程序安全性。

本文討論了在PHP中實施API速率限制的策略,包括諸如令牌桶和漏水桶等算法,以及使用Symfony/Rate-limimiter之類的庫。它還涵蓋監視,動態調整速率限制和手

本文討論了使用password_hash和pyspasswify在PHP中使用密碼的好處。主要論點是,這些功能通過自動鹽,強大的哈希算法和SECH來增強密碼保護

本文討論了OWASP在PHP和緩解策略中的十大漏洞。關鍵問題包括注射,驗證損壞和XSS,並提供用於監視和保護PHP應用程序的推薦工具。


熱AI工具

Undresser.AI Undress
人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover
用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

AI Hentai Generator
免費產生 AI 無盡。

熱門文章

熱工具

Atom編輯器mac版下載
最受歡迎的的開源編輯器

MantisBT
Mantis是一個易於部署的基於Web的缺陷追蹤工具,用於幫助產品缺陷追蹤。它需要PHP、MySQL和一個Web伺服器。請查看我們的演示和託管服務。

ZendStudio 13.5.1 Mac
強大的PHP整合開發環境

EditPlus 中文破解版
體積小,語法高亮,不支援程式碼提示功能

SecLists
SecLists是最終安全測試人員的伙伴。它是一個包含各種類型清單的集合,這些清單在安全評估過程中經常使用,而且都在一個地方。 SecLists透過方便地提供安全測試人員可能需要的所有列表,幫助提高安全測試的效率和生產力。清單類型包括使用者名稱、密碼、URL、模糊測試有效載荷、敏感資料模式、Web shell等等。測試人員只需將此儲存庫拉到新的測試機上,他就可以存取所需的每種類型的清單。