前言
維護的主端項目是用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。