背景
快速可以说是互联网的最大特点了，唯快不破，快速响应，快速发布，快速部署，快速上线
但上线，毕竟还是有风险的，怎么能又快速响应，又能降低风险范围呢
前人，现人，后人们都在寻找着银弹
部署方式就进化了有很多次，蓝绿部署、滚动部署、灰度发布、金丝雀发布。。。
这些都是为了应对互联网的快速响应需求
游戏的发布现在还是比较粗暴的，对开发，运维也比较简单。
制定一个版本计划，开发，与运营沟通，确定版本内容，到了时间，所有游戏区全部关闭入口，停止服务器，发布，部署，重启，开放入口，一气呵成，快哉！
等等，理想很丰满，现实很骨感
在版本发布最后一天，开发人员在凌晨1、 2点时，还在开发，修复bug，好不容易打包，回家睡觉
第二天运维在8点开始停机发布新版本；
duang,怎么游戏服起不来了，开发请起床，查问题
迷迷糊糊的开发在梦境中惊醒，终于搞定，打包，发版本，启动服务(有时可能要一上午查问题，通知运营方，延长维护时间)
duang,玩家反馈，新功能有问题...
此时，回滚？还是。。。；好汉不回头，哪来的回滚
紧急停机，再寻找问题，修复，上线...
...
整个游戏的链条上，似乎大家都已经习惯，开发习惯，玩家也习惯
习惯麻痹了一切，没有提出更好的策略，大家都这么玩啊，无所谓啦~
方案
细思极恐，我们应该，也需要做得更好
灰度发布／金丝雀发布
灰度发布是在原有版本可用的情况下，同时部署一个新版本应用作为“金丝雀”（金丝雀对瓦斯极敏感，矿井工人携带金丝雀，以便及时发发现危险），测试新版本的性能和表现，以保障整体系统稳定的情况下，尽早发现、调整问题。
灰度发布／金丝雀发布由以下几个步骤组成：
- 准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件。
- 从负载均衡列表中移除掉“金丝雀”服务器。
- 升级“金丝雀”应用（排掉原有流量并进行部署）。
- 对应用进行自动化测试。
- 将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）。
- 如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）
游戏架构
这个架构图比现实丰满不少，真实情况组件可能是单点的，数据层也就是单个mysql，一切都是那么脆弱。
流程图
玩家首先登陆游戏运营平台，鉴权完毕，选择区服，通过网关服务器获取到真实game-server信息，通过TCP，玩家与game-server建立起长连接。
通过这个流程，就知道玩家与game-server直接牵手，强依赖的，如果gameserver重启，tcp连接是一定会断的，虽然前端可能尝试重新连接，但对玩家是有感的，不可能对玩家透明。
改进
怎么才能对玩家无感，切换版本呢？
在之前的架构图中，稍作修改，在玩家与Gameserver之间增加一层ha-proxy，这样就有了灰度发布的基础
玩家不再直接与game-server直连，而是与ha-proxy
透明性
对玩家来说，发版本就是透明的，发版本时，不再需要停机，入口也不需要关闭，7*24玩耍
流量灵活切换
灰度百分比，可以灵活控制，这里面又涉及到路由规则，复杂了，可以先百分百切换
快速迭代
玩家无感，出现bug，可以快速修复，快速上线
快速回滚
一旦新版本有问题，可以马上切回老版本，版本之间无逢切换
难点
加了ha-proxy，多了更多的灵活性
ha-proxy的难点，高可用，高可靠，高性能
高可用
最重要的一点，不能单点；
如果ha-proxy挂了，怎么办？就算game-server正常运行，也不能再提供服务，自己坑了自己
所以ha-proxy不能单点，哪是集群，还是主从？
每台物理机上都部署，还是集中几台部署？
高可靠
在新旧版本同时在线时，流量是否平滑过渡？ 玩家操作是否保持完整性？
一个玩家操作横跨新旧版本时，数据一致性如何保障？
高性能
游戏服都是尽量压榨单台服务的能力，现在多了一层通讯，IO会不会影响性能？
结论
对于以上方案，不论是哪一种实现方式，仁者见仁，条条大路通罗马。
也可能你觉得这种想法本身就是个多余。
能卖1块钱的豆腐，为什么要卖5毛？
