# 2 微服務框架研發概覽 PHP微服務框架即“Micro Service Framework For PHP”，是Camera360社區服務器端團隊基于Swoole自主研發的現代化的PHP服務框架，簡稱msf或者php-msf，它的核心設計思想是采用協程、異步、并行的創新技術手段提高系統的單機吞吐能力，降低整體服務器成本。 ## 主要特性 * 精簡版的MVC框架 * IO密集性業務的單機處理能力提升5-10倍 * 代碼長駐內存 * 支持對象池 * 支持Redis連接池、MySQL連接池（異步與同步） * 內置Redis Proxy，支持分布式、master-slave集群（故障自動failover與recovery） * 內置MySQL Proxy，master-slave集群（讀寫分離、事務） * 支持異步、并行 * 基于PHP Yield實現協程 * 內建http/redis/mysql/mongodb/task等協程客戶端 * 純異步的Http Server * RPC Server/Client * 支持命令行模式 * 支持獨立進程的定時器 * 支持獨立配置進程 * 支持sendfile靜態文件(需配置root目錄) ## 環境要求 - Linux，FreeBSD，MacOS(有兼容問題) - Linux內核版本2.3.32以上(支持epoll) - PHP-7.0及以上版本（推薦使用PHP-7.1） - gcc-4.4以上版本 - [swoole-1.9.15](https://github.com/swoole/swoole-src/archive/v1.9.15.tar.gz)及以上版本（暫不支持Swoole-2.0） - [hiredis-0.13.3](https://github.com/redis/hiredis/archive/v0.13.3.tar.gz) - [yac](https://github.com/laruence/yac/archive/yac-2.0.2.tar.gz) - [phpredis](http://pecl.php.net/get/redis-3.1.2.tgz) - composer ## 定位 我們專注打造穩定高性能純異步基于HTTP的微服務框架，作為nginx+php-fpm的替代技術棧實現架構的微服務化;而Tcp/WebSocket Server將作為插件的形勢支持，或者作為其他獨立的開源項目。 對于小型團隊或者業務系統我們建議還是采用傳統的nginx+php-fpm技術棧，對于成本和性能來說沒有瓶頸，也就完全沒有必要引入全新的技術棧。 對于大中型團隊或者業務系統，處在服務治理或者服務化演進的重要階段，php-msf是可選方案之一。 對于龐大的PHP應用集群，想要大幅節約服務器成本，提升服務性能，php-msf是可選方案之一。 對于聚合服務，比如大型的網站首頁，想要通過服務器端聚合內容整合數據，php-msf是可選方案之一。 ## 原則 ### 穩定 php-msf經受了Camera360社區服務大流量、高并發的洗禮，穩定性得到充分驗證。穩定性是我們花了大量時間、精力去解決的最重要問題，是三大原則的最重要原則。 ### 高性能 IO密集性業務的單機處理能力提升5-10倍，這是生產環境中得出的真實數據，如Camera360社區某聚合服務在流量高峰需要40臺服務器抗住流量，而采用php-msf重構之后只需要4臺相同配置的服務器就可以抗住所有流量。 ### 簡單 由于Swoole復雜的進程模型，并且有同步阻塞和異步非阻塞之分，所以在運行相同代碼邏輯時，可能在調用方式、傳遞參數都不一致，從而直線拉高了學習成本，我們為了屏蔽低層的差異，做了大量的工作，實現和傳統MVC框架的唯一區別在于添加“yield”關鍵字。 ## 協程 目前社區有幾個PHP開源項目支持協程，它們大多采用Generator+Yield來實現，但是實現的細微差別會導致性能相差甚遠，我們應該認識到協程能夠以同步的代碼書寫方式而運行異步邏輯，故協程調度器的性能一定要足夠的高，php-msf的協程調度性能是原生異步回調方式的80%，也就是說某個API采用原生異步回調寫法QPS為10000，通過php-msf協程調度器調度QPS為8000。 ## 為什么是微服務框架？ 目前php-msf還在起步階段，我們花了大量的時間和精力解決穩定性、高性能、內存問題，因為我們認為“基石”是“萬丈高樓”的最基本的保障，只有基礎打得牢，才能將“大樓”建設得“更高”。3.0版本是我們開源的起始版本，是我們邁出的重要一步，接下來我們重點會是分布式微服務框架的打磨。 另外，由于基于PHP長駐進程，并直接解析HTTP或者TCP請求，這是服務化最重要的支撐，基于此我們可以做很多原來不敢去實現的想法，總之想像空間很大。 ## 某服務重構 ### 軟硬件 * aws c3.xlarge（4核8G） * 64個php-fpm進程 ### 處理邏輯 * 1次Redis Get * 1次 MongoDB Query * 2個廣告接口 * 2個業務接口 ### 重構前 PHP-5.6/Yii2/OPcache/Http n | c | qps | 平均響應時間(ms) | CPU | -------|-------|------------|-----------------|-------| 100 | 1 | 4.16 | 240.168 | 9% | 5000 | 5 | 15.36 | 325.502 | 46% | 5000 | 10 | 18.72 | 534.141 | 83% | 5000 | 50 | 19.03 | 2627.159 | 99% | PHP-7.0/Yii2/OPcache/Http n | c | qps | 平均響應時間(ms) | CPU | -------|-------|------------|-----------------|-------| 100 | 1 | 3.51 | 284.876 | 5% | 5000 | 5 | 17.23 | 290.129 | 21% | 5000 | 10 | 32.36 | 309.057 | 40% | 5000 | 20 | 52.94 | 377.784 | 82% | 5000 | 40 | 55.52 | 720.433 | 91% | ### 重構后 msf-2.0 n | c | qps | 平均響應時間(ms) | CPU | -------|-------|------------|-----------------|-------| 100 | 1 | 4.52 | 221.089 | 1.4% | 5000 | 5 | 40.31 | 248.063 | 14% | 5000 | 10 | 73.22 | 273.148 | 27% | 5000 | 20 | 129.63 | 308.575 | 75% | 5000 | 40 | 172.19 | 475.916 | 99% | ### 資源使用  在處理相同并發請求下，上面的曲線是重構前的，下面的曲線是重構后的。 ### 結論 1. 采用新框架重構某服務后，在相同資源消耗的情況下，單機的處理能力提升8倍； 2. 重構前某在正常情況下，提供19qps，CPU使用率為45%左右； 3. 重構后某在正常情況下，提供19qps，CPU使用率為12%左右； 4. 重構后某單機正常情況下，提供120qps，CPU使用率為75%左右；