CaaS在微服务开发运维中的最佳实践

• 自定义命令/HTTP等健康检查
  再比如说自定义的 HTTP 命令,定义负载均衡的时候,可以指定一个URL,表明容器里的服务是不是健康的.

  没有这个功能的时候,系统只知道 Docker 这个容器是不是正常在跑,没办法判断 Docker 里面的应用是不是真的是活着的.自定义命令和 HTTP 这种方式是在 从Docker1.12 开始引入的.在这之前,阿里云的容器服务已经实现了这个功能.

• 按照资源约束的调度和再平衡.
  资源约束的意思是这个应用需要多少资源,根据资源约束来部署运行容器.
• 节点故障自动重调度

我们经常碰到的一个问题是容器是没有状态的,容器挂掉了,或者容器所在的节点挂掉了,另外一个容器起的时候要保证当初挂的那些存储要跟着迁移过去.

有的服务天生就喜欢和有的服务在一块,比如说一个 Web 应用就喜欢和数据库服务待在一个节点上.有些服务天生不喜欢在一块,假定做了一个数据库主备别把它们放在一个节点上.

跨可用区调度意思是,假定我的应用必须是高可用的,实例要分配在多个可用区中.这些要求也可以通过声明的方式来描述,不用写脚本.

3.2 微服务上线发布策略

最后一个是服务的发布策略,做 Devops,关注自动化从头到尾只是解决了第一步,第二步是部署,部署和上线发布的策略问题.

我们知道新服务的第一次部署可能在公司创建的第一天就完成了,随后每天都是在升级都是在发布,发布如果解决不好了,Devops 做的就是比较华而不实了.

现在业界有很多讨论,我们到底有哪些发布策略,这是网上的一些图：

• 有蓝绿发布,老服务在这运行着,部署新的服务,我们称之蓝色服务,服务起来了以后,不把流量切换到蓝色服务上,验证蓝色服务,如果没问题了再切换过去,把绿色服务删掉.

  在这个过程当中只有短暂的一个流量切换的过程,这是蓝绿发布,意思就是两个集群的流量从零到百分之百,要么是零要么是百分之百.下面这个图大家可能看不太清楚,跟这个很类似,这是老的这是新的服务,这里面流量不是百分之百,应该是5%或者是95%,意思是逐步切换,.

• 还有一种模式是金丝雀发布模式,正常老的服务都是粉色的,金丝雀是新版,叫金丝雀是因为在矿井里面,金丝雀对瓦斯特别敏感,稍微有点危险信号就死掉了,我们先放一个金丝雀,如果代码没有问题,就可以慢慢把所有的服务升级上去.
• 最后一个图是AB测试,实际上是一种验证措施,假定新上线的页面,我们需要检验它的作用,可以把流量分成两半,对于用户来讲看到的是同一个页面,但是后面左右两个不同的服务,通过一段时间的观察,看看同样的流量情况下面,运行的效果是不是都有变化.

（编辑：东莞站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!