近些年微服務(wù)架構(gòu)大行其道，趁著最近有時(shí)間，來(lái)?yè)v鼓搗鼓微服務(wù)是怎么一回事。
微服務(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)：
沒(méi)有銀彈，微服務(wù)架構(gòu)在帶來(lái)諸多優(yōu)點(diǎn)的同時(shí)，也會(huì)有如下缺點(diǎ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 兩種：
- JSON-RPC 是一種基于 JSON 格式的輕量級(jí)的 RPC 協(xié)議標(biāo)準(zhǔn)，可基于 HTTP 協(xié)議來(lái)傳輸，或直接基于 TCP 協(xié)議來(lái)傳輸。 JSON-RPC 優(yōu)點(diǎn)是易于使用和閱讀。
- 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 地址和端口寫成配置文件顯得很不靈活，微服務(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 代碼如下：
這里啟動(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ù)。例如，在 App/Controller/IndexController 控制器里有 add 方法：
在 App/JsonRpc/AdditionService 中 add 的實(shí)現(xiàn)：
繼承了 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ù)集群搭建就完成了!
【責(zé)任編輯：華軒 TEL：（010）68476606】