项目开发的经验谈--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。