站長資訊網(wǎng)
最全最豐富的資訊網(wǎng)站

PHP 微服務(wù)集群搭建 – Hyperf

微服務(wù)架構(gòu)

微服務(wù)的概念由 Martin Fowler 于2014年3月提出:

微服務(wù)架構(gòu)是一種架構(gòu)模式,它提倡將單一應(yīng)用程序劃分成一組小的服務(wù),服務(wù)之間相互協(xié)調(diào)、互相配合,為用戶提供最終價值。每個服務(wù)運行在其獨立的進(jìn)程中,服務(wù)和服務(wù)之間采用輕量級的通信機制相互溝通。每個服務(wù)都圍繞著具體的業(yè)務(wù)進(jìn)行構(gòu)建,并且能夠被獨立的部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。另外,應(yīng)盡量避免統(tǒng)一的、集中的服務(wù)管理機制,對具體的一個服務(wù)而言,應(yīng)根據(jù)業(yè)務(wù)上下文,選擇合適的語言、工具對其進(jìn)行構(gòu)建。

下圖是一個電商系統(tǒng)的微服務(wù)架構(gòu)圖:

PHP 微服務(wù)集群搭建 - Hyperf

微服務(wù)架構(gòu)與單體應(yīng)用相比,具有以下優(yōu)點:

1、每個服務(wù)都比較簡單,只關(guān)注于一個業(yè)務(wù)功能;

2、微服務(wù)架構(gòu)方式是松耦合的,每個服務(wù)可以獨立測試、部署、升級、發(fā)布;

3、每個微服務(wù)可由不同團(tuán)隊獨立開發(fā),可以各自選擇最佳及最合適的不同的編程語言與工具;

4、每個服務(wù)可以根據(jù)需要進(jìn)行水平擴展,提高系統(tǒng)并發(fā)能力。

沒有銀彈,微服務(wù)架構(gòu)在帶來諸多優(yōu)點的同時,也會有如下缺點:

1、微服務(wù)架構(gòu)提高了系統(tǒng)的復(fù)雜度,增加了運維開銷及成本。如單體應(yīng)用可能只需部署至一小片應(yīng)用服務(wù)集群,而微服務(wù)架構(gòu)可能變成需要構(gòu)建/測試/部署/運行數(shù)十個獨立的服務(wù),并可能需要支持多種語言和環(huán)境;

2、作為一種分布式系統(tǒng),微服務(wù)架構(gòu)引入了其他若干問題,例如消息序列化、網(wǎng)絡(luò)延遲、異步機制、容錯處理、服務(wù)雪崩等;

3、服務(wù)管理的復(fù)雜性,如服務(wù)的注冊、發(fā)現(xiàn)、降級、熔斷等問題;

4、服務(wù)與服務(wù)之間存在相互調(diào)用的情況,為排查系統(tǒng)故障帶來巨大挑戰(zhàn)。

可以說,正是傳統(tǒng)應(yīng)用架構(gòu)的系統(tǒng)變得日益臃腫,面臨難以維護(hù)、擴展的問題,同時容器化技術(shù)(Docker)的蓬勃發(fā)展和 DevOps 思想的日漸成熟,催生了新的架構(gòu)設(shè)計風(fēng)格 – 微服務(wù)架構(gòu)的出現(xiàn)。

RPC 框架

微服務(wù)架構(gòu)中的各個服務(wù)通常不在同一個機器上,甚至不會在同一個網(wǎng)絡(luò)環(huán)境里,因此微服務(wù)之間如何調(diào)用是一個亟待解決的問題,我們通常使用 RPC 協(xié)議來解決:

RPC(Remote Procedure Call),即遠(yuǎn)程過程調(diào)用,是一個計算機通信協(xié)議。該協(xié)議允許運行于一臺計算機的程序調(diào)用另一臺計算機的子程序,而程序員無需額外地為這個交互作用編程。——維基百科

實現(xiàn)了 RPC 協(xié)議的框架,可以讓服務(wù)方和調(diào)用方屏蔽各種底層細(xì)節(jié),讓調(diào)用方像調(diào)用本地函數(shù)一樣調(diào)用遠(yuǎn)端的函數(shù)(服務(wù))。RPC 框架一般為服務(wù)端和客戶端提供了序列化、反序列化、連接池管理、負(fù)載均衡、故障轉(zhuǎn)移、隊列管理、超時管理、異步管理等職能。在網(wǎng)上找到一個說明 RPC 框架工作原理圖:

PHP 微服務(wù)集群搭建 - Hyperf

目前,根據(jù)序列化數(shù)據(jù)時采用的技術(shù)的不同,可分為 JSON-RPC 和 gRPC 兩種:

1、JSON-RPC 是一種基于 JSON 格式的輕量級的 RPC 協(xié)議標(biāo)準(zhǔn),可基于 HTTP 協(xié)議來傳輸,或直接基于 TCP 協(xié)議來傳輸。 JSON-RPC 優(yōu)點是易于使用和閱讀。

