软件工程化的一些思考

背景介绍

之前一直在做项目的工程化，导致很久没有写博客了，就在上周已经顺利的发版了，涉及的项目有一个一般的分布式项目，还有一个机器学习集成平台，今天就总结一下工程化中的一些经验。

为什么要做工程化

一般的开发流程是先做设计，设计在经过各方专家评审之后，开始编码实现，现在开发的模式一般也是瀑布的开发模式，讲究快速实现，快速迭代，所以开发的产品很容易会由于cpu/io/内存/网络/线程池的大小/超时设计造成各种的瓶颈以及错误。

如果没有好的工程化，运维阶段就会有很多的问题。如果你的工程化做的不好，那么就等着各种支持吧，配置怎么配，软件怎么装，很大的一部分时间都浪费在了支持上。如果工程化做的好，运维会按照文档一步一步来，就顺利的安装好了，也就是用短的投入换来了不用一直的支持。

现场环境千变万化，机器性能不一样，依赖软件的部署也不一样，比如说有的地方显卡是p4,有的地方怎是t4，还有的是p40, 众所周知，这几款显卡的性能有很大的差别，t4的fp16性能好好，单p4就不行了。还有，有的现场安装的是redis集群，有的则是单机部署的。如果你的软件不能很好的支持这种配置，后期部署的时候就会很麻烦，也会给现场造成一些不必要的浪费。

一些需要工程化的点

下面就分两部分（一般软件，机器学习软件）介绍一下，工程化需要注意哪写点

一般软件

依赖软件的各种部署与配置

对于软件的各种存储依赖和中间件依赖，一定要适配他们的各种部署方式，这里列几种常见的常用的软件：

• redis
  redis需要把配置文件给现场暴露出来，需要让现场根据实际情况进行自定义的配置，如果现场已经有了现成的redis。则需要支持无缝的对接现场的redis 这里需要注意的是redis的密码，集群部署方式，哨兵部署方式以及单机部署方式。同时还的做好数据落地持久化。
• minio
  minio是一个对象存储工具，部署方式的话有单节点，集群。配置的话需要注意访问的凭证，是否允许浏览器，以及存储的位置等。
• mongo
  mongo是一个介于关系和非关系的存储软件，也需要适配它的各种部署方式。
• mysql
• mq
• zookeeper
• es
• nginx
  做代理的神器，配置需要面向运维，同时需要尽量的简化配置，各种配置尽量做到傻瓜式、一键式。

总之各种软件的依赖都需要考虑到各种可配置的配置项，以及各种可以写死的配置，当然还需要适配各种部署方式。

线程池大小以及超时的配置

开发软件的时候调试的样本毕竟很少，可是现场会有各种各样的情况，比如说处理超大文件，这会导致之前设置成超时时间太短，导致很多任务失败，如果是大批量的小文件，这时可能之前设置的线程池大小就会偏小，导致资源的利用率不足。如果仅仅把这些线程池大小和超时时间给运维暴露出来，运维也可能不会配置。这时需要给软件增加一个压力感知层，让软件可以自适应的调整这些配置。对于运维，我们把一些端口号和ip交给他们就好了，其他的我们都自己内部调整就行。

软件启动脚本的自动化

软件发布出去之后，运维需要启动软件，这时候运维需要不断的修改软件的配置。不同的依赖修改不同的配置。这时候就需要写一个自动化的启动脚本，运维之需要把软件复制过来，然后执行start就行。其他的就交给脚本吧。关于需要配置的东西，就写一个config配置文件，用户在启动时候，把一些地址和端口给配进去，自动化的脚本会加载这个配置文件，并把这些变量放到对应的地方，这样可以顺利的启动。

机器学习相关

显存的控制

生产环境的时候一定要把显存给控制好，如果设置的是显存自增的方式，很有可能会把服务给挂了。
当然可以固定显存的利用率，gpufraction = 0.2 可是在不同显卡上，这个值设置需要注意，因为有的显卡是8g，有的可是16g,还有的是12g，同样是0.2 实际占用的可是不一样，很有可能造成显存浪费和启动失败。

多节点的启动

一般机器学习也都是通过http来进行检测的，每一个机器学习服务都是http服务，我们可以再有限的gpu上启动尽可能多的节点，然后通过一个nginx挂起来，这样就做成了一个简单的集群，可以有效的进行提速，当然需要通过时间的显存以及显卡利用率来判断适合的数据。

tenosrrt 量化与加速

可以通过tensorrt来量化你的模型，并时间加速，如果是多个服务，可以吧图像预处理给统一了，这样也会减少很多时间，具体如何做量化，可以直接看官网的例子。

总结

总之，再做工程化的时候目标就是，资源占用尽量少、运行速度快、准确率高、实施简单。