hyperf| hyperf 程式設計入門小結 1

最近在帶組内的新人基于 hyperf 項目進行開發, 目标是建構一整套 PHP 微服務的體系. 千裡之行始于足下, 這裡先 mark 一下一些基礎的程式設計注意事項

hyperf 程式設計注意事項

禁止項

• $path = $_SERVER['HTTP_REFERER'];

  不可以使用超全局變量, swoole server 是常駐程序 epoll 方式處理請求, 不是 fpm 依靠多程序一對一處理請求

配置管理 config

• 所有配置都在 config 檔案中, 項目中隻使用 config() 就可以擷取配置
• .env 隻寫環境相關配置, 最後都需要使用 env() 配置到 config 檔案中, env() 隻允許在 config 檔案中使用

修改 PHP 配置

• container.php

  保持和官方同步,

  int_set() define()

  等可以配置到 hyperf.php 檔案中

容器 container

• 盡量使用架構提供的功能, 這樣才能發揮出 container 的效果
• 手動 new 的對象, 沒有交給 container 管理, 無法使用架構提供的注解功能, 比如

  @Inject

協程 go/coroutine

• 使用協程有2個必須條件: 開協程

  go() + callback 中執行非阻塞代碼

• 常用的庫都提供了非阻塞調用: mysql(基于laravel ORM + 連接配接池), redis(ext-redis + 連接配接池), http(guzzle clientFactory)

http client

• http 請求這樣的功能很常見, 幾乎所有的項目都會自己的封裝, 但是要使用 hyperf 提供的

  hyperf/guzzle

  , 才能實作

  非阻塞調用

• 項目自己封裝的 http 請求庫, 基本可以斷定沒有

  guzzle/http

  好用

基于 hyperf 的封裝

務必

要考慮

反哺

社群, 有以下幾點:

• hyperf 的疊代速度, 包括功能支援上, 速度有目共睹, 所謂的封裝, 也許就在下次發版支援了
• hyperf 的代碼送出以及整個社群共建, 保證了代碼風格和相當高的

  代碼品質

• 反哺社群

  也是

  依賴解決

  的最優解之一
• 最後再來一句靈魂拷問:

  自己再封裝一層真的有必要麼?

建議項:

• 大段注釋的代碼基本建議删掉, 哪怕真的有需要, 也可以從 git log 裡找回, 我認為這是

  clean code

  的要求之一
• 不建議使用常量, hyperf 隻設定了一個常量

  BASE_PATH

  , 使用常量通常是沒想好要

  怎麼放

  , 建議多看看 hyperf 的元件設計

Unix哲學（Unix程式設計藝術）

• Doug Mcilroy:

1.讓每個程式就做好一件事。如果有新任務，就重新開始，不要往原程式中加入新功能而搞得複雜。

2.假定每個程式的輸出都會成國另一個程式的輸入，哪怕那個程式還是未知的。輸出中不要有無關的資訊幹擾。避免使用嚴格的分欄格式和二進制格式輸入。不要堅持使用互動式輸入。

3.盡可能早地将設計和編譯的軟體投入試用，哪怕是作業系統也不例外，理想情況下，應該是在幾星期之内。對拙劣的代碼别猶豫，扔掉重寫。

4.優先使用工具而不是拙劣的幫助來減輕程式設計的負擔。工欲善其事，必先利其器。

5.一個程式隻做一件事，并做好。程式要能協作。程式要能處理文本流，因為這是最通用的接口。

• Rob Pike:

1.你無法斷定程式會在什麼地方耗費運作時間。瓶頸經常出現在想不到的地方，是以别急于胡找個地方改代碼，除非你已證明那兒就是瓶頸所在。

2.估量。在你沒對代碼進行估量，特别是沒找到最耗時的那部分之前，别去優化速度。

3.花哨的算法在n很小時通常很慢，而n通常很小。花哨算法的常數複雜度很大。除非你确定n總是很大，否則不要用花哨算法（即使n很大，也優先考慮第2條）

4.花哨的算法比簡單算法更容易出bug、更難實作。盡量使用簡單的算法配合簡單的資料結構。

5.資料壓倒一切。如果已經選擇了正确的資料結構并具把一切都組織得井井有條，正确的算法也就不言自明。程式設計的核心是資料結構，而不是算法。

給我看流程圖而不讓我看（資料）表，我仍會茫然不解；如果給我看（資料）表，通常就不需要流程圖了；資料表足夠說明問題了。

6.原則6：沒有原則6

• Ken Thompson:

子產品原則：使用間潔的接口拼合簡單的部件。

清晰原則：清晰勝于機巧。

拿不準就窮舉。

組合原則：設計時考慮拼接組合。

分離原則：政策同機制分離，接口同引擎分離。

簡潔原則：設計要簡潔，複雜度能低則低。

吝啬原則：除非确無它法，不要編寫寵大的程式。

透明性原則：設計要可見，以便審查和調試。

健壯原則：健壯源于透明與簡潔。

表示原則：把知識疊入資料以求邏輯質樸與健壯。

通俗原則：接口設計避免标新立異。

緘默原則：如果一個程式沒什麼好說的，就沉默。

補救原則：也現異常時，馬上退也并給出足夠錯誤資訊。

經濟原則：甯花機器一分鐘，不花程式員一秒鐘。

生成原則：避免手工hack，盡量編寫程式去生成程式。

優化原則：雕琢前先要有原型，跑之前先學會走。

多樣原則：決不相信所謂“不二法門”的斷言。

擴充原則：設計着眼未來，未來部比預想來得快。

補充資源

• PHP 微服務系列大綱
• PHP 網絡程式設計基礎 - swoole
• swoole| swoole wiki 筆記
• PHP 微服務架構
• 雲平台基礎設施
  • cncf
• php 基礎
  • psr
  • 架構: yii laravel