开发忙的团团转,往往都是研发效能惹的祸:还没用容器就太out了
大家好!我是老码农。
《码农说》公众号的第4篇文章暖暖来袭,今天继续分享研发效能这个话题。
标题党?
标题中最后一句:还没用容器就太out了,这话发自肺腑。
如果你的团队还没用容器,建议:赶紧学,赶紧学。
场景一:注册中心
现在我们很多项目都是微服务,注册中心和配置中心,nacos成为首选(关于注册中心选型不是本次话题的重点,就不展开了)
会越到一个什么问题呢:大家如果都用服务器上的Nacos,在开发阶段会出现
- A注册服务S1、S2、S3到服务器Nacos;
- B也注册服务S1、S2、S3到服务器的Nacos;
然后A想调试S1->S2->S3这个链路,会发现调用不同,因为S1->S2的时候,有可能调用的B本地电脑的S2,
- A和B属于不同部门,网络是不通的。
- 即使是通的,如果B的代码不是最新的,你也没法确认效果
所以华丽丽的挂了,没发联调。
场景二:消息中心
消息中心也有类似问题,你在A服务发了个消息,然后在B服务监听,想调试一个BUG,结果是另外一个同学给消费了,你根本就没法联调。
上面的场景一和场景二,大致解决对策:
- 第一种:分不同的组(nacos)或者vhost(消息中心),然后不同的人连接不同的组或者vhost
- 第二种:本地搭建一个nacos环境、rabbitmq环境
很多同学都会采取第二种方案。
那第二种方案会带来一个问题,需要下载、安装、配置
- nacos
- rabbitmq
- 。。。
如果遇到软件冲突,估计要折腾你很长时间才能搞定,尤其nacos,之前团队有些同学需要打补丁才能正常使用,然后也是调查了好久。
容器
对,就是引入容器技术,我们能很好解决这个问题。
本篇文章不会针对容器做比较详细的说明,重点在分享提高研发效能思路。
那怎么做呢:
- Step1: 安装Docker Desktop桌面版
- Step2: 安装docker-compose
- Step3: 编写脚本
- Step4: 运行脚本
- Step5: 确认环境
我们可以把这个流程标准化,然后写一个手顺,分发给大家。
大家可能会比较关心一个问题,那如何同步服务器和本地的配置信息呢。
这个有什么难的呢?比如:nacos
nacos的配置信息都存储到:config_info这张表中,我们可以写个脚本,定时同步到本地环境就行了。
这5个步骤完全可以由1个人负责调研,然后写个资料,之后全员展开即可。
远不止
对于绝大部分团队,容器直接上生产是有些难度的,是需要积累经验后再上生产会更安全些。
毕竟一步到位搞定K8S,对团队的技术能力要求还是蛮高的,需要有专业的devops人员推进才更可靠。
但如果只是开发和测试环境引入容器技术,还是比较容易的,学习成本并不高。
容器化思路
最重要:一定要脚本化,脚本化不管我们在
- 开发环境
- 测试环境
- 开发人员的电脑
我们都能
- 版本一致
- 快速部署
我们所有的事都要围绕效率展开,不要搞很多重复的工作。
分享下我通常做法。
第一步:梳理常用中间件
如下图, 我梳理了
- elk
- gitlab
- mysql
- redis
- rabbitmq
- 。。。
这些不管在哪个团队,都有可能会用到,例如Redis、MySQL基本是标配。
第二步:编写脚本:环境变量
通常我会把配置相关的属性提到提到外面的配置文件,统一设置,如下图:.env
第三步:编写脚本:docker-compose.yml
这里面都是比较细,大家看下图,因为很多同学并不是特别熟悉docker,最好多加些注释,便于大家理解和学习
第四步:编写启动脚本
一定要2种环境的都写
- bat:windows,很多开发同学用的都是windows操作系统;
- sh:现在用macOS的同学也很多,这个脚本在macOS、Linux都可以运行。
当我们做完这些准备后,今后在弄环境,直接运行这些脚本就行了,
而且可以快速复制到其他项目。
大家想一想,是不是能提升我们的研发效率呢。
总结
关于容器化这个话题比较大,本篇抛砖引玉,分享了在开发环境和测试环境容器化方面的一些思路。
我们实则还可以进一步优化。
例如和CI做深度集成,不需要写脚本,直接在CI平台上点击完成这些开发环境和测试环境创建的工作,是不是更Happy呢。
我们作为一个有追求的研发,平时更要注意效率化,不要让低效的工作掩盖毫无意义的加班带来的痛楚。
我是老码农
大家好!我是老码农。今天就分享到这里。
关注《码农说》,期待用不同的视角与大家进行深入的交流,一同学习技术,提升研发效能,共同高速成长。