微服務架構：構建PHP微服務生態

誕生於 2014 年的“微服務架構”，其思想經由 Martin Fowler 闡述後，在近幾年持續受到重視，理論與相關實踐都不斷髮展，目前談架構必定會言及微服務架構。

伴隨著微服務架構的快速發展，各種開發語言各種型別的微服務開發框架陸續出現，在近日舉辦的 PHPCon 大會上，來自開源微服務框架 TARS 核心開發組的梁晨，為開發者分享了 TARS-PHP 在 TARS 構建微服務生態中扮演的角色。梁晨同時也是 TARS-PHP 專案的主要負責人，以下是本次演講全程的整理。

大家好，接下來 45 分鐘的時間，我想跟大家聊聊 TARS 作為微服務平臺本身有什麼優勢，同時也想讓大家看到，TARS-PHP 核心開發組在這一年中，不斷演進 TARS-PHP，將其融入 PHP 生態的努力，看看這對整個 TARS 微服務生態有些什麼意義。

從近年來的業界架構演進來看，微服務已經逐漸成為趨勢。從這張圖可以看到，在不同的行業，釋出服務的時間間隔各不相同，網際網路行業每週釋出的佔比最高，但是其它行業也有逐漸趕上的趨勢。

我們可以看到具體的釋出資料，63%的企業平均每月釋出一次。怎麼將系統轉到微服務架構上呢？現在有很多選擇，接近 10% 的人選擇 Dubbo 這樣的原生框架，接近 50% 的人選擇雲原生架構，同時也有 30% 左右的人基於 Weblogic WEBSPHERE 等架構。而在這其中，51% 考慮轉型，15% 已經實施。

從這些資料中我們可以看得出來微服務架構當前逐漸成為主流。

伴隨著微服務架構的這種快速發展節奏，各種開發語言各種型別的微服務開發框架相繼出現，我們分析了一下當前各家使用微服務框架的情況，可以看到主要分為四種模式：

無服務治理類：gRPC、brpc 為代表

單語言帶服務治理類：Dubbo、Spring Cloud 為代表，主要適用於 Java 語言

多語言帶服務治理類：TARS

Service Mesh：SideCar 模式，仍在發展成熟期

這其中，TARS 在通訊框架的基礎上支援服務治理能力，同時支援多種程式語言，算是比較另類的選擇。講到這裡，我們可以來看看它具體支援怎樣的治理能力，在此之前，先了解一下微服務架構是怎樣的。

從微服務整體架構上看，它主要分為：接入層、閘道器層、業務服務層、支援服務層和基礎設施層。除此之外，非常重要而又容易被忽略的還有：微服務開發框架、持續交付流水線、端到端工具鏈、工程實踐與規範這些構成整個微服務架構體系的部分，它們都在微服務的架構中發揮著非常重要的作用。

TARS 整體可以分為運營、平臺、通訊框架、公共元件與統一協議幾個大塊，用於支援上述微服務架構層次。

簡單來講，運營平臺上，TARS 可以支援不同語言服務的管理和運營，同時也支援頁面級別服務的建立和釋出；而在公共元件上，TARS 提供了非常多強大的公共元件來負責不同的功能，包括日誌元件、監控元件、主控元件與配置元件等；統一協議方面，TARS 本身自帶的二進位制協議，非常適合高效能的場景，首先這個協議語言無關，自帶介面描述，同時還有工具進行程式碼轉換，可以大大提高開發效率。

聚焦到 TARS-PHP 上，作為Tars在PHP語言的解決方案，設計的時候主要考慮如下四個方面：

功能完善：對標現有 C++、Java 與 NodeJS 體系功能

靈活：論靈活，誰與 PHP 爭鋒？

輕量：用最輕量的設計，點到即止，即插即用

高效：插上 Swoole 協程的翅膀，不得不飛

整個框架主要分為四個部分：

TARS-CLIENT

TARS-SERVER

TARS-EXT 擴充套件

程式碼生成工具

在過去的一年中，TARS-PHP 主要在豐富現有功能、構建更加開放的體系、引入 DevOps 的效率、更好地服務社群四個方面發力。

從 TARS-SERVER 功能層面來講，TARS-PHP 新增了 WebSocket Server 和 PB SERVER，使得現在一個服務模板，能夠實現多達五種不同的服務。

透過使用 WebSocket Server，使用者可以有效擴充套件 Swoole 功能，它支援多個埠、自定義 和非常靈活化的 FD 儲存。

PB Server 構建了一個 gRPC 服務，這個服務部署在 TARS 平臺上，參與 TARS 平臺定址，受 TARS 平臺管理。這個服務使用 gRPC on Http/2 作為網路通訊協議，使用 Protobuf 作為編碼協議，可以和其它 PB Client 協同工作。

在開發效率上，我們也針對 PB Client 做了最佳化，開發者同樣可以透過我們提供的程式碼自動化生產工具，節約開發時間。

在 TARS-PHP 與平臺更好地結合方面，我們實現了針對 PHP 服務的專有特性監控，它可以監控 Swoole 的 worker 數量、TIME_WAIT 等網路狀態個數與 Swoole 中每個 worker 佔用的記憶體情況等資料，讓開發者更瞭解自己的服務。

同時，新增的自定義路由功能，也賦能了現有的 HTTP SERVER，透過引入 lumen 引擎的方式，現在的路由功能也更加強大。

在日誌方面，藉助 monolog 的能力，我們與 ELK 也進行了結合。簡單的配置，就可以讓日誌入 ELK，更加方便我們進行一些 debug 或是後續的資料探勘。

為了構建 TARS-PHP 的開放體系，我們引入了 Client & Server filters，它可以讓開發者更加方便地在請求前後新增自己的程式碼。同時我們也開放了 TARS 協議中，向 Context 上下文寫入的能力，使得分散式追蹤唾手可得。

而為了讓 PHP 開發者能夠更多地使用 TARS，同時降低自己的遷移成本，TARS-PHP 現在也與 Laravel、ThinkPHP、Yii2、SWOFT 與 Phalcon 進行了整合，後續還將重點接入 Hyperf 與 easyswoole 等業界優秀的框架。透過接入 TARS，相當於賦能了服務打包、雲配置與 HTTP/TARS 雙協議，又能保持原有的開發框架，一舉兩得。

在 DevOps 方面，TARS 提供了官方的 Docker 映象，讓開發者能夠一鍵搭建開發環境。而在持續整合上，我們也提供了基於 Jenkins 和 TARS 平臺 API 的自動構建方案，讓你的程式碼提交到測試到部署，成為一條龍。

為了讓開發者能夠更快地使用 TARS，我們也放出了一個使用 TARS 的 HTTP、TCP 與 PB 在內的多種 Server 型別的彈幕服務，儲存也涉及到了 Redis 和 MySQL，可以讓開發者更容易在自己的專案裡把 TARS 跑起來。

TARS-PHP 的開源之路剛剛起步，為了解決文件問題，我們也不斷地完善現有的 Gitbook，降低開發者的使用門檻。

在 TARS-PHP 開源一年左右的時間裡，我們的專案與衍生專案數超過了 10 個、GitHub repo commit 數量超過 200 次、微信與 QQ 群累計開發者社群人數 800+、Packagelist 下載量 4萬+。希望大家也能夠加入 TARS-PHP 的建設。

轉載來源：