Swoole

Swoole是實現(xiàn)各種協(xié)議及實現(xiàn)異步高性能的一個庫，不是框架。包括上層的編程API和底層的hack，協(xié)程只不過是實現(xiàn)異步的一種方式。

基于Swoole，PHP開發(fā)者可以輕松快速開發(fā)出支持高并發(fā)的應(yīng)用，比如即時通訊類應(yīng)用，甚至游戲服務(wù)器，進一步拓寬了PHP的應(yīng)用場景。

越來越多的PHP項目已經(jīng)享受到Swoole帶來的技術(shù)紅利。基于異步協(xié)程庫Swoole的PHP框架越來越多了。

目前基于Swoole的都有哪些框架：

TSF: 騰訊基于協(xié)程和Swoole的PHP服務(wù)器框架

EasySwoole: 企業(yè)級服務(wù)框架

PHP-MSF: Camera360基于Swoole的協(xié)程企業(yè)級微服務(wù)框架

ZanPHP: 有贊基于Swoole的PHP框架

SwooleDistributed: 基于Swoole的分布式通訊框架

Group-Co: PHP異步協(xié)程框架

Swoft: 基于Swoole協(xié)程的框架

MixPHP: 基于Swoole的次世代PHP框架

FastD: 一個支持Swoole的輕量級Web開發(fā)框架

QueryPHP: 漸進式PHP常駐框架引擎

Hyperf: PHP企業(yè)級微服務(wù)協(xié)程框架

Swoole框架與生態(tài)發(fā)展

最初Swoole感覺很驚艷，那時候創(chuàng)始人韓天峰還是用php原生來實現(xiàn)常駐內(nèi)存，思路和Workerman相似。

后來用C擴展重構(gòu)，性能確實提升很大，但是技術(shù)曲線直線上升，想用好swoole需要走很長的路，讓普通的PHPer很難愛起來，swoole官方的框架又太簡陋，沒什么人用也沒人維護。

EasySwoole的出現(xiàn)，讓所有人看到了一線希望，swoole也有了明確的方向。

再后來swoft出現(xiàn)，讓很多PHP老鳥覺得，這就是我想要的東西，更讓人感覺PHP終于要躋身現(xiàn)代編程語言的行列，而切換成本不高。

再再后來Hyperf出現(xiàn)了，從代碼和注釋里有人找到了swoft的痕跡，后來發(fā)現(xiàn)是swoft曾經(jīng)的開發(fā)組成員發(fā)起的Hyperf。

EasySwoole和Swoft看起來是swoole生態(tài)的奠基者，也已經(jīng)是swoole生態(tài)的重要組成部分。

2020年Swoole與ThinkPHP合作，由ThinkPHP全權(quán)代理推廣Swoole及其3個收費產(chǎn)品Swoole的企業(yè)級框架、加密方案、調(diào)試方案，另外還和Hyperf合作，有指定Hyperf為官方框架的嫌疑，當然這肯定引起了EsaySwoole、Swoft等前期一起奠定Swoole生態(tài)的框架大大們不愉快。

選擇哪一個Swoole框架

我們先來看swoole+php與go的比較：

CSP 模型：swoole 與 go 只差一個 select，go還有多線程協(xié)程 runtime.GOMAXPROCS，當然單線程又有單線程的好處，少考慮很多線程安全問題。

抽象能力：php5之后 與 java 比較接近，面向?qū)ο竽芰Ω茫O(shè)計模式更好運用，業(yè)務(wù)實現(xiàn)用php會更好，如果是做中間件使用go更好一些。

錯誤處理：php 的 try/catch/finally 雖然內(nèi)置不足，且傳統(tǒng)但可以少寫不少處理異常的代碼，異常不容導(dǎo)致服務(wù)停止，go 則在錯誤處理的粒度更精細一些，需要要更加細心處理每個異常錯誤，否則一不小心服務(wù)就掛了，php確實適合快速實現(xiàn)業(yè)務(wù)。

組件庫生態(tài)：php 現(xiàn)有的庫分 c 擴展和 composer 包，其中 composer 包中有一些使用了一些全局變量/方法，導(dǎo)致無法在協(xié)程中使用，而很多老的c擴展都沒有考慮到異步的場景，導(dǎo)致很多細粒度的功能實現(xiàn)不了，還有使用單獨網(wǎng)絡(luò)庫無法 hook 為協(xié)程的，而 go 所有的庫都天然的可以用協(xié)程，并且是用本身 go 編寫的，沒有用到c，也便于調(diào)試修改源碼。顯然在生態(tài)方面java和go是很占優(yōu)的。

類型系統(tǒng)：強弱類型自有各自的優(yōu)勢，強類型執(zhí)行效率肯定高，弱類型比較自由靈活。

性能：swoole主要提供了websocket/長鏈接的服務(wù)、協(xié)程異步實現(xiàn)，而協(xié)程異步主要是異步IO，解決以往php只能同步IO帶來的低效，但對于密集運算的話，swoole解決不了cpu這塊效率問題。swoole通過協(xié)程把原php磁盤IO、網(wǎng)絡(luò)IO的同步阻塞方式升級為異步不阻塞的方式，提高CPU利用率，加快請求處理。

我們需要基于swoole的框架嗎？還是可用在第三方框架上加入swoole擴展，比如laravel或thinkphp的swoole擴展？

項目不大，用戶量不大，那本身就不會遇到性能瓶頸問題，那還是用自己熟悉的傳統(tǒng)的mvc框架即可，效率高，容錯率好，易維護。

項目大，用戶量大，并發(fā)大，公司只有php技術(shù)棧，那就先考慮前端優(yōu)化（代碼邏輯優(yōu)化、加載優(yōu)化、資源優(yōu)化等）、負載均衡、后端優(yōu)化（業(yè)務(wù)邏輯或算法優(yōu)化、流量限流、異步隊列等）、數(shù)據(jù)層優(yōu)化（適當緩存機制、數(shù)據(jù)庫讀寫分離、sql語句優(yōu)化、數(shù)據(jù)庫索引優(yōu)化等）等等

為了進一步優(yōu)化，及可能還會考慮更完整的分布式，數(shù)據(jù)庫主從與集群、緩存主從與集群、消息隊列集群，再考慮服務(wù)剝離，慢慢發(fā)展成為微服務(wù)架構(gòu)，一方面提高性能，還提高開發(fā)測試部署效率。

而微服務(wù)常用的RPC、API（RESTful）技術(shù)，如果要求提高新能，顯然客戶端（后端業(yè)務(wù)客戶端）需要支持異步實現(xiàn)，RPC服務(wù)端也需要支持異步，才能保證連接快速處理并結(jié)束，避免系統(tǒng)連接太多最后導(dǎo)致三高宕機。

選擇Swoole框架，EasySwoole從文檔上看雖然沒有像Swoft、Hyperf看起來高大上優(yōu)雅，但他提供了不少phper需要的composer包或庫，比如微信、支付寶、jwt、spider等一些常用工具和sdk二次封裝，顯然會提升開發(fā)的效率；Swoft和Hyper重點核心在微服務(wù)和websocket。

目前對于web服務(wù)，除非新項目，允許試驗，否則不建議使用基于swoole的框架實現(xiàn)http服務(wù)。

以上就是Swoole框架的詳細內(nèi)容，想要獲取更多資訊歡迎關(guān)注編程學(xué)習(xí)網(wǎng)