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