swoole框架選擇

時間 2020-04-07

標籤 swoole 框架選擇简体版

原文原文鏈接

一、需求背景

目前在開發過程當中因須要調用其餘第三方的接口，可是第三方的接口功能存在一些侷限性，好比：html

數據一次只能獲取10條，但業務實際須要展現30或40條
沒有根據數據id獲取收藏狀態的接口，但列表上卻須要展現收藏狀態

而且數據在第三方app上用戶還有可能更新，將數據徹底存在本地也不合適。所以想對接口數據作預獲取。想到了利用swoole的異步、監聽事件及併發處理的特性。java

所以想選擇一個swoole的框架，目前是隻針對這個需求使用，後續別的需求也有可能會用到。laravel

二、框架選擇思考

爲何要使用框架，使用框架的目的是什麼
什麼樣的框架纔是好的框架

我的認爲在選擇框架時首先要明確這2個問題，心中定義一個標準，如此才能選擇出合適的框架。對於這2個問題，我先說下本身的見解。git

爲何要使用框架，使用框架的目的是什麼

使用框架的目的在於簡化開發，讓咱們沒必要將精力用於路由、配置、加載文件等這些基本的處理方面，將精力專一於業務、專一於咱們要完成的功能。因此說框架只是一種工具，關鍵看咱們用得是否是順手。github

什麼樣的框架纔是好的框架

竊覺得，好的框架不是說在github上有多少star、多少fork。而應該是，首先框架可以知足使用要求，和項目自己要創建的架構是匹配的；其次框架應該是具有很好的擴展性，可以知足業務不斷變化的需求；再者，就是框架應該是易於理解的，甚至是源碼可以容易讀懂和改進的，對於框架引發的報錯可以比較容易的解決，不然若是框架自己就很複雜，使用框架沒有達到簡化開發的目的，反而成了一種負擔，那這便違背了使用框架的初衷。web

三、框架備選方案

一、 swoft

https://github.com/swoft-cloud/swoft （star：4.7k fork: 721）docker

swoft 偏向 java 的註釋型寫法，適合有java背景。segmentfault

Swoft 能像 Go 同樣，內置協程網絡服務器及經常使用的協程客戶端且常駐內存，不依賴傳統的 PHP-FPM。有相似 Go 語言的協程操做方式，有相似 Spring Cloud 框架靈活的註解、強大的全局依賴注入容器、完善的服務治理、靈活強大的 AOP、標準的 PSR 規範實現等等。服務器

Swoft的註釋路由AOP實體Bean等都明顯源自於Java，我的感受Swoft框架很全面，並且組件化的設計讓他系統結構清晰並且很好選擇使用所需的模塊。可是太不PHP了，開發我的感受是不敏捷的swoole

文檔：https://www.swoft.org/documents/v2/quick-start/directory-struct/

二、 easyswoole

https://github.com/easy-swoole/easyswoole (star: 3.3k fork: 436)

EasySwoole 是一款基於Swoole Server 開發的常駐內存型的分佈式PHP框架，專爲API而生，擺脫傳統PHP運行模式在進程喚起和文件加載上帶來的性能損失。 EasySwoole 高度封裝了 Swoole Server 而依舊維持 Swoole Server 原有特性，支持同時混合監聽HTTP、自定義TCP、UDP協議，讓開發者以最低的學習成本和精力編寫出多進程，可異步，高可用的應用服務。

easyswoole更像是一個爲了便於開發的助手類，框架的上手難度低，適合團隊快速適應，若是你的項目不是很複雜，有但願精簡快速的開發，es是一個不錯的選擇

文檔：https://www.easyswoole.com/Cn/Components/Component/waitGroup.html

三、 hyperf

https://github.com/hyperf/hyperf (star:2.3k fork: 401)

hyperf 偏向 laravel 的寫法，適合有laravel背景

對於hyperf，是swoft開發組中的幾位的成員出來開發的一個框架，也是擁有了swoft優秀的基因基礎上，再也不強制註釋，集成大量企業級開發的組件，hyperf的入門難度是有的，環境的部署最好使用docker，對於初學的小白來講，須要花費一些時間進行研究學習，對於團隊的接受須要花費時間進行學習和消化，大型的集羣項目相對來講比較適合hyperf。

文檔：https://doc.hyperf.io/#/