項目開發(fā)的經(jīng)驗談--composer的使用

前言

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

Composer的本質(zhì)

個人感覺Composer是解決的線下聚合項目代碼文件的過程，不屬于線上。包括打tag，通過各種檢測，rsync比對，Jenkins構(gòu)建，選擇云或者內(nèi)部主機，使用docker或者不用等，其實都是線下過程。

我所理解的線上的內(nèi)容，應該是對請求直接提供支持相應的內(nèi)容。當一個請求來的時候，穿過網(wǎng)關，到達執(zhí)行腳本的地方，執(zhí)行了代碼邏輯，然后返回，應該是這個過程。取址->譯碼->執(zhí)行，這是程序執(zhí)行的本質(zhì)。

Composer的優(yōu)勢

Composer?是 PHP 的一個依賴管理工具，擁有那么成熟的社區(qū)和相關使用人員，開發(fā)者利用現(xiàn)成的一些包無疑會增加開發(fā)的效率。

擴展包的比較

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

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

php擴展包，應該是和php代碼一樣，不需要額外編譯上線。即基本上擴展包中包含多少個文件，會上線多少個文件。當然，可以進行優(yōu)化，只上線你需要的部分，過濾掉包內(nèi)不相關的部分（測試代碼，各種說明文檔，內(nèi)容等），目前常用的上線方式，基本沒有包含這個過濾，這個可以優(yōu)化，但也會帶來一些新的問題，區(qū)分哪些文件需要上線，哪些不需要上線的過濾標準。

我們之前使用過下面三種開發(fā)方式：

說明：以上上線均指合并代碼完成，通過線下業(yè)務測試，準備通過create tag 然后觸發(fā)腳本方式上線。

對比這三種方式特點：

1. 不使用composer包的情況，這種情況是我們的代碼中沒有加入composer的相關內(nèi)容，上線的過程是創(chuàng)建個tag，發(fā)布到線上的時間，當然現(xiàn)在常用方法是rsync文件比對發(fā)布，上線時間 t = create tag + rsync code時間。

2. composer install 在本地，這個是我在某個項目中使用的一種方式，維護的代碼庫中包含第三方擴展包，提交的代碼中包含引入的第三方庫。我在創(chuàng)建tag的時候包含Expansion packs + 業(yè)務代碼。因為是composer install在線下執(zhí)行，所以上線時間 t=create tab + rsync code時間。

3. 先打包再composer install ，由于之前的系統(tǒng)架構(gòu)理念，我們會去執(zhí)行compoer install做些類的映射的過程。執(zhí)行create tag，此時業(yè)務代碼的tag是最小的，但上線的代碼應該還是composer install后，增加的Expansion packs + 業(yè)務代碼，此時上線時間t= create tab + composer install + rsync code。

如果你的項目使用了Composer的擴展包，上線時間t的長短對你的業(yè)務影響不大的情況下，可以選擇第三種，如果對上線的速度有要求的話，還是要考慮中間步驟的時間。

根據(jù)實際情況選擇是否使用composer引入擴展包

通用的擴展包一般只是考慮大眾的需求，功能都比較全，會兼容到各種情況，這也會增大擴展包的提及和學習成本，有可能大部分是你想要的，有可能一部分是你想要的。 先介紹個case吧，我之前在遷移一個關于調(diào)用gitlab api邏輯的應用項目的時候，發(fā)現(xiàn)之前的開發(fā)同學用了一個擴展包，對比了使用第三方封裝擴展和直接調(diào)用gitlab api接口的遷移成本，發(fā)現(xiàn)遷移之前還得熟悉這個擴展包的接口，會增加學習成本，讀了下gitlab的幫助，發(fā)現(xiàn)gitlab api的接口調(diào)用已經(jīng)夠簡單和詳細，最后選擇直接調(diào)用接口，更快的完成遷移。

如果是采用一邊rsync一邊上線的模式，上線總體代碼包含的文件多少會影響到上線代碼的各個文件的時間差， 如果這個時間差過大的話，會造成線上正在運行的代碼因為找不到類，而報大量的瞬時502，(目前還沒有完全定位，推斷是與這個有關，也許與某些寫法的php的加載有關，后期跟進中。）

回滾和擴容

回滾和擴容對于一個高并發(fā)線上運行的項目是兩個常用的操作。從決定做這兩個操作，到部署環(huán)境，代碼推送完成是一個快速相應的過程。而上線代碼的內(nèi)容的大小和部署時間的長短是需要我們?nèi)タ紤]的。要求：迅速快捷。我們的回滾的時間還是一個把歷史的tag觸發(fā)構(gòu)建，然后執(zhí)行composer install，最后rsync代碼比對上線的過程。目前在composer install的時候用了本地的緩存，緩存了相關安裝的包，最快需要10s左右的時間吧，如果沒有這層緩存，那這個時間可就需要的多了。

擴展包質(zhì)量

第三方擴展包也不是完全沒問題的，這或許是開源軟件和自己維護的商業(yè)軟件的區(qū)別吧，如下圖這個Symfony的警告，相關使用者要合理評估這個問題對你的線上代碼的影響。

最后，根據(jù)項目實際情況合理的使用composer。