今年在原版spinnaker的基础上我们和云平台厂商合作支持了阿里云和腾讯云，俗话说“是骡子是马拉出来遛遛“，今年的跨年晚会弹性部分将完全交给spinnaker来处理。现在是圣诞夜，我和小伙伴们还在spinnaker平台上加班做容灾和扩容，希望一周后的”多云多活极致弹性“能给2019年画上完美的句号。
以下是云平台在实现spinnaker时遇到的一些问题，同时也是自动化持续部署需要注意的共性的地方，一起拿来出分析下，与君共勉。
1 弹性伸缩组带宽瓶颈
无论是哪种云，都需要考虑到一个弹性需要接入多个“流量入口“的场景。
阿里云，需要考虑接入多个虚拟服务器组来根据path做不同转发的场景，而且也需要要考虑作为默认服务器组接入多个LB，因为阿里云的LB将会成为带宽瓶颈，通过对接多LB可以扩展入网带宽。
腾讯云的带宽瓶颈配置在LB后端的实例上，实例的总带宽决定了整体弹性带宽能力，所以配置实例时需要把带宽放到最大。
2 弹性需要具备多AZ的能力
弹性伸缩组配置时需要配置多子网，每个子网属于不通的区，例如选择北京CDEF四个zone。一方面是通过散列部署的方式避免云平台某个区出现故障时整个弹性挂掉，另一方面当云平台资源紧张时可以保证能扩展出实例。
这一点是阿里云比腾讯云做的优秀的地方，腾讯云虽然云控台上支持多AZ，但是我亲测后开出的机器都会落到一个区。
3 弹性需要具备多实例类型的能力
多实例类型并不是必须的，是为了应对资源紧张时的一种方案，尽可能地开的出机器。
4 Deploy环节流量割接需要严谨的判断服务能力
服务能力的判断分为两个维度：能否提供服务和能否提供足够的服务。
4.1 能否提供服务
LB通过健康检查来判断某个实例是否能够提供服务，然后决定是否往这个实例调量，所以一定要保证LB中配置的健康检查路径代表真实的服务情况。工作中发现有些产品把nginx静态文件作为健康检查路径，这是大错特错的，因为nginx活并不能代表你的服务是活的。
像搜索引擎等需要预热的场景也要考虑周全，因为那些服务需要把磁盘内容加载到缓存中才可以被调量，否则缓存层是空的压力一下来直接被打死。
4.2 能否提供足够的服务
一定要判断弹性伸缩中实例的个数，这个是血的教训。
Spinnaker中有一种红黑发布，可以选择按照现有弹性伸缩组的实例个数来进行红黑发布，我平时使用中都没有发现问题，直到跨年前资源比较紧张的时候由于云资源内部实例售罄导致新的弹性伸缩并没有开足，而LB到这个新的弹性伸缩所有实例的健康检查都是通过的，所以就做了流量的割接，LB打往老弹性的流量全部放给了新弹性，结果新弹性由于服务能力不足险些被打挂。
后来紧急修复了这个bug，也给我敲醒了警钟，凡是涉及生产流量割接的问题一定要对服务能力有充足的判断。
5 弹性伸缩组中的弹性规则需要完整继承
弹性伸缩组最大的好处是可以弹性伸缩，弹性伸缩是伸缩规则+伸缩触发组成的。不同的云平台在配置上略有区别，但是原理都是相通的。先配置好伸缩规则，代表你的伸缩组是要缩容还是扩容，缩容扩容几台机器或者到什么程度；再去配置伸缩触发，一般包括schedule和报警规则两类，前者适用于潮汐型的业务，后者用于非周期型也就是突发型的业务。
以上的配置基本都比较复杂，而且涵盖了一线运维人员的部分心血，所以当spinnaker进行deploy版本迭代的时候一定要保证把这部分继承过来，否则表面上看起来版本发布成功，但是已经失去了弹性的特性。
6 临时实例清理机制
Spinnaker是通过packer的方式来做bake的，正常运行中不会有问题，但是总会有些特殊情况会导致临时实例删不掉造成经济上的浪费。
我目前能总结出来的场景有：1，bake过程中rosco异常 2，云平台申请不到bake所需要的实例 3 云平台内部错误导致镜像制作超时。
所以我们需要一个至少以每天为周期的扫描机制去云平台查询有没有packer没有释放掉的资源，在bake是给这些临时实例规定命名规则或者标注tag，然后交给serverless定期去清理它们。
7 自定义镜像一定要最小化
Bake用的基础镜像越小，基于这个基础镜像制作出的业务镜像也就越小，从时间成本上讲bake一次时间越短，从经济成本上讲，bake一次自定义镜像占用的磁盘越小，越省钱。我每次拿到200G甚至300G的镜像时总是一脸茫然，当我去询问为什么这些镜像要做的这么大的时候答案也是让我哭笑不得。因为有些业务场景必须把一部分内容落到本地，然后定期再从本地拿走，当访问量特别高时就会占用很高的磁盘空间。但是他们搞混了一个概念，镜像大小和实例大小是不一样的，我们可以拿50G的镜像开出300G的实例，但是用300G的镜像缺开不出50G的实例，所以镜像一定是做的越小越好。
8 高并发前要把LB做散列
核心的LB列表需要提供给云厂商让他们后端帮我们做好散列，否则你的LB在云后端都在一台机器上也会有能力不足或单点故障的风险。
9 Spinnaker自身的调优
9.1 Redis扩容
Spinnake定期采集云平台资源缓存到redis，deck看到的资源都是redis中的信息，所以当跨年晚会这种高流量场景下我们扩展了机器后也需要关注spinnaker的redis能否支撑这么多机器。
9.2 可以关闭Rosco
Rosco是负责做bake镜像的微服务，但重大活动前往往会对软件封版，所以我们可以关闭rosco为其它微服务腾出足够的硬件资源。
9.3 CloudDriver JVM调优
CloudDriver是调度和采集云平台资源的核心微服务，所以需要关注下它的服务能力能否足够监控这么多资源。
