近些年微服務架構(gòu)大行其道，趁著最近有時間，來搗鼓搗鼓微服務是怎么一回事。
微服務架構(gòu)
微服務的概念由 Martin Fowler 于2014年3月提出：
微服務架構(gòu)是一種架構(gòu)模式，它提倡將單一應用程序劃分成一組小的服務，服務之間相互協(xié)調(diào)、互相配合，為用戶提供最終價值。每個服務運行在其獨立的進程中，服務和服務之間采用輕量級的通信機制相互溝通。每個服務都圍繞著具體的業(yè)務進行構(gòu)建，并且能夠被獨立的部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。另外，應盡量避免統(tǒng)一的、集中的服務管理機制，對具體的一個服務而言，應根據(jù)業(yè)務上下文，選擇合適的語言、工具對其進行構(gòu)建。
下圖是一個電商系統(tǒng)的微服務架構(gòu)圖：
微服務架構(gòu)與單體應用相比，具有以下優(yōu)點：
沒有銀彈，微服務架構(gòu)在帶來諸多優(yōu)點的同時，也會有如下缺點：
可以說，正是傳統(tǒng)應用架構(gòu)的系統(tǒng)變得日益臃腫，面臨難以維護、擴展的問題，同時容器化技術(Docker)的蓬勃發(fā)展和 DevOps 思想的日漸成熟，催生了新的架構(gòu)設計風格 – 微服務架構(gòu)的出現(xiàn)。
RPC 框架
微服務架構(gòu)中的各個服務通常不在同一個機器上，甚至不會在同一個網(wǎng)絡環(huán)境里，因此微服務之間如何調(diào)用是一個亟待解決的問題，我們通常使用 RPC 協(xié)議來解決：
RPC(Remote Procedure Call)，即遠程過程調(diào)用，是一個計算機通信協(xié)議。該協(xié)議允許運行于一臺計算機的程序調(diào)用另一臺計算機的子程序，而程序員無需額外地為這個交互作用編程。——維基百科
實現(xiàn)了 RPC 協(xié)議的框架，可以讓服務方和調(diào)用方屏蔽各種底層細節(jié)，讓調(diào)用方像調(diào)用本地函數(shù)一樣調(diào)用遠端的函數(shù)(服務)。RPC 框架一般為服務端和客戶端提供了序列化、反序列化、連接池管理、負載均衡、故障轉(zhuǎn)移、隊列管理、超時管理、異步管理等職能。在網(wǎng)上找到一個說明 RPC 框架工作原理圖：
目前，根據(jù)序列化數(shù)據(jù)時采用的技術的不同，可分為 JSON-RPC 和 gRPC 兩種：
- JSON-RPC 是一種基于 JSON 格式的輕量級的 RPC 協(xié)議標準，可基于 HTTP 協(xié)議來傳輸，或直接基于 TCP 協(xié)議來傳輸。 JSON-RPC 優(yōu)點是易于使用和閱讀。
- gRPC 是一個高性能、通用的開源 RPC 框架，其由 Google 主要面向移動應用開發(fā)并基于 HTTP/2 協(xié)議標準而設計，基于 ProtoBuf (Protocol Buffers) 序列化協(xié)議開發(fā)，且支持眾多開發(fā)語言。 gRPC 具有低延遲、高效率、高擴展性、支持分布式等優(yōu)點。
Consul
現(xiàn)在有了 RPC 框架，我們就可以只考慮服務與服務之間的業(yè)務調(diào)用而不用考慮底層傳輸細節(jié)。此時，如果服務 A 想調(diào)用服務 B 時，我們可以在服務 A 中配置服務 B 的 IP 地址和端口，然后剩下的傳輸細節(jié)就交給 RPC 框架。這在微服務規(guī)模很小的情況下是沒有問題的，但是在服務規(guī)模很大、而且每個服務不止部署一個實例的情況下會面臨巨大挑戰(zhàn)。比如，服務 B 部署了三個實例，這時候服務 A 想調(diào)用服務 B 該請求哪個實例的 IP ?假如服務 B 部署的三個實例有兩個都掛掉了，服務 A 可能會依舊去請求掛掉的實例，服務將不可用。將 IP 地址和端口寫成配置文件顯得很不靈活，微服務架構(gòu)往往要保證高可用及動態(tài)伸縮。
因此，我們需要一個服務注冊與服務發(fā)現(xiàn)的工具，能夠動態(tài)地變更服務信息，并且找到可用的服務的 IP 地址和端口。目前市面上服務發(fā)現(xiàn)的工具有很多，如 Consul、ZooKeeper 、Etcd、Doozerd 等，本文主要以 Consul 軟件為例。
Consul 是一個支持多數(shù)據(jù)中心、分布式高可用的服務發(fā)現(xiàn)和配置共享的服務軟件，由 HashiCorp 公司用 Go 語言開發(fā), 基于 Mozilla Public License 2.0 的協(xié)議進行開源。 Consul 支持健康檢查，并允許 HTTP 、gRPC 和 DNS 協(xié)議調(diào)用 API 存儲鍵值對。
下面是引入服務注冊與服務發(fā)現(xiàn)工具后的架構(gòu)圖：
在這個架構(gòu)中：
- 首先 S-B 的實例啟動后將自身的服務信息(主要是服務所在的 IP 地址和端口號)注冊到 Consul 中。
- Consul 會對所有注冊的服務做健康檢查，以此來確定哪些服務實例可用哪些不可用。
- S-A 啟動后就可以通過訪問 Consul 來獲取到所有健康的 S-B 實例的 IP 和端口，并將這些信息放入自己的內(nèi)存中，S-A 就可用通過這些信息來調(diào)用 S-B。
- S-A 可以通過監(jiān)聽 Consul 來更新存入內(nèi)存中的 S-B 的服務信息。比如 S-B-1 掛了，健康檢查機制就會將其標為不可用，這樣的信息變動就被 S-A 監(jiān)聽到了，S-A 就更新自己內(nèi)存中 S-B-1 的服務信息。
可見， Consul 軟件除了服務注冊和服務發(fā)現(xiàn)的功能之外，還提供了健康檢查和狀態(tài)變更通知的功能。
Hyperf
對于 Java 開發(fā)者來說，有技術相當成熟的 Dubbo 和 Spring Cloud 微服務框架可供選擇。作為一名 PHPer，我用 Google 查了一下「PHP + 微服務」，發(fā)現(xiàn)有用的相關內(nèi)容少之又少 ，沒有什么實質(zhì)性的參考價值，無限惆悵。。。幸好，有大神在基于 Swoole 擴展的基礎上，實現(xiàn)了高性能、高靈活性的 PHP 協(xié)程框架 Hyperf ，并提供了微服務架構(gòu)的相關組件。
Hyperf 是基于 Swoole 4.3+ 實現(xiàn)的高性能、高靈活性的 PHP 協(xié)程框架，內(nèi)置協(xié)程服務器及大量常用的組件，性能較傳統(tǒng)基于 PHP-FPM 的框架有質(zhì)的提升，提供超高性能的同時，也保持著極其靈活的可擴展性，標準組件均基于 PSR 標準 實現(xiàn)，基于強大的依賴注入設計，保證了絕大部分組件或類都是 可替換 與 可復用 的。
于是，我在學習了微服務架構(gòu)相關的基礎知識之后，使用 Hyperf 框架構(gòu)建了一個基于 PHP 的微服務集群，這是項目源碼地址：https://github.com/Jochen-z/p...。該項目使用 Dokcer 搭建，docker-compose.yml 代碼如下：
這里啟動了一個 Consul 容器 consul-server-leader 作為服務注冊和服務發(fā)現(xiàn)的組件，容器 microservice-1 和 microservice-2 分別提供了加法運算和除法運算的服務。容器 app 作為服務調(diào)用方，配置了 consul-server-leader 容器的 URL，通過訪問 consul-server-leader 獲取 microservice-1 和 microservice-2 服務的 IP 地址和端口，然后 app通過 RPC 協(xié)議調(diào)用加法運算和除法運算的服務獲取結(jié)果并返回給用戶。
app 容器為 Web 應用，部署了一個 Hyperf 項目并對外提供 HTTP 服務。例如，在 App/Controller/IndexController 控制器里有 add 方法：
在 App/JsonRpc/AdditionService 中 add 的實現(xiàn)：
繼承了 AbstractServiceClient 即可創(chuàng)建一個微服務客戶端請求類，Hyperf 在底層幫我們實現(xiàn)了與 Consul 和服務提供者交互的細節(jié)，我們只要 AdditionService 類里的 add 方法即可遠程調(diào)用 microservice-1 和 microservice-2 提供的服務。
至此，PHP 微服務集群搭建就完成了!
【責任編輯：華軒 TEL：（010）68476606】