2.开发流程拆解与介绍
2.1需求阶段
▲不要浪费时间讨论不应该存在的问题
2.1.1评估需求的方法
①MVP(minimum viable product，最小化可行产品)思想
▲站在用户的角度思考
▲收集用户反馈，快速迭代
②四象限法
2.2开发阶段
▲云原生的发展，深刻改变了后端开发的工作
▲开发环境逐渐云原生化
2.2.1云原生下的开发
①传统虚拟机
▲在物理主机中虚拟出多个虚拟机，每个虚拟机拥有自己的操作系统
▲运维人员负责自己的操作系统
▲每个虚拟机中都要安装相应的依赖环境
②容器化
▲容器是在操作系统中虚拟出来的
▲通过cgroup，namespace和Union Mount等技术实现了容器之间的相互隔离，同时容器只有很低的开销
▲应用和其依赖作为以一个整体，打包成绩镜像交付
③单体架构
▲多个模块共同组成一个服务，服务体量较大
▲模块之间直接调用，不需要RPC通信
▲服务整体扩缩容量
▲多人开发一个代码仓库，需要充分集成测试
④微服务架构
▲各个功能在不同的服务中
▲不同模块需要进行RPC通信
▲不同模块可以独立扩缩容量
▲每个服务的代码仓库仅由少部分人维护
2.2.2团队的分支策略
▲多个团队成员之间各自用什么分支开发？
▲修改之间有冲突怎样解决？
▲出了问题的代码如何回退到之前版本？
2.2.3代码规范、自测和文档
①代码规范
▲养成良好的注释习惯
▲不要有魔法数字，魔法字符串
▲重复的逻辑抽象成公共的方法，不要copy代码
▲正确使用IDE的重构功能，防止修改错误
②自测
▲单元测试
▲功能环境测试
▲测试数据构造
③文档
▲大型改造需要有技术设计文档，方案评审
▲好的接口文档能更方便的和前端进行沟通
2.3测试阶段
2.3.1测试金字塔
2.3.2测试的三个环境介绍
①功能环境
▲需要一个能模拟线上的环境进行开发测试
▲环境和环境之间能够隔离，不影响其他功能的开发和测试
②集成环境
▲不同人开发的功能合并在一起测试，相互之间的影响可能产生缺陷
▲迭代发布的所有功能合并在一起测试，确保发布的所有功能之间的影响不产生缺陷
③回归环境
▲确保新的功能不对老的功能产生影响
▲回归测试一般会借助自动化测试脚本
2.4发布阶段
2.4.1各种发布模式
1.蛮力发布：简单粗暴，直接用新版本覆盖老版本
| 优点 | 缺点 | 适用 |
|---|---|---|
| 简单 | 发布过程中服务会中断 | 测试环境部署 |
| 成本低 | 出了问题会影响全部用户 | 小公司或者非核心的业务服务 |
2.金丝雀发布：
| 优点 | 缺点 | 适用 |
|---|---|---|
| 相对简单 | 发布过程中服务会中断 | 测试环境部署 |
| 能够用少量用户验证新版本功能 | 发现不了随用户增大才会暴露的问题 | 小公司或者非核心的业务服务 |
3.滚动发布：每个实例都通过金丝雀的方式逐步放大流量，对用户影响小，体验平滑
| 优点 | 缺点 | 适用 |
|---|---|---|
| 发布过程中用户体验不会中断 | 流程较复杂，对发布系统有比较高的要求 | 发布系统能力较强，可以平滑切换流量 |
| 可以充分验证服务功能 | 发布速度较慢 | 发布自动化程度高，可以自动滚动 |
| 新老版本不兼容的情况不能使用 |
4.蓝绿发布：把服务分成蓝绿两组，先把蓝组流量摘掉然后升级，只用绿组提供服务，之后切换全部流量，只用蓝组提供服务，然后升级绿组服务，最终两组升级
| 优点 | 缺点 | 适用 |
|---|---|---|
| 发布速度快 | 需要有一半机器承担所有流量的能力 | 服务器资源丰富 |
| 流程相对简单 | 出问题会影响全部用户 | 新老版本不能兼容的情况，需要一次性升级到新版 |
2.4.2发布过程中要做的事情
①发布负责人
▲负责按照计划执行发布
▲需要通知各个相关人员发布进展
▲观察各个服务的发布状态，及时处理异常
②变更服务的相关RD
▲按照上线checklist检查服务的日志、监控、相应上线过程中的告警
▲对于自己负责的改动，在小流量或者是预览环境进行功能验证
▲执行发布计划中的其他操作（如线上配置，数据处理等）
③值班同学
▲发布过程中的监控和告警需要特别关注，如果有异常需要立刻判断是否由变量引起
▲如果有变更引起的告警或者用户反馈，需要及时中止发布
2.5运维阶段
2.5.1发生事故的情况|青训营笔记
▲用户量增加引起的流量洪峰（12306抢票）
▲数据库表的数据量增长导致查询速度变慢
▲内存/进程泄漏导致服务资源不足
▲光缆被挖断
3.流程怎样优化
3.1DevOps
▲代码管理
▲自动化测试
▲持续集成
▲持续交付
3.1.1效率竖井
3.2全流程自动化
▲通过效能平台串联各个阶段
▲减少无价值的等待
