項目開發的經驗談--composer的使用

前言

維護的主端項目是用php爲主要開發語言的項目，在這幾年引入了Composer擴展包的概念，結合這幾年的實際狀況說一說使用心得吧。

Composer的本質

我的感受Composer是解決的線下聚合項目代碼文件的過程，不屬於線上。包括打tag，經過各類檢測，rsync比對，Jenkins構建，選擇雲或者內部主機，使用docker或者不用等，其實都是線下過程。

我所理解的線上的內容，應該是對請求直接提供支持相應的內容。當一個請求來的時候，穿過網關，到達執行腳本的地方，執行了代碼邏輯，而後返回，應該是這個過程。取址->譯碼->執行，這是程序執行的本質。

Composer的優點

Composer 是 PHP 的一個依賴管理工具，擁有那麼成熟的社區和相關使用人員，開發者利用現成的一些包無疑會增長開發的效率。

擴展包的比較

php項目與java項目等語言上線的不一樣之處在於php是原封不懂的代碼都推到線上運行，而java是編譯以後生成的中間包的形式上線。舉個例子：若是php項目包含10個文件，上線的時候應該是這10個文件，java項目上線是編譯以後生成1個jar包上線。php項目的文件的總和若是比較大會有影響，但php上線不須要預先編譯，這又是極其方便的。

php C擴展包，雖然是與php相關，但整個安裝過程跟上面的java過程是相同的，下載下來一個源碼項目，通過編譯生成一個.so文件，這個.so文件應該是隻包含與提供功能相關的函數，而全部的非線上提供服務相關的內容(ReadMe, 單元測試文件)，應該都是過濾掉的。

php擴展包，應該是和php代碼同樣，不須要額外編譯上線。即基本上擴展包中包含多少個文件，會上線多少個文件。固然，能夠進行優化，只上線你須要的部分，過濾掉包內不相關的部分（測試代碼，各類說明文檔，內容等），目前經常使用的上線方式，基本沒有包含這個過濾，這個能夠優化，但也會帶來一些新的問題，區分哪些文件須要上線，哪些不須要上線的過濾標準。

咱們以前使用過下面三種開發方式：

說明：以上上線均指合併代碼完成，經過線下業務測試，準備經過create tag 而後觸發腳本方式上線。

對比這三種方式特色：

1. 不使用composer包的狀況，這種狀況是咱們的代碼中沒有加入composer的相關內容，上線的過程是建立個tag，發佈到線上的時間，固然如今經常使用方法是rsync文件比對發佈，上線時間 t = create tag + rsync code時間。

2. composer install 在本地，這個是我在某個項目中使用的一種方式，維護的代碼庫中包含第三方擴展包，提交的代碼中包含引入的第三方庫。我在建立tag的時候包含Expansion packs + 業務代碼。由於是composer install在線下執行，因此上線時間 t=create tab + rsync code時間。

3. 先打包再composer install ，因爲以前的系統架構理念，咱們會去執行compoer install作些類的映射的過程。執行create tag，此時業務代碼的tag是最小的，但上線的代碼應該仍是composer install後，增長的Expansion packs + 業務代碼，此時上線時間t= create tab + composer install + rsync code。

若是你的項目使用了Composer的擴展包，上線時間t的長短對你的業務影響不大的狀況下，能夠選擇第三種，若是對上線的速度有要求的話，仍是要考慮中間步驟的時間。

根據實際狀況選擇是否使用composer引入擴展包

通用的擴展包通常只是考慮大衆的需求，功能都比較全，會兼容到各類狀況，這也會增大擴展包的說起和學習成本，有可能大部分是你想要的，有可能一部分是你想要的。 先介紹個case吧，我以前在遷移一個關於調用gitlab api邏輯的應用項目的時候，發現以前的開發同窗用了一個擴展包，對比了使用第三方封裝擴展和直接調用gitlab api接口的遷移成本，發現遷移以前還得熟悉這個擴展包的接口，會增長學習成本，讀了下gitlab的幫助，發現gitlab api的接口調用已經夠簡單和詳細，最後選擇直接調用接口，更快的完成遷移。

若是是採用一邊rsync一邊上線的模式，上線整體代碼包含的文件多少會影響到上線代碼的各個文件的時間差， 若是這個時間差過大的話，會形成線上正在運行的代碼由於找不到類，而報大量的瞬時502，(目前尚未徹底定位，推斷是與這個有關，也許與某些寫法的php的加載有關，後期跟進中。）

回滾和擴容

回滾和擴容對於一個高併發線上運行的項目是兩個經常使用的操做。從決定作這兩個操做，到部署環境，代碼推送完成是一個快速相應的過程。而上線代碼的內容的大小和部署時間的長短是須要咱們去考慮的。要求：迅速快捷。咱們的回滾的時間仍是一個把歷史的tag觸發構建，而後執行composer install，最後rsync代碼比對上線的過程。目前在composer install的時候用了本地的緩存，緩存了相關安裝的包，最快須要10s左右的時間吧，若是沒有這層緩存，那這個時間可就須要的多了。

擴展包質量

第三方擴展包也不是徹底沒問題的，這或許是開源軟件和本身維護的商業軟件的區別吧，以下圖這個Symfony的警告，相關使用者要合理評估這個問題對你的線上代碼的影響。

最後，根據項目實際狀況合理的使用composer。