建站
咨詢
售后
建站咨詢
新聞中心
前言
維護(hù)的主端項目是用php為主要開發(fā)語言的項目，在這幾年引入了Composer擴(kuò)展包的概念，結(jié)合這幾年的實際情況說一說使用心得吧。
Composer的本質(zhì)
個人感覺Composer是解決的線下聚合項目代碼文件的過程，不屬于線上。包括打tag，通過各種檢測，rsync比對，Jenkins構(gòu)建，選擇云或者內(nèi)部主機(jī)，使用docker或者不用等，其實都是線下過程。
我所理解的線上的內(nèi)容，應(yīng)該是對請求直接提供支持相應(yīng)的內(nèi)容。當(dāng)一個請求來的時候，穿過網(wǎng)關(guān)，到達(dá)執(zhí)行腳本的地方，執(zhí)行了代碼邏輯，然后返回，應(yīng)該是這個過程。取址->譯碼->執(zhí)行，這是程序執(zhí)行的本質(zhì)。
Composer的優(yōu)勢
Composer?是 PHP 的一個依賴管理工具，擁有那么成熟的社區(qū)和相關(guān)使用人員，開發(fā)者利用現(xiàn)成的一些包無疑會增加開發(fā)的效率。
擴(kuò)展包的比較
php項目與java項目等語言上線的不同之處在于php是原封不懂的代碼都推到線上運行，而java是編譯之后生成的中間包的形式上線。舉個例子：如果php項目包含10個文件，上線的時候應(yīng)該是這10個文件，java項目上線是編譯之后生成1個jar包上線。php項目的文件的總和如果比較大會有影響，但php上線不需要預(yù)先編譯，這又是極其方便的。
php C擴(kuò)展包，雖然是與php相關(guān)，但整個安裝過程跟上面的java過程是相同的，下載下來一個源碼項目，經(jīng)過編譯生成一個.so文件，這個.so文件應(yīng)該是只包含與提供功能相關(guān)的函數(shù)，而所有的非線上提供服務(wù)相關(guān)的內(nèi)容(ReadMe, 單元測試文件)，應(yīng)該都是過濾掉的。
php擴(kuò)展包，應(yīng)該是和php代碼一樣，不需要額外編譯上線。即基本上擴(kuò)展包中包含多少個文件，會上線多少個文件。當(dāng)然，可以進(jìn)行優(yōu)化，只上線你需要的部分，過濾掉包內(nèi)不相關(guān)的部分（測試代碼，各種說明文檔，內(nèi)容等），目前常用的上線方式，基本沒有包含這個過濾，這個可以優(yōu)化，但也會帶來一些新的問題，區(qū)分哪些文件需要上線，哪些不需要上線的過濾標(biāo)準(zhǔn)。
我們之前使用過下面三種開發(fā)方式：
說明：以上上線均指合并代碼完成，通過線下業(yè)務(wù)測試，準(zhǔn)備通過create tag 然后觸發(fā)腳本方式上線。
對比這三種方式特點：
1. 不使用composer包的情況，這種情況是我們的代碼中沒有加入composer的相關(guān)內(nèi)容，上線的過程是創(chuàng)建個tag，發(fā)布到線上的時間，當(dāng)然現(xiàn)在常用方法是rsync文件比對發(fā)布，上線時間 t = create tag + rsync code時間。
2. composer install 在本地，這個是我在某個項目中使用的一種方式，維護(hù)的代碼庫中包含第三方擴(kuò)展包，提交的代碼中包含引入的第三方庫。我在創(chuàng)建tag的時候包含Expansion packs + 業(yè)務(wù)代碼。因為是composer install在線下執(zhí)行，所以上線時間 t=create tab + rsync code時間。
3. 先打包再composer install ，由于之前的系統(tǒng)架構(gòu)理念，我們會去執(zhí)行compoer install做些類的映射的過程。執(zhí)行create tag，此時業(yè)務(wù)代碼的tag是最小的，但上線的代碼應(yīng)該還是composer install后，增加的Expansion packs + 業(yè)務(wù)代碼，此時上線時間t= create tab + composer install + rsync code。
如果你的項目使用了Composer的擴(kuò)展包，上線時間t的長短對你的業(yè)務(wù)影響不大的情況下，可以選擇第三種，如果對上線的速度有要求的話，還是要考慮中間步驟的時間。
根據(jù)實際情況選擇是否使用composer引入擴(kuò)展包
通用的擴(kuò)展包一般只是考慮大眾的需求，功能都比較全，會兼容到各種情況，這也會增大擴(kuò)展包的提及和學(xué)習(xí)成本，有可能大部分是你想要的，有可能一部分是你想要的。 先介紹個case吧，我之前在遷移一個關(guān)于調(diào)用gitlab api邏輯的應(yīng)用項目的時候，發(fā)現(xiàn)之前的開發(fā)同學(xué)用了一個擴(kuò)展包，對比了使用第三方封裝擴(kuò)展和直接調(diào)用gitlab api接口的遷移成本，發(fā)現(xiàn)遷移之前還得熟悉這個擴(kuò)展包的接口，會增加學(xué)習(xí)成本，讀了下gitlab的幫助，發(fā)現(xiàn)gitlab api的接口調(diào)用已經(jīng)夠簡單和詳細(xì)，最后選擇直接調(diào)用接口，更快的完成遷移。
如果是采用一邊rsync一邊上線的模式，上線總體代碼包含的文件多少會影響到上線代碼的各個文件的時間差， 如果這個時間差過大的話，會造成線上正在運行的代碼因為找不到類，而報大量的瞬時502，(目前還沒有完全定位，推斷是與這個有關(guān)，也許與某些寫法的php的加載有關(guān)，后期跟進(jìn)中。）
回滾和擴(kuò)容
回滾和擴(kuò)容對于一個高并發(fā)線上運行的項目是兩個常用的操作。從決定做這兩個操作，到部署環(huán)境，代碼推送完成是一個快速相應(yīng)的過程。而上線代碼的內(nèi)容的大小和部署時間的長短是需要我們?nèi)タ紤]的。要求：迅速快捷。我們的回滾的時間還是一個把歷史的tag觸發(fā)構(gòu)建，然后執(zhí)行composer install，最后rsync代碼比對上線的過程。目前在composer install的時候用了本地的緩存，緩存了相關(guān)安裝的包，最快需要10s左右的時間吧，如果沒有這層緩存，那這個時間可就需要的多了。
擴(kuò)展包質(zhì)量
第三方擴(kuò)展包也不是完全沒問題的，這或許是開源軟件和自己維護(hù)的商業(yè)軟件的區(qū)別吧，如下圖這個Symfony的警告，相關(guān)使用者要合理評估這個問題對你的線上代碼的影響。
最后，根據(jù)項目實際情況合理的使用composer。
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。
新聞名稱：項目開發(fā)的經(jīng)驗談--composer的使用-創(chuàng)新互聯(lián)
瀏覽路徑：http://www.dlmjj.cn/article/doddgs.html
