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

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

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

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

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

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

2、微服務(wù)架構(gòu)方式是松耦合的，每個(gè)服務(wù)可以獨(dú)立測(cè)試、部署、升級(jí)、發(fā)布；

3、每個(gè)微服務(wù)可由不同團(tuán)隊(duì)獨(dú)立開(kāi)發(fā)，可以各自選擇最佳及最合適的不同的編程語(yǔ)言與工具；

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

沒(méi)有銀彈，微服務(wù)架構(gòu)在帶來(lái)諸多優(yōu)點(diǎn)的同時(shí)，也會(huì)有如下缺點(diǎn)：

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

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

3、服務(wù)管理的復(fù)雜性，如服務(wù)的注冊(cè)、發(fā)現(xiàn)、降級(jí)、熔斷等問(wèn)題；

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

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

RPC 框架

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

RPC（Remote Procedure Call），即遠(yuǎn)程過(guò)程調(diào)用，是一個(gè)計(jì)算機(jī)通信協(xié)議。該協(xié)議允許運(yùn)行于一臺(tái)計(jì)算機(jī)的程序調(diào)用另一臺(tái)計(jì)算機(jī)的子程序，而程序員無(wú)需額外地為這個(gè)交互作用編程。——維基百科

實(shí)現(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)移、隊(duì)列管理、超時(shí)管理、異步管理等職能。在網(wǎng)上找到一個(gè)說(shuō)明 RPC 框架工作原理圖：

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

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

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

Consul

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

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

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

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

在這個(gè)架構(gòu)中：

首先 S-B 的實(shí)例啟動(dòng)后將自身的服務(wù)信息（主要是服務(wù)所在的 IP 地址和端口號(hào)）注冊(cè)到 Consul 中。

Consul 會(huì)對(duì)所有注冊(cè)的服務(wù)做健康檢查，以此來(lái)確定哪些服務(wù)實(shí)例可用哪些不可用。

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

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

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

Hyperf

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

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

于是，我在學(xué)習(xí)了微服務(wù)架構(gòu)相關(guān)的基礎(chǔ)知識(shí)之后，使用 Hyperf 框架構(gòu)建了一個(gè)基于 PHP 的微服務(wù)集群，這是項(xiàng)目源碼地址：https://github.com/Jochen-z/p…。該項(xiàng)目使用 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

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

app 容器為 Web 應(yīng)用，部署了一個(gè) Hyperf 項(xiàng)目并對(duì)外提供 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 的實(shí)現(xiàn)：

class AdditionService extends AbstractServiceClient {     /**      * 定義對(duì)應(yīng)服務(wù)提供者的服務(wù)名稱      * @var string      */     protected $serviceName = 'AdditionService';     /**      * 定義對(duì)應(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)建一個(gè)微服務(wù)客戶端請(qǐng)求類，Hyperf 在底層幫我們實(shí)現(xiàn)了與 Consul 和服務(wù)提供者交互的細(xì)節(jié)，我們只要 AdditionService 類里的 add 方法即可遠(yuǎn)程調(diào)用 microservice-1 和 microservice-2 提供的服務(wù)。

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