摘要：所以的鏡像，所有的包都是和官方一致的，可以比對，沒有任何修改。所以做鏡像最大的難點，是穩定性的保障。開源是全量鏡像，包含了對部分的處理。

先上鏈接：https://github.com/zencodex/c...

ZComposer 鏡像誕生于2017年3月份，至今已經運行2年多了，這不是一個多么有技術含量的東西，所以簡單聊一些開發和解決問題的思路，希望能對你有一點啟發。如果你覺得有些收獲，請點下鼠標，在 github 上給我1個 star（支持下），謝謝。

安全性，不對原有的json，zip做修改，否則會引起 hash 變化，重新計算 hash 沒問題（之前第三方有這么做的），這樣帶來的問題是，無法對包的安全性做校驗，假如有惡意黑鏡像，對數據做了修改，就無法判斷了。所以 ZComposer 的鏡像，所有的包都是和 packagist.org 官方一致的，可以比對 hash ，沒有任何修改。

穩定性，因為不間斷的采集數據，上傳數據，中間有一個環節出現差錯，就可以導致有問題，所以務必對采集完的包，通過 hash 值做完整性檢查。有時候第三方的API策略，或者CDN線路都可能導致出現問題。所以做鏡像最大的難點，是穩定性的保障。

Webysther/packagist-mirror（官方推薦的鏡像開源） fork 自 hirak/packagist-crawler，但這些鏡像開源都沒有處理dist包，而dist包才是最大/最多的，最值得CDN處理的。ZComposer 開源是全量鏡像，包含了對 dist 部分的處理。dist 包還有個 65000上限子目錄數 的問題，1年的時間，包的數量都是成倍的增加。軟連接的方案是我原創出來的，或許隨著包的無限增加，還需要設計其他方案。

推薦運行主機配置：

[x] 內存最好不低于4G

[x] 剩余磁盤空間不低于30G

$ apt install beanstalkd
$ cd composer-mirror
$ composer install

通常根據自己部署的實際環境，修改參數。詳細配置說明詳見 config.default.php

cp config.default.php config.php，修改 config.php 中的如下參

    /**
     * distdir 用于存儲 zip 包
     */
    "distdir" => __DIR__ . "/dist/",

    /**
     * 指向 mirrorUrl 對應的 web 實際目錄
     */
    "cachedir" => __DIR__ . "/cache/",

    /**
     * packagistUrl：官方采集源
     */
    "packagistUrl" => "https://packagist.org",

    /**
     * 鏡像包發布站點, packages.json 入口根域名
     */
    "mirrorUrl" => "https://packagist.laravel-china.org",

    /**
     * .json 中 dist 分發 zip 包的CDN域名
     */
    "distUrl" => "https://dl.laravel-china.org/",

sudo vim /etc/supervisor/supervisord.conf，添加如下配置信息：

[program:crawler]
command=php ./bin/console app:crawler
directory=/home/zencodex/composer-mirror/  ;部署代碼的位置，自行替換
autostart=true
autorestart=true
redirect_stderr = true  ; 把 stderr 重定向到 stdout，默認 false
stdout_logfile_maxbytes = 10MB  ; stdout 日志文件大小，默認 50MB
stdout_logfile_backups = 5      ; stdout 日志文件備份數
stdout_logfile = /tmp/composer_crawler_stdout.log

[program:composer_daemon]
command=php ./bin/console app:daemon
directory=/home/zencodex/composer-mirror/  ;部署代碼的位置，自行替換
autostart=true
autorestart=true
redirect_stderr = true  ; 把 stderr 重定向到 stdout，默認 false
stdout_logfile_maxbytes = 10MB  ; stdout 日志文件大小，默認 50MB
stdout_logfile_backups = 5      ; stdout 日志文件備份數
stdout_logfile = /tmp/composer_daemon_stdout.log

# sudo crontab -e
# 根據自己環境代碼的位置，替換 /home/zencodex/composer-mirror 
# getcomposer 是獲取最新的 composer，上傳到 CDN 云存儲

0 */2 * * * /usr/bin/php /home/zencodex/composer-mirror/bin/console app:clear --expired=json
0 1 * * * /usr/bin/php /home/zencodex/composer-mirror/getcomposer.php

# 執行抓取任務
$ php ./bin/console app:crawler

# 后臺多進程模型同步又拍云
$ php ./bin/console app:daemon

# 清理過期垃圾文件
$ php ./bin/console app:clear --expired=json

# 掃描并校驗所有json和zip文件的hash256
$ php ./bin/console app:scan

沒有使用數據庫存儲，完全是按目錄結構存儲

每個包的 dist/zip 文件存儲的是對應 github url的下載地址，因磁盤空間有限，不在本地存儲，直接推送到云端

清理過期文件，判斷是否有更新，是否過期的依據是文件的時間戳，所以不要手動對文件做 touch，或引起時間戳變化的操作

如果使用非又拍云的其他平臺，需要注意以下代碼，需要自行實現

ClientHandlerPlugin 需要 Flysystem 的對應 Adapter 有對應接口，本例中只有 zencodex/flysystem-upyun 實現了，其他第三方包，可以參照樣例自行實現

Cloud::refreshRemoteFile，作用是刷新 CDN 緩存的文件，這個每日有調用頻率限制，所以只刷新 package.json 時使用

Cloud::refreshRemoteFile，如果使用非又拍云的平臺，需要替換為自己平臺刷新代碼。或者參照 ZenCodexSupportFlysystemAdapterUpyunAdapter 封裝 getClientHandler。

Cloud::prefetchDistFile 和 refreshRemoteFile 類似，調用的是云平臺特殊接口，無法統一封裝在 Flysystem，所以也通過 getClientHandler 處理

代碼詳情見 src/Commands/PatchCommand.php

/*
|--------------------------------------------------------------------------
| linux ext4 支持的最大子目錄數有上限，大約 64000 ~ 65000，目前包的數量已經超過上限
|--------------------------------------------------------------------------
|
| 有三種解決方法，前2種基本不現實。所以自己通過嘗試，找到了3 (軟連接不計數的方案)
|
|   1. 更換沒有子文件夾數量限制的文件系統，比如 xfs 
|   2. 或者更改相關代碼，重新編譯 ext4 內核
|   3. 切割大的文件夾，分散不同字母開頭的文件。在主文件夾里面使用軟連接，軟連接并不計數
|
*/

ZComposer 鏡像早期是 ?@Summer? 提出的構想，期間也得到了 ?@overtrue? 和LC社區小伙伴們的大力支持，開源也是 Overtrue 提的建議，一并感謝大家們的鼓勵和支持。大俠們會在 2019 年 8 月 3 - 4 日，舉辦國內 第一屆 Laravel Conf China 大會，可謂華山論劍，高手云集的盛會，趕緊通過官網報名吧：http://laravelconf.cn

文章首發于：https://learnku.com/articles/...