分布式服务框架-原理与实践:11---服务灰度发布【扩展】-蓝绿发布

2019独角兽企业重金招聘Python工程师标准>>>

下面，再学习一下扩展材料-蓝绿发布

===

翻墙访问：

http://www.tuicool.com/articles/2Iji2ue

http://sunitspace.blogspot.com/2013/10/blue-green-deployment.html

http://sunitspace.blogspot.com/

===

蓝绿发布的意义是，整个发布过程中，用户没有感受到任何宕机或者服务重启

下面说一下蓝绿发布的过程

第0步：部署以前的配置

这一步还看不出啥来

 

第1步: 把绿色集群的状态改为’备用’. 从负载均衡的池里把这些地址去掉,这样,绿色的集群就不再回接收到来自用户的请求了.转而进入备用负载均衡的池里.

这个图，本质的话，分析，本质就是开了2套完全独立的环境

此时版本都是1

第2步:在绿色集群里部署新的代码,直到应用启动成功

此时，相当于搭建了1套v1,一套v2,完整的2套环境

第3步:使用备用负载均衡简单测试一下备用集群的部署情况.理想状态下是全自动的.

第4步:把绿色备用集群的状态改成存货,于是进入了存活负载均衡的池里

看到 蓝色运行v1版本,绿色运行v2版本,都连接的是相同的数据库.这意味着v2版本也要在老的数据模型上运行.如果数据库有变更,要等到所有的集群升级到新的代码上.

第5步: 对蓝色集群也进行同样的操作.

看这个图，本质就是流量全部切换到了v2上

最终v2代码完成部署.

第6步:根据情况.运行数据库迁移

 

===总结===

就是完全搭建2套完整的后端环境，然后流量从入口之处慢慢切！

如果是这样的话，那倒是挺简单的

 

===附上英文版

Zero downtime during deployment using modified blue-green deployment strategy

Zero downtime during application deployment is one of the key requirements for continuos delivery. And no business would like their site to be down and showing maintenance page every few days/weeks during deployment.

To achieve this we decide to go for blue-green deployment. However, we were challenged with how to do this in legacy style infrastructure where we are,

1. Not able to spin new machines dynamically and throw away stacks
2. Don' have ability to add/remove instances dynamically using scripts from load-balancer
3. Network level configurations are done manually like firewall setting

Also keeping full in-active stack didn't sound good idea. Now we had to made some modifications to achieve zero downtime using blue-green deployment.

Decision 1: We took out database from the application deployment stack. Since we were using NoSQL MongoDB database, it didn't require any schema migration etc. However, we required to follow design principle, always write code which is backward compatible with the data models. And if there is any database migration required it should be run after deployment.

Decision 2: Use RPM to package apps and run like a service to start and stop. This enabled us to deploy application easily with the standard chef recipes. All application components are packaged as RPMs and published to repository from CI pipeline. Standardise deployment process across all components/application. We used FPM gem to build RPMs.

Decision 3: All application/component should provide 2 state heartbeat, live or standby, with ability to change the current state of the heartbeat at runtime using api call. Configure one load-balance to listen to live heartbeat and another to standby. Allows to add/remove instances from load-balancer by changing heartbeat state.

And with above changes the deployment steps are,

 

Step 1: Change heartbeat of the green stack to state 'standby'. This will remove green stack from LIVE load-balancer pool and no new request send to green stack.

 

Step 2: Deploy latest version of the application to green stack. Wait sometime to complete the inflight request on green stack before deployment.

 

Step 3: Sanity test green stack using standby load-balancer. Ideally automated, this will make sure deployment is good.

Step 4: Revert heartbeat of the green stack to state 'live'. This will put the green stack back to LIVE load-balancer pool.

If you notice the blue stack running on v1 and green stack running on v2. And both the stacks are connected to same database. Which means v2 codebase should work with old data models. And if there is any database migration should be carried only after all stack upgraded to latest version.

Step 5: Repeat above steps for blue stack,

 

And finally v2 deployed fully,

 

Step 6: Optional, run database migration (independent of the deployment)

 

What we achieved is, at any give point of time either blue or green stack is actively servicing the requests without downtime.  

 

However, the one point to note here is that during deployment only half capacity available, which means deployment should be avoided at peak load time. 

转载于:https://my.oschina.net/qiangzigege/blog/986675