这是我参与「第五届青训营 」伴学笔记创作活动的第 11 天
从需求到上线的全流程
需求阶段
-
不要浪费时间讨论不应该存在的问题
-
MVP (minimum viable product)
-
站在用户的角度评估需求
-
收集用户反馈，快速迭代
-
-
四象限法（紧急、重要）
- 尽量不要把事情变成紧急的事情
开发阶段
云原生
-
传统虚拟机
-
由物理主机虚拟出多个虚拟机，每个虚拟机拥有自己的操作系统
-
运维同学负责维护和交付虚拟机
-
每个虚拟机中都要安装相应的依赖环境
-
-
容器化
-
容器是在操作系统中虚拟出来的
-
通过 cgroup, namespace 和 Union Mount 等技术实现了容器之间的相互隔离。同时容器只有很低的开销
-
应用和其依赖作为一个整体，打包成镜像交付
-
微服务
-
各个功能在不同的服务中
-
不同的模块需要进行 RPC 通信
-
不同模块可以独立扩缩容
-
每个服务的代码仓库仅由少部分人维护
开发
-
开发环境逐渐原生化
-
本地 IDE 转移至线上
团队分支策略
-
多个团队成员各自用什么分支开发？
-
修改出现冲突怎么办？
-
出现了问题怎么回退到之前的版本
代码规范
-
养成良好的注释习惯，超过三个月的代码，自己都会忘了当时想的是什么
-
不要有魔法数字，魔法字符串
- 如果有，应该把数字或字符串定义出来
-
重复的逻辑抽象成公共方法，不要 cv
-
正确使用 IDE 的重构功能（踩过坑qaq），防止修改错误
自测
-
单元测试
-
功能环境测试
-
测试数据构造
文档
-
大型改造需要有技术设计文档，方便评审
-
好的接口文档能更方便地和前端同学进行沟通
测试阶段
推荐：《Google 软件测试之道》
越早发现缺陷，修复的成本越低
功能环境
-
需要一个能模拟线上的环境进行开发和测试
-
环境和环境之间能够隔离，不影响其他功能的开发和测试
集成环境
-
不同人开发的功能合并在一起测试，相互之间的影响可能产生缺陷
-
迭代发布的所有功能合并在一起测试，确保发布的所有功能之间的影响不产生缺陷
回归环境
-
确保新的功能不会对之前的功能产生影响
-
回归测试一般会借助自动化脚本
发布阶段
发布模式
-
蛮力发布：直接用新版本覆盖老版本
-
优点
-
简单
-
成本低
-
-
缺点
-
发布过程中服务会中断
-
出了问题会影响全部用户
-
-
适用
-
测试环境部署
-
小公司或非核心的业务服务
-
-
-
金丝雀发布：先测试一台机器
-
优点
-
相对简单
-
能够用少量用户验证新版本的功能
-
-
缺点
-
发布过程中服务依然会中断
-
发现不了随着用户量增大才会暴露的问题
-
-
适用
-
测试环境部署
-
小公司或非核心的业务服务
-
-
-
滚动发布：每个实例都使用金丝雀逐步放大流量
-
优点
-
发布过程中用户体验不会中断
-
可以充分验证服务功能
-
-
缺点
-
流程较复杂，对发布系统有比较高的要求
-
发布速度慢
-
新老版本不兼容的情况下不能使用
-
-
适用
-
发布系统能力较强，可以平滑切换流量
-
发布自动化程度较高，可以自动滚动
-
-
-
蓝绿发布：两个实例集交替升级、交替承担流量
-
优点
-
发布速度快
-
流程相对简单
-
-
缺点
-
需要一般的机器承担所有流量的能力
-
出现问题会影响全部用户
-
-
适用
-
服务器资源丰富
-
新老版本不能兼容的情况，需要一次性升级到新版本
-
-
-
红黑发布：类似于蓝绿发布，只是短时间内扩容一倍的服务器
一篇非常详细的文章：常用的发布方式 - HackerVirus - 博客园
运维阶段
事故
-
流量洪流（12306咳咳
-
数据库表的数据量增长
-
内存|进程泄露
-
光缆被挖断？
出现问题
-
止损（关闭服务
-
通知服务使用者
-
定位问题
-
修复问题
