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

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

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

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

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

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

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

3.2 微服务上线发布策略

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

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

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

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

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

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

所有的这些发布模式,在网上都有很多讨论,也都有很多实践,如果自己完全都是从头搭也可以.但是如果里用了 CaaS 服务,平台应该提供这些能力,你不用再自己搭了.所以说在容器服务里面,Devops 最后环节里面最后这一公里给你解决了.

小结

这里我说微服务是冰山一角,冰山下面实际是最大的一砣,分布式系统部署运维,服务治理,还有一个我们刚才没说的应用服务化改造.

这里总结一点,我们看微服务冰山一角是非常亮的,但是底层的支持东西是非常重要也是非常大的,这是我们运维人员要做的事情,也是一个 CaaS 平台想为运维人员所能提供的一点帮助,这个帮助就是我刚才提到的六个方向.

文章来自微信公众号：高效运维

（编辑：ASP站长网）