这是我参与「第五届青训营 」伴学笔记创作活动的第 12 天
为什么
传统瀑布模型
工作流程直观表达、定义了标准的研发阶段、以流程为本，理想化模型
这种模型适用于对安全等要求比较高的，如银行等企业
但是这种模型太注重流程，不适用于市场
敏捷开发
- 以小团队快速迭代
- 团队成员之间的合作更加紧密
- 以人为本、和用户沟通
SAFe
The Scaled Agile Framework是一套管理框架，多个team相互配合
有哪些
需求阶段
-
MVP（minimum viable product）最小可行产品思想
站在用户的角度思考，收集用户反馈，快速迭代
-
四象限法：
开发阶段
传统方式：
-
虚拟机
在物理主机中虚拟出多个虚拟机，每个虚拟机拥有自己的操作系统。运维人员负责维护和交付虚拟机。每个虚拟机都要安装相应的依赖环境
-
单体架构
多个模块共同组成一个服务，服务体量比较大。模块之间直接调用，不需要RPC通信。服务整体扩缩容量。多人开发一个代码仓库，需要充分集成测试
云原生：
-
容器化
容器是在操作系统中虚拟出来的。通过cgroup，namespace和Union Mount等技术实现了容器之间的相互隔离，同时容器只有很低的开销。内容和其依赖作为一个整体，打包成镜像交付
-
微服务架构
各个功能在不同的服务中。每个服务需要RPC通信。不同模块可以独立扩缩容。每个服务的代码仓库仅由少部分人维护
注意代码规范、自测、文档
测试阶段
功能环境
- 需要一个能模拟线上的环境进行开发和测试
- 环境和环境之间能够隔离，不影响其他功能的开发
集成环境
- 不同人开发的功能合并在一起，相互之间的影响可能会产生缺陷
- 迭代发布的所有功能合并在一起测试，确保发布的所有功能之间的影响不产生缺陷
回归环境
- 确保新的功能不对老的功能产生影响
- 回归测试一般会借助自动化测试脚本
发布阶段
发布模式：
-
蛮力发布：直接用新版本覆盖老版本
-
金丝燕发布：在一台机器发布，再扩散，增大用户数量
-
滚动发布：每个实例都通过金丝雀的方式逐步放大流量，对用户影响小
-
蓝绿发布：把服务分成蓝绿两组，先把蓝组流量摘掉然后升级，只用绿组，之后切换全部流量，只用蓝组服务，然后升级绿组服务，最终两组全部发布
-
红黑发布：发布时动态扩容出一组新的服务
运维阶段
一般有查大规模的微服务体系，在微服务中添加埋点采集Metrics、Logging、分布式Trace等多种数据
如何优化
DevOps：
