这是我参与「第三届青训营 -后端场」笔记创作活动的第3篇笔记
需求阶段
- 不要浪费时间讨论不应该存在的问题
- 站在用户的角度思考；收集用户反馈，快速迭代
- 给出后端系统视角的建议，估算任务优先级
开发阶段
-
云原生下的开发：
-
容器化技术
-
微服务技术
- 各个功能在不同的服务中
- 不同模块需要进行RPC通信
- 不同模块可以独立扩缩容
- 每个服务的代码仓库仅由少部分人维护
-
WebIDE
-
-
团队分支策略：
- 为什么会有分支策略
- 有哪些分支策略
- 合并的方式
-
代码规范
- 养成良好的注释习惯，超过三个月的代码，自己都会忘了当时在想什么
- 不要有魔法数字，魔法字符串
- 重复的逻辑抽象成公共的方法，不要copy代码
- 正确使用IDE的重构功能，防止修改错误
-
自测
- 单元测试
- 功能环境测试
- 测试数据构造
-
文档
- 大型改造需要有技术设计文档，方案评审
- 好的接口文档能更方便的和前端进行沟通
测试阶段
- 功能测试：功能测试，是为了测试一个新开发的功能，因此需要有能模拟线上的开发和测试环境，环境之间能相互隔离，这样可以独立验证不同的新功能
- 集成测试：集成测试，是为了把几个功能合在一起测试，因为可能各个新功能独立测试没有问题，但是合在一起却产生了bug
- 回归测试：回归测试是为了验证老的功能不被新的改动影响
发布阶段
-
各种发布模式
- 蛮力发布：简单粗暴，直接用新版本覆盖老版本。
- 金丝雀发布：由于金丝雀对瓦斯极其敏感，因此以前矿工开矿下矿洞前，先会放一只金丝雀进去探是否有有毒气体，看金丝雀能否活下来，金丝雀发布由此得名。
- 滚动发布：每个实例都通过金丝雀的方式逐步放大流量，对用户影响小，体验平滑
- 蓝绿发布：常备两个集群，先把流量全部切换到Group 1，升级Group2，然后再把流量全部切换到Group 2，升级Group 1。最终恢复流量。
- 红黑发布：与蓝绿发布类似，但是日常只有一个集群工作，发布时扩容一个集群升级新版本，切换流量后下掉老版本的集群。
-
发布过程要做的事
-
发布负责人
- 负责按照计划执行发布
- 需要通知各个相关人员发布进展
- 观察各个服务的发布状态，及时处理异常
-
变更服务的相关RD
- 按照上线checklist检查服务的日志，监控，响应上线过程中的告警
- 对于自己负责的改动，在小流量或者是预览环境进行功能验证
- 执行发布计划中的其他操作（如线上配置，数据处理等）
-
值班同学
- 发布过程中的监控和告警需要特别关注，如果有异常需要立刻判断是否由变更引起
- 如果有变更引起的告警或者用户反馈，需要及时中止发布
-
运维阶段
公司在发展过程中，逐渐形成了十分复杂的超大规模微服务体系，为了实现对这些复杂微服务的监控，通常会在微服务中添加埋点采集Metrics、Logging、分布式Trace等多种数据
