开发与迭代
点击阅读更多查看文章内容
开发流程拆解与介绍
开发阶段
单体架构vs微服务架构
微服务的缺点：不同服务之间需要进行rpc通信，网络开销比较大
代码规范：
- 养成良好的注释习惯，超过三个月的代码，自己都会忘了当时在想什么
- 不要有魔法数字，魔法字符串
- 例如 if x==2，这里的2就是魔法数字，没有明确的含义，可以通过定义一个常量通过常量命名来明确数字的含义
- 重复的逻辑抽象成公共的方法，不要copy代码
- 正确使用IDE的重构功能，防止手动修改错误不彻底
自测：
- 单元测试
- 功能环境测试
- 测试数据构造
文档：
- 大型改造需要有技术设计文档，方案评审
- 好的接口文档能更方便的和前端进行沟通
测试阶段
发布阶段
发布模式：常用的发布方式 - HackerVirus - 博客园
蛮力发布：直接用新版本覆盖老版本
金丝雀发布：先发一台机器，没问题再发送到全部机器
滚动发布
蓝绿发布（在流量较少的时候进行发布）
红黑发布
运维阶段
- 用户量增加引起流量洪峰
- 数据库表的数据量增长导致查询速度变慢
- 内存/进程泄露导致服务资源不足
止损->周知->定位->修复
流程怎样优化
DevOps解决方法：开发和运维行程闭环
架构
架构定义解析
微服务架构：
服务网格：
企业级后端架构的挑战
离在线资源并池
自动扩缩容（指标：cpu利用率）
微服务亲和性部署
流量治理
CPU水位负载均衡
Git
Git的前世今生
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Git是一个分布式版本控制系统：
- 版本控制：一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。
- 版本控制可以更好的关注变更，了解到每个版本的改动是什么，方便对改动的代码进行检查，预防事故发生；也能够随时切换到不同的版本，回滚误删误改的问题代码；
- 分布式：每个开发者都有一个完整的代码库副本，包括代码和历史记录。
本地版本控制：
集中式版本控制：
分布式版本控制：
Git基本使用方式
Git配置
不同级别：低级别会覆盖高级别配置
- local：.git/config
- global：~/.gitconfig
- system：$(prefix)/etc/gitconfig
一次commit会创建 commit/tree/blob 三个object
- blob：存储文件的内容
- tree：存储文件的目录信息
- commit：存储提交信息，一个commit对应唯一版本的代码
将这三个文件串联在一起：
tree中可以存储多个文件信息也可以再存储tree
refs文件存储的内容：一个commit就对应一个完整的代码，refs的内容是对应的Commit ID，因此把ref当作指针，指向对应的Commit来表示当前Ref对应的版本。
不同种类的ref：.git/refs/heads前缀表示的是分支，.git/refs/tags前缀表示的是标签
Branch：分支一般用于开发阶段，是可以不断添加Commit进行迭代的
Tag：标签一般表示的是一个稳定版本，指向的Commit一般不会变更
修改历史版本：
- commit –amend：通过这个命令可以修改最近一次commit信息，修改之后commit id会变
- rebase：通过 git rebase -i HEAD~3 可以实现对最近三个commit的修改
- 合并 commit
- 修改具体的commit message
- 删除某个commit
Clone：拉取完整的仓库到本地目录，可以指定分支，深度。
Fetch：将远端某些分支最新代码拉取到本地，不会执行merge操作，会修改refs/remote内的分支信息，如果需要和本地代码合并需要手动操作。
Pull：拉取远端某分支，并和本地代码进行合并，操作等同于 git fetch + git merge，也可以通过 git pull –rebase 完成 git fetch + git rebase 操作。可能存在冲突，需要解决冲突。
Push：将本地代码同步到远端，冲突问题：如果本地的commit记录和远端的commit历史不一致，则会产生冲突，比如 git commit –amend or git rebase 都有可能导致这个问题。如果该分支就自己一个人使用，或者团队内确认可以修改历史则可以通过git push origin master -f 来完成强制推送
代码合并
Fast-Forward（git merge test –ff-only）：不会产生merge节点，合并后保持线性历史，如果target分支有更新，则需要通过rebase操作更新source branch后才可以合入。
Three-Way Merge（git merge test –no-ff）：三方合并，会产生一个新的merge节点
保护分支：防止用户直接向主干分支提交代码，必须通过PR来进行合入
Code Review，CI：都是在合入前的检查策略，Code Review 是人工进行检查，CI则是通过一些定制化的脚本来进行一些校验。
代码历史混乱，代码合并方式不清晰：不理解 Fast Forward 和 Three Way Merge 的区别，本地代码更新频繁的使用Three Way 方式，导致生成过多的merge节点，使提交历史变得复杂不清晰。