2、gRPC 是一個高性能、通用的開源 RPC 框架,其由 Google 主要面向移動應(yīng)用開發(fā)并基于 HTTP/2 協(xié)議標(biāo)準(zhǔn)而設(shè)計,基于 ProtoBuf (Protocol Buffers) 序列化協(xié)議開發(fā),且支持眾多開發(fā)語言。 gRPC 具有低延遲、高效率、高擴展性、支持分布式等優(yōu)點。

Consul

現(xiàn)在有了 RPC 框架,我們就可以只考慮服務(wù)與服務(wù)之間的業(yè)務(wù)調(diào)用而不用考慮底層傳輸細(xì)節(jié)。此時,如果服務(wù) A 想調(diào)用服務(wù) B 時,我們可以在服務(wù) A 中配置服務(wù) B 的 IP 地址和端口,然后剩下的傳輸細(xì)節(jié)就交給 RPC 框架。這在微服務(wù)規(guī)模很小的情況下是沒有問題的,但是在服務(wù)規(guī)模很大、而且每個服務(wù)不止部署一個實例的情況下會面臨巨大挑戰(zhàn)。比如,服務(wù) B 部署了三個實例,這時候服務(wù) A 想調(diào)用服務(wù) B 該請求哪個實例的 IP ?假如服務(wù) B 部署的三個實例有兩個都掛掉了,服務(wù) A 可能會依舊去請求掛掉的實例,服務(wù)將不可用。將 IP 地址和端口寫成配置文件顯得很不靈活,微服務(wù)架構(gòu)往往要保證高可用及動態(tài)伸縮。

因此,我們需要一個服務(wù)注冊與服務(wù)發(fā)現(xiàn)的工具,能夠動態(tài)地變更服務(wù)信息,并且找到可用的服務(wù)的 IP 地址和端口。目前市面上服務(wù)發(fā)現(xiàn)的工具有很多,如 Consul、ZooKeeper 、Etcd、Doozerd 等,本文主要以 Consul 軟件為例。

Consul 是一個支持多數(shù)據(jù)中心、分布式高可用的服務(wù)發(fā)現(xiàn)和配置共享的服務(wù)軟件,由 HashiCorp 公司用 Go 語言開發(fā), 基于 Mozilla Public License 2.0 的協(xié)議進(jìn)行開源。 Consul 支持健康檢查,并允許 HTTP 、gRPC 和 DNS 協(xié)議調(diào)用 API 存儲鍵值對。

下面是引入服務(wù)注冊與服務(wù)發(fā)現(xiàn)工具后的架構(gòu)圖:

PHP 微服務(wù)集群搭建 - Hyperf

在這個架構(gòu)中:

首先 S-B 的實例啟動后將自身的服務(wù)信息(主要是服務(wù)所在的 IP 地址和端口號)注冊到 Consul 中。

Consul 會對所有注冊的服務(wù)做健康檢查,以此來確定哪些服務(wù)實例可用哪些不可用。

S-A 啟動后就可以通過訪問 Consul 來獲取到所有健康的 S-B 實例的 IP 和端口,并將這些信息放入自己的內(nèi)存中,S-A 就可用通過這些信息來調(diào)用 S-B。

S-A 可以通過監(jiān)聽 Consul 來更新存入內(nèi)存中的 S-B 的服務(wù)信息。比如 S-B-1 掛了,健康檢查機制就會將其標(biāo)為不可用,這樣的信息變動就被 S-A 監(jiān)聽到了,S-A 就更新自己內(nèi)存中 S-B-1 的服務(wù)信息。

可見, Consul 軟件除了服務(wù)注冊和服務(wù)發(fā)現(xiàn)的功能之外,還提供了健康檢查和狀態(tài)變更通知的功能。

Hyperf

對于 Java 開發(fā)者來說,有技術(shù)相當(dāng)成熟的 Dubbo 和 Spring Cloud 微服務(wù)框架可供選擇。作為一名 PHPer,我用 Google 查了一下「PHP + 微服務(wù)」,發(fā)現(xiàn)有用的相關(guān)內(nèi)容少之又少 ,沒有什么實質(zhì)性的參考價值,無限惆悵。。。幸好,有大神在基于 Swoole 擴展的基礎(chǔ)上,實現(xiàn)了高性能、高靈活性的 PHP 協(xié)程框架 Hyperf ,并提供了微服務(wù)架構(gòu)的相關(guān)組件。

Hyperf 是基于 Swoole 4.3+ 實現(xiàn)的高性能、高靈活性的 PHP 協(xié)程框架,內(nèi)置協(xié)程服務(wù)器及大量常用的組件,性能較傳統(tǒng)基于 PHP-FPM 的框架有質(zhì)的提升,提供超高性能的同時,也保持著極其靈活的可擴展性,標(biāo)準(zhǔn)組件均基于 PSR 標(biāo)準(zhǔn) 實現(xiàn),基于強大的依賴注入設(shè)計,保證了絕大部分組件或類都是 可替換 與 可復(fù)用 的。

