微服務架構
微服務的概念由Martin Fowler 於2014年3月提出：
微服務架構是一種架構模式，它提倡將單一應用程式劃分成一組小型的服務，服務之間相互協調、相互配合，為用戶提供最終價值。每個服務運作在其獨立的進程中，服務和服務之間採用輕量級的通訊機制相互溝通。每個服務都圍繞著具體的業務進行構建，並且能夠被獨立的部署到生產環境、類生產環境等。另外，應盡量避免統一的、集中的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行建構。
下圖是一個電商系統的微服務架構圖：
#微服務架構與單體應用相比，具有以下優點：
1、每個服務都比較簡單，只專注於一個業務功能；
2、微服務架構方式是鬆散耦合的，每個服務可以獨立測試、部署、升級、發布；
3、每個微服務可由不同團隊獨立開發，可以各自選擇最佳及最合適的不同的程式語言與工具；
4、每個服務可以根據需要進行水平擴展，提高系統並發能力。
沒有銀彈，微服務架構在帶來許多優點的同時，也會有以下缺點：
1、微服務架構提高了系統的複雜度，增加了維運開銷及成本。如單體應用可能只需部署至一小片應用服務集群，而微服務架構可能變成需要建置/測試/部署/運行數十個獨立的服務，並可能需要支援多種語言和環境；
2、作為一種分散式系統，微服務架構引入了其他若干問題，例如訊息序列化、網路延遲、非同步機制、容錯處理、服務雪崩等；
3、服務管理的複雜性，如服務的註冊、發現、降級、熔斷等問題；
4、服務與服務之間存在相互呼叫的情況，為排查系統故障帶來巨大挑戰。
可以說，正是傳統應用架構的系統變得日益臃腫，面臨難以維護、擴展的問題，同時容器化技術（Docker）的蓬勃發展和DevOps 思想的日漸成熟，催生了新的架構設計風格– 微服務架構的出現。
RPC 框架
微服務架構中的各個服務通常不在同一個機器上，甚至不會在同一個網路環境裡，因此微服務之間如何調用是亟待解決的問題，我們通常使用RPC 協定來解決：
RPC（Remote Procedure Call），即遠端過程調用，是一個電腦通訊協定。該協議允許運行於一台電腦的程式呼叫另一台電腦的子程序，而程式設計師無需額外地為這個交互作用編程。 ——維基百科
實作了 RPC 協定的框架，可以讓服務方和呼叫方屏蔽各種底層細節，讓呼叫方像呼叫本地函數一樣呼叫遠端的函數（服務）。 RPC 框架一般為服務端和用戶端提供了序列化、反序列化、連線池管理、負載平衡、故障轉移、佇列管理、逾時管理、非同步管理等職能。在網路上找到一個說明RPC 框架工作原理圖：
目前，根據序列化資料時所採用的技術的不同，可分為JSON-RPC 和gRPC 兩種：
1、JSON-RPC 是一種基於JSON 格式的輕量級的RPC 協定標準，可基於HTTP 協定來傳輸，或直接基於TCP 協定來傳輸。 JSON-RPC 優點是易於使用和閱讀。
2、gRPC 是一個高效能、通用的開源RPC 框架，其由Google 主要面向行動應用開發並基於HTTP/2 協定標準而設計，基於ProtoBuf (Protocol Buffers) 序列化協定開發，且支援眾多開發語言。 gRPC 具有低延遲、高效率、高擴展性、支援分散式等優點。
Consul
現在有了 RPC 框架，我們就可以只考慮服務與服務之間的業務呼叫而不用考慮底層傳輸細節。此時，如果服務 A 想要呼叫服務 B 時，我們可以在服務 A 中設定服務 B 的 IP 位址和連接埠，然後剩下的傳輸細節交給 RPC 框架。這在微服務規模很小的情況下是沒有問題的，但是在服務規模很大、而且每個服務不只部署一個實例的情況下會面臨巨大挑戰。例如，服務 B 部署了三個實例，這時候服務 A 想要呼叫服務 B 該請求哪個實例的 IP ？假如服務 B 部署的三個實例有兩個都掛掉了，服務 A 可能會依舊去請求掛掉的實例，服務將不可用。將 IP 位址和連接埠寫成設定檔顯得很不靈活，微服務架構往往要確保高可用及動態伸縮。
因此，我們需要一個服務註冊與服務發現的工具，能夠動態地變更服務信息，並且找到可用的服務的 IP 位址和連接埠。目前市面上服務發現的工具很多，如 Consul、ZooKeeper 、Etcd、Doozerd 等，本文主要以 Consul 軟體為例。
Consul 是一個支援多資料中心、分散式高可用的服務發現和配置共享的服務軟體，由 HashiCorp 公司用 Go 語言開發, 基於 Mozilla Public License 2.0 的協定進行開源。 Consul 支援健康檢查，並允許 HTTP 、gRPC 和 DNS 協定呼叫 API 儲存鍵值對。
下面是引入服務註冊與服務發現工具後的架構圖：
#在這個架構中：
首先S-B 的實例啟動後將自身的服務資訊（主要是服務所在的IP 位址和連接埠號碼）註冊到Consul 中。
Consul 會對所有註冊的服務做健康檢查，以此來決定哪些服務實例可用哪些不可用。
S-A 啟動後就可以透過存取 Consul 來獲取到所有健康的 S-B 實例的 IP 和端口，並將這些資訊放入自己的記憶體中，S-A 就可用透過這些資訊來呼叫 S-B。
S-A 可以透過監聽 Consul 來更新存入記憶體中的 S-B 的服務資訊。例如 S-B-1 掛了，健康檢查機制就會將其標為不可用，這樣的資訊變動就被 S-A 監聽到了，S-A 就更新自己記憶體中 S-B-1 的服務資訊。
可見， Consul 軟體除了服務註冊和服務發現的功能之外，還提供了健康檢查和狀態變更通知的功能。
Hyperf
對於 Java 開發者來說，有技術相當成熟的 Dubbo 和 Spring Cloud 微服務框架可供選擇。身為一名 PHPer，我用 Google 查了一下「PHP 微服務」，發現有用的相關內容少之又少 ，沒有什麼實質性的參考價值，無限惆悵。 。 。幸好，有大神在基於 Swoole 擴充的基礎上，實現了高效能、高彈性的 PHP 協程框架 Hyperf ，並提供了微服務架構的相關元件。
Hyperf 是基於Swoole 4.3 實現的高效能、高靈活性的PHP 協程框架，內建協程伺服器及大量常用的元件，效能較傳統基於PHP-FPM 的框架有質的提升，提供超高性能的同時，也保持著極其靈活的可擴展性，標準組件均基於PSR 標準實現，基於強大的依賴注入設計，保證了絕大部分組件或類都是可替換與可復用的。
於是，我在學習了微服務架構相關的基礎知識之後，使用Hyperf 框架構建了一個基於PHP 的微服務集群，這是項目源碼地址：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 作為服務註冊和服務發現的元件，容器microservice-1 和microservice-2 分別提供了加法運算和除法運算的服務。容器app 作為服務調用方，配置了consul-server-leader 容器的URL，透過存取consul-server-leader 取得microservice-1 和microservice-2 服務的IP 位址和端口，然後app 透過RPC 協定呼叫加法運算和除法運算的服務取得結果並回傳給使用者。
app 容器為 Web 應用，部署了一個 Hyperf 專案並對外提供 HTTP 服務。例如，在App\Controller\IndexController 控制器裡有add 方法：
public function add(AdditionService $addition)
{
$a = (int)$this->request->input('a', 1); # 接受前端用户参数
$b = (int)$this->request->input('b', 2);
return [
'a' => $a,
'b' => $b,
'add' => $addition->add($a, $b) # RPC调用
];
}在App\JsonRpc\AdditionService 中add 的實作：
class AdditionService extends AbstractServiceClient
{
/**
* 定义对应服务提供者的服务名称
* @var string
*/
protected $serviceName = 'AdditionService';
/**
* 定义对应服务提供者的服务协议
* @var string
*/
protected $protocol = 'jsonrpc-http';
public function add(int $a, int $b): int
{
return $this->__request(__FUNCTION__, compact('a', 'b'));
}
}繼承了AbstractServiceClient 即可建立一個微服務客戶端請求類，Hyperf 在底層幫我們實作了與Consul 和服務提供者互動的細節，我們只要AdditionService 類別裡的add 方法即可遠端呼叫microservice-1 和microservice-2 提供的服務。
至此，PHP 微服務叢集搭建就完成了！
以上是PHP 微服務叢集建置 - Hyperf的詳細內容。更多資訊請關注PHP中文網其他相關文章！