于是,我在學(xué)習(xí)了微服務(wù)架構(gòu)相關(guān)的基礎(chǔ)知識之后,使用 Hyperf 框架構(gòu)建了一個基于 PHP 的微服務(wù)集群,這是項目源碼地址:https://github.com/Jochen-z/p…。該項目使用 Dokcer 搭建,docker-compose.yml 代碼如下:

version: "3" services:   consul-server-leader:     image: consul:latest     container_name: consul-server-leader     command: "agent -server -bootstrap -ui -node=consul-server-leader -client=0.0.0.0"     environment:       - CONSUL_BIND_INTERFACE=eth0     ports:       - "8500:8500"     networks:       - microservice   microservice-1:     build:       context: .     container_name: "microservice-1"     command: "php bin/hyperf.php start"     depends_on:       - "consul-server-leader"     volumes:       - ./www/microservice-1:/var/www     networks:       - microservice     tty: true   microservice-2:     build:       context: .     container_name: "microservice-2"     command: "php bin/hyperf.php start"     depends_on:       - "consul-server-leader"     volumes:       - ./www/microservice-2:/var/www     networks:       - microservice     tty: true   app:     build:       context: .     container_name: "app"     command: "php bin/hyperf.php start"     depends_on:       - "microservice-1"     volumes:       - ./www/web:/var/www     ports:       - "9501:9501"     networks:       - microservice     tty: true networks:   microservice:     driver: bridge volumes:   microservice:     driver: local

這里啟動了一個 Consul 容器 consul-server-leader 作為服務(wù)注冊和服務(wù)發(fā)現(xiàn)的組件,容器 microservice-1 和 microservice-2 分別提供了加法運算和除法運算的服務(wù)。容器 app 作為服務(wù)調(diào)用方,配置了 consul-server-leader 容器的 URL,通過訪問 consul-server-leader 獲取 microservice-1 和 microservice-2 服務(wù)的 IP 地址和端口,然后 app 通過 RPC 協(xié)議調(diào)用加法運算和除法運算的服務(wù)獲取結(jié)果并返回給用戶。

app 容器為 Web 應(yīng)用,部署了一個 Hyperf 項目并對外提供 HTTP 服務(wù)。例如,在 AppControllerIndexController 控制器里有 add 方法:

public function add(AdditionService $addition) {   $a = (int)$this->request->input('a', 1); # 接受前端用戶參數(shù)   $b = (int)$this->request->input('b', 2);   return [     'a' => $a,     'b' => $b,     'add' => $addition->add($a, $b) # RPC調(diào)用   ]; }

在 AppJsonRpcAdditionService 中 add 的實現(xiàn):

class AdditionService extends AbstractServiceClient {     /**      * 定義對應(yīng)服務(wù)提供者的服務(wù)名稱      * @var string      */     protected $serviceName = 'AdditionService';     /**      * 定義對應(yīng)服務(wù)提供者的服務(wù)協(xié)議      * @var string      */     protected $protocol = 'jsonrpc-http';     public function add(int $a, int $b): int     {         return $this->__request(__FUNCTION__, compact('a', 'b'));     } }

繼承了 AbstractServiceClient 即可創(chuàng)建一個微服務(wù)客戶端請求類,Hyperf 在底層幫我們實現(xiàn)了與 Consul 和服務(wù)提供者交互的細(xì)節(jié),我們只要 AdditionService 類里的 add 方法即可遠(yuǎn)程調(diào)用 microservice-1 和 microservice-2 提供的服務(wù)。

至此,PHP 微服務(wù)集群搭建就完成了!

贊(0)
分享到: 更多 (0)
網(wǎng)站地圖   滬ICP備18035694號-2    滬公網(wǎng)安備31011702889846號
十八18禁国产精品www| 亚洲永久永久永久永久永久精品| 国产精品久久毛片| 久久国产精品2020免费m3u8| 久久精品中文字幕第23页| 精品96在线观看影院| 亚洲?V无码成人精品区日韩| 国产精品高清尿小便嘘嘘| 精品久久久久国产免费| 国产毛片片精品天天看视频| 亚洲综合无码精品一区二区三区| 国产精品午夜爆乳美女视频| 久久水蜜桃亚洲AV无码精品| 久久91精品久久91综合| 国产综合精品久久亚洲| 国产区精品福利在线观看精品| 亚洲国产精品国产自在在线 | 国产精品久久久福利| 久久精品免费全国观看国产| 亚洲成a人片在线观看精品| 9i9精品国产免费久久| 国产精品麻豆入口| 国产精品久久久天天影视香蕉| 七次郎在线视频精品视频| 精品一区二区三区电影| 美日韩一区二区三区| 美日韩一区二区三区| 日韩有码在线视频| 久久乐国产综合亚洲精品| 国产精品爽爽va在线观看网站| 91午夜精品亚洲一区二区三区| 2021国内精品久久久久影院 | 久久精品aⅴ无码中文字字幕| 凹凸69堂国产成人精品视频| 国产精品亚洲专区无码WEB | 免费视频精品一区二区| 国产亚洲日韩在线a不卡| 日韩在线一区视频| 亚洲A∨午夜成人片精品网站 | 亚洲国产精品嫩草影院在线观看 | 日韩精品电影一区|