前言

本文给大家分享的题目是《基于DevOps、微服务以及K8S的高可用架构探索与实现》。整个企业的高可用架构面临很多的挑战，面向微服务、容器化以及敏态交付，是我们现在的三驾马车，而今天提到的一个比较接近的概念叫Kubernetes、DevOps和微服务这三驾马车也能够帮助企业级应用解决他们传统的一些问题。

本文给大家分享的主要内容都是从金融和通信领域中的具体案例总结而来，通过这次分享希望对大家能有所借鉴。主要内容包括企业级高可用性架构面临的挑战，面临这些内忧外患的挑战我们应该怎样做才能突破这样的困境，有哪些原则和方法。

然后Kubernetes、DevOps和微服务这三架马车如何各司其职为我们带来很好的高可用性架构，以及大家也知道面临的各种弹性的扩容需求。比如说我们的客户在517电信日的时候，他们的需求可能是平时业务量的120多倍，这样的情况下我们怎样进行弹性扩容，这都是我要跟大家分享的内容。

一 企业级高可用性架构的挑战

企业级高可用架构面临哪些挑战，其实有很多，可能有遇到天灾的挑战。

比如说2011年311大地震的时候我正好在东京，当时在做一个金融系统的相关工作。那次大地震导致很多很多的问题，虽然大地震不是在东京发生，但是还是给我们的系统造成了影响。

当时根据我们的系统和容灾备份中心进行合理调整，保证了我们的客户，因为我们的客户也是整个亚洲很大的一家银行，保证他的业务正常运行，这一切都是我们提前需要考虑才能做到的。

除此之外还可能有很多人为的Miss带来的问题。比如说，我们的一个银行客户，误删除根目录，这样的事情在十年之内发生了两次，其实只要保证节点的冗余性，就不难解决。

我们说企业级高可用性架构面临的天灾人祸的挑战，我们怎样才能保障它。

我们要事前考虑好这些因素。比如说我们可能会有应用程序的异常退出、有操作系统宕机、服务器的宕机、停电、大地震、人为操作失误、访问量突然增大，原本是没有问题的，我们企业是高可用的，但是突然业务扩展了100多倍。

我们在设计时是有一个原则，比如按照10倍设计，按照1.5倍测试，按照1.2倍发布这样都是可以的。但是突然扩大100多倍我的架构是很难实现的，所以动态扩容也是一个重要的课题。

这些挑战有这么多，其实我们还可以把整体的变得更加复杂。整个系统非常非常复杂，在整个金融领域当中可以看到复杂的架构比比皆是，复杂到什么程度呢？

举个简单的例子，日本超大银行的核心外汇系统来说，它大概有1500万行代码，我们之前还讨论过1500万行代码是什么量级。2006年我在做松下手机的开发时，总的代码大概是600万行，所以是3个手机的量，我们并行编译需要8小时，有4种操作系统，5种编程语言，倒不是说设计架构时就要变成这样，是因为很复杂的业务结合在一起就已经是这样的现状。

整个这样的一个系统，怎样才能保证高可用，我们有很多不同系统的集群，整个结合起来这么复杂、庞大的金融怎样才能保证整体的可用性，而且我们还要重构。这些给我们带来都是非常大的挑战，而且变更越来越多，频度也越来越大，还要求稳定性，因为我们的客户都会要求，你又要快又要好。

他们的要求也不过分，但是对于我们的实现来说，这其实是很难的。客户有的时候说我就改了一个Bug为什么不让我上线。这么大的架构我全编译都要8个小时，你改了这一行bug，那编译的过程你看不见吗，1500万行代码，要编译3个安卓手机。但是这些客户不会说，他会说我的同行他们做的就这么快，这都是我们面临的压力。

今天我也会给大家举一些案例，金融我个人接触的行业中也分为到两种，有传统的金融，他们还是以稳为主，今天的一些案例中就是一些稳的，还有一些是快的。所以我们的容器化并不一定都是需要快。

我们讲三架马车，这三架马车到底怎样开，开起来稳不稳，怎样进行扩展，这过程中我们需要注意什么，我们有些实践，不敢说最好的，但是可以给大家带来借鉴。

二 高可用性架构整体设计

整个来说高可用有这么多的挑战，如何进行整体的设计和架构。我这里的话列出了一些简单的点。

2.1 高可用性架构目标

我们说一个系统比较好的可用性，我们说它有良好的扩展性，整体是容易维护的，最重要的对客户来说，我这个系统是随时用都是可用的，很简单，我的系统拿出去至少能够跑起来，客户能访问。

所以我们讲整体业务的连续性和稳定性，对于我们高可用性架构是最重要的。

我们业界经常说几个9的目标，我们讲99%其实是系统基本可用。99.9%，这个系统是具有高可用性的特点，这是说，我们一年可以有8.8个小时可以把我们的系统停下来。更多来说，比如说银行，我们更多是做到4个9。这也结合了2017devops现状调查报告来说，高绩效的企业，他的业界banch　mark，平均下来他的MTTR的时间大概在一小时，也就是你的系统停一次，一年大概保4个9，如果停两次的话，那4个9的高可用就保不住了。

但是我们不一定要我们的系统一定是为了冲几个9，要看业务需求是否需要达到这个情况。我给客户做的时候，会跟他说你的高可用目标，为什么先列目标，因为目标定下来后，你的成本就会出现，如果1500万行代码全部要4个9或者5个9的，其实我们是做不到的。我们核心的系统、关键的领域，甚至是2个9都无所谓。

有一个二八定律，80%的功能客户基本上很少用，我们做的很复杂的功能，客户都不用，这也是一个现状。所以那些东西并不一定要达到4个9的可用性，所以目标设定非常重要。

除此之外，RPO和 RTO，从业务恢复的角度以及数据连续性的角度，对我们高可用性进行整体的规划。我们国家2007年发布了容灾备份相关信息产业的标准，将RPO和RTO分成六级，大家有兴趣的可以看一下，其实不同行业在做的时候应该是先定目标，这个成本就出来了，然后再往下做高可用架构的设计，这样才能往下细分。

比如我们要达到5个9，你一年只有5分钟，我要这样做。比如说我们的应用程序突然停了，既然停了把它重启起来就可以了，无论哪种方式都是这样的。但是关键是你是5个9，一年只有5分钟怎么办？你的策略就不一样，你是不是应该保证两个方式双方都能正常运行的时候你再起另外一个。所以整体策略不同，成本也会不同。

2.2 高可用策略和手段

整体的策略和手段有很多。我们提高可用最重要的一点是冗余。

我们会使用冗余的方式，你的一个application宕了，它要能访问，那一定是在另一个地方有备份，客户才会访问到。如果你的Note也宕了，一定是其他的地方也有备份。我们保证Application在一台机器上有多重运行，如果这台机器宕了的话，在另一台上也有运行，无论是哪种方式，它都是基础的策略。

除此之外，我们会结合成本，做Active-Standby或Active-Active的方式，然后我们做高可用的架构其实是说，我们的两台机器都放上去，一台机器一直是做一主一备，这对客户来说成本投入没有这么好，我看不到收益，所以我们一般做Active-Active双活。

比如我们做集群是保证节点级别的可用性。我们做服务多重化是保证应用层级的高可用性。我们做容灾备份，就像刚才给大家举的例子，2011年日本大地震，如果我们给客户没有做容灾备份的东西，他不可能依然能保证在整个过程中是可用的。

虽然是一主一从，但是两者相互结合还是能保证他的服务正常运行。但是除此之外，还有很多的因素。成本是无处不在。而且我们的客户也会知道，容灾备份中心做成两活其实是更好，但是成本会发生更大的变化。

另外我们平时的训练，因为这跟技术无关，但是又非常的重要，因为我看过很多的系统，他们做得都很好，但是为什么他不敢切。

我看过太多很好的系统，但是有的系统我也没见过，像2015年左右，纽约交易所停了218分钟，这么庞大的一个系统停了218分钟，后来我查了原因，他们说是因为技术的原因，后来我就没看出因为什么技术的原因。

但是我相信他一定会有容灾备份的策略，但是为什么不切。实际我接触过很多企业，他们训练不到位，导致他们不敢切，切过去OK，切回来怎么办？可能就会出问题。

除此之外，还有横向的扩容，我们的波峰来了，我们什么时候才能进行扩容，所以这个时候我们需要考虑。我们讲跟DevOps进行结合，我们监控做到我们能够确定什么时候进行横向扩容。

比如说DevOps的透明化和我们整体的可视化结合起来，然后这些能够保证我们系统的高可用性进行很好地对应，这是整体的策略和手段，当然还有很多，我只是列出了这几个常见且重要的点。

2.3 要素和原则

我们叫容器化、微服务和DevOps，是我们现在应用容器化的三架马车可能更敏捷的对应。因为K8S本身就是容器和容器编辑的平台，可以很好地进行管理。我们使用这三架马车如何才能保证我们的系统更加可用、方便和灵活。K8S是用什么样的方式来保证它的高可用性，首先有三个重要的点：

• 第一点，K8S是以容器化为基础的，运行在它上面的应该是一些容器，以容器形式存在的这些服务，K8S 平台保证了这些服务它本身是可用的。我们传统的，自己写SOA其实也是一样的，只是k8s做的更好，它把这些变成透明化了。
  
  

• 第二点，我们保证K8S本身是可用的，因为K8S保证它的集群运行在这之上的服务是ok的，但是同时，怎样才能保证K8S它也是高可用的，消除这些单点我们也会说到这些。
  
  

• 第三点，当我们业务的波峰来的时候我们如何处理。
  
  

然后我们讲微服务，微服务为什么要引入，各个企业有自己的想法。我们引入微服务有很多自己的想法，比如要简化，要解耦，要使我们的服务能够独立部署，它要能够进行整个是无状态可回滚的，整个来说我们是为了让容器化变得更加简单，这些微服务要按照这样的策略进行设计。

我们讲DevOps是怎样做成桥梁和纽带在微服务和K8S之间进行沟通。首先我们使用DevOps的理念，微服务的一旦落地，它带来的好处同时也给我们的部署也带来有压力，所以我们如何做持续集成和持续交付，使得这些部署，应微服务带来的部署这种压力得到缓解，这是我们Devops实践需要考虑的事情。

同时，我们通过环境的一致性，通过考虑安全的因素，使我们高可用性在很多方面得到整体的考虑。我们提到DevOps跟K8S自动的可动态的横向的调整，K8S如何才能知道我们什么时候进行横向调整。我们需要监控的机制，而我们DevOps的实践中，我们需要让整个的过程是透明的，可视的，所以我们通过使我们的系统具有整体监控的能力，让我们知道什么时候该横向扩容。

这是一个很简单的例子，我们说整体的做一主多从的K8S架构的话，可以看出，这就是简单的K8S的构成。K8S可以做成一主多从，同时我们的ETCD使用集群的方式来保证它的服务OK。消除单点的话就是Master一主多备，这是非常典型的很简单的思路。无论哪种方式，我们都是要保证它的冗余度得到保证。

如何使得我们的微服务更加专注于业务的开发，我们在与我们的客户进行实际应用时也使用一些传统开箱即用的，比如说Spring Cloud等一些组件。帮助他整体的下面的框架基本上就不用再进行开发了。

我们传统用Tuxedo时，都是要自己写。突然会发现压力一下全部减轻了，我们只需要注重业务的开发，突然发现非常顺畅。

我们讲DevOps他更多地是一种融合，所以我们最佳实践进行结合，通过自动化流水线，保证了自动部署和自动集成的稳定性。

通过可视化的监控来确认我们什么时候可以动态扩容，通过一致性的环境来保证整个的流程是更加顺畅的。

所以这是我们整体的一个架构和思路。在很多的系统之中和客户进行推荐的时候我们基本上都是用这样的方式。

三 Kubernetes的基础服务

下面我们讲三架马车第一架Kubernetes如何提供基础服务。这些都是Kubernetes的基础知识，我们可以很容易地得到，但是我们讲使用Kubernetes的时候，在整个的架构中起到什么作用，还是刚才提到这三点。

第一点，我们使用Kubernetes的RC或Daemonset这些东西，我们保证了这些服务是可以自愈的，简单来说就是有人帮我检测、重启，这些策略都可以进行调整的。

第二点，Kubernetes本身是需要ETCD和Master始终是可用的，所以我们需要通过具体的策略来保证我们的K8S本身也是可用的，所以这两点能保证整个集群是OK的。我们Kubernetes提供基础的平台和服务，但是如果你的平台和服务它本身是不稳定的，也是无法达到整个系统高可用的。我们讲这个平台应该比较厚重，同时也要比较稳靠，这是我们需要考虑的，我们实际跟客户落地的时候，这些点都需要考虑，我列出了其中重要的几点。

我们消除单点的ETCD。ETCD是CoreOS发布的关于键值的分布式数据存储。在Kubernetes之中，我们使用apiserver跟它进行交互，如果它不稳定，我们数据的保存就没有保障，所以我们要消除它的单点，那做一个集群就可以了。

我们做一主多备的Master。我们的Active Master一旦坏掉了切到另外一个，很简单就是冗余，多放两个在那里，坏了就切过去。理论上来说都非常简单和单纯，但是就用靠这种单纯和简单的方式，就能保证我们的客户的整体系统比较稳定。

就像在311地震的时候，我们给一个日本的核心银行的系统，做了一主一从的方式就能保证系统是高可用，所以我们事前需要考虑，同时考虑成本和整体策略，然后给客户提供一个价钱和其他东西结合的一个方案。

第三点，就是Kubernetes能够应付现在传统金融在做动态扩容时很难做到的一点。使用传统的方式，当客户想追加节点的时候很困难。客户想增加一个节点时会发现非常困难。

我们传统的方式做集群的话，我们可以做双机或者多机，或者是做其它的都可以跑。但是我要加一个节点很困难，大家知道如果我们开始做架构时，上来就是说你使用了Kubernetes这种神器，或者是你程序本身都是容器化的，你就碰不到这种困难。

但是如果你从十几年前开始做架构，会看到传统的这种架构一步步怎样走过来的时候你就会发现，这些真的是很厉害的神器。

为什么传统金融在往这方面靠的原因，我们加一个Node的时候，做一个双机集群，我们要自己划磁盘，自己划磁盘的仲裁，做心跳线，做设定。虽然做得很快但是也特别费工夫，关键的是对客户来说，你要把这些机器停下，这些是要命的，而且花了很多的钱，而且对于K8S平台来说这些都是透明的。

这是对客户来说非常有意义的点。也是我们推它的原因。在使用监控，首先第一步看到整个的趋势，问题会不会出现警告。同时对我们的动态扩容提供输入。

对动态扩容提供输入，我们整个动态扩容怎么做？我们做了简单的整理。其实一旦你把所有的条件做好，剩下的都非常简单了。

我们有些通信的客户可能在波峰的时候可能他的具体的业务量达到平时的一百多倍，这种情况下怎么办，找到时间点扩容就可以了。

我们还是按照步骤，定义业务、系统资源的指标，在这种情况下扩几个pod，然后采集数据。那我们怎么知道这些是可以进行扩展的，然后具体的监控是实现说我看系统的日志和业务的日志我们可以扩了。在Kubernetes或Swarm层上面一条命令就可以做到了，这就已经很简单了。

但是最关键的是我们之前需要做的这些，监控怎样做好，我们给客户的最佳实际案例是这样做的，不要上来就开始做这个自动。自动化其实可以做到最后再做，我们要保证整个流程是平稳的。

比如说举个简单的例子，我们在金融的系统是这样做的，我们如果想做什么样的调整，比如说我要做这样的动态调整，我会把整个的东西打到日志，把空跑的状态确认出来，然后根据事后我们进行分析他算错没算错。做完之后，再做动态的扩展，动态扩展相当于一个利器，很好用，但是用坏了也很危险，在具体实践的时候，我们跟客户实践了以后才会做。

如果Kubernetes提供了这样一个基础服务，微服务就很轻松了。比如说我们传统在做Tuxedo架构的时候，我们做微服务的自动重启，坏掉了怎么办？如果使用自己的SOA架构，你在里面写循环，你自己总不能启自己，需要有一个守护进程在后面做，守护进程宕了怎么办？因为企业级高可用架构，尤其是银行不可能像目前初创公司的做法，他要求他的系统一定是非常稳定的，你守护进程坏掉我也得保证，所以我们一般会再写一个，再坏了怎么办，没完没了的，所以那个要靠监控来做。

你要使用Tuxedo的话，就很简单，在里面设定一个什么时候这个Sever等于Y，这个架构基本可以保证服务的多重化或者节点之间的控制。但是有一个很不好做的东西时什么呢。这是一个整体的SOA架构，你要进行全部编译，这意味着你做服务动态调整要通过编译来做，这就很麻烦了。这个相对于Kubernetes的方式很不灵活。

四 专注于业务实现的微服务架构

使用了Kubernetes这种方式后，就会更加灵活，使我们的服务专注于服务的架构开发。

即使是这样，我们依然有很多的东西需要考虑，我们为什么进行微服务的设计和架构，这有很多很多的痛点。

就是说我们大型的系统一旦出来，就像多米诺骨牌一样，你拉其中的一块，就会整个轰塌。以我十几年的工程师经验，这个过程是非常痛苦的，痛苦的人都知道怎么来的。

我只改了一行代码，为什么整个程序宕了，整个应用毁了，这种情况会出现的。因为随着年久失修，这些大型的系统，它会成为巨石一样存在，谁都不敢改，改起来成本又非常大，维护的成本也非常高。

我接触过很多大型项目，跟他们一起做他们做得非常优秀，但是即使这么优秀的企业我们还是发现了很多有意思的事情。

比如说当年Alpha推出市场的时候，原本在Alpha上运行的话我们转到Hpux上，当然有一部分跑到了IBM的AIX上，但是无论你跑在哪种上面，如果有C这种通过编译型语言的话，你要进行重新编译和优化。

一个很有趣的规律就是超过百万行级的代码我们都会发现非常低级的bug，不管系统多么优秀。有一条到现在没破，我们知道像C这种父子语句和判断语句肯定会有用混的，If写成父子语句的，有专门的把两行写成一行，就是为了省一行空间的写法也有。我们明明确确的根据上下文判断就是一个进或不进，改不改。这就陷入两难，因为它有上百万的代码。

一个工程师我只负责以前在Alpha上面跑，现在在Hpux上跑，你们不是跟我说，我只是换一个机器，剩下都OK吗，为什么不OK了？所以我们不敢改，因为很多时候时错错得正，你改了这个地方其它地方还有一个错，最后结果正确的我怎么知道。

这个难点在于，还是整个的耦合度没有拆分，这种情况下如果你的功能很小的话那就很好办了。如果部署能够独立化，解耦做得很好，简化做得很好，规模又小型化，这样我们知道这块影响到哪儿，大不了我把它重新用backup运行。我知道它影响到哪个地方，只有不知道，我们才害怕，而且不知道可能真会出现各种问题。

所以这个才是我们实际与企业级客户在推的时候遇到的问题，企业级用户痛点也在这里，因为客户很多时候就问我，我改一行代码为什么要花这么长的时间，我跟他说一天为什么花这么长的时间。确实要花这么长时间，因为你系统太复杂了。我们解耦以后可以治这个病，但是整个的过程也会带来其他的问题。所以我们整个过程需要进行考虑。

我们使用Spring Cloud，可以使我们过程中更加方便。通过适当冗余，使用多个Eureka服务端，这样就能保证保证服务注册不会停止。如果我们做Tuxedo的架构话要自己写，我们使用Eureka就更加方便。

我们还要考虑负载均衡，像Ribbon这种客户端。我想大家做过SOA开发，对这种策略都不难进行，就是有所反馈。比如说我们就讲，我坏了应该怎样重启，要加权、随机要重启，这台坏掉了我看另外一台机器有几个，跑在另外一台机器上，自己写这个很痛苦的。这些如果使用了开箱即用的东西会整体地加快我们的速度。

除此以外还有很多，我再列举一个配置中心。我为什么提它呢。我们讲三架马车，最终一架是DevOps，像Spring Cloud也好，我们推DevOps时，我们推荐使用一套的部署机制，你不同的环境可以通过不同的配置来实现，我们认为Spring Cloud是它对DevOps的一种微服务发布方式，我们通过整体的具体实践进行结合使得发布更加方便和顺畅，更多地是与DevOps进行结合。

有这样的东西开箱即用，对于微服务，我们就很容易写我们的SQL语句，实现业务逻辑，就会非常简单，实际在使用的时候，尤其是容器化的过程中IP会变来变去，这些问题都会带来困难的点。但是想想你要从零开始创建这些东西，它的成本是值得的。虽然有些人说你没办法做这些东西，但是你看看传统企业痛苦的程度。

五 DevOps助力全生命周期的高可用性

我们讲DevOps能够在其中起到桥梁和纽带的作用，辅助我们三架马车，容器化的服务能够更好的落地实践。具体地有哪些点，我列出了这样一些点。

5.1 环境一致性

我们强调开发和测试环境、生产环境的一致性。因为开发环境，经常会有不同环境的开发，可能会带来很多的问题。测试环境的话，由于测试和开发环境的不同也会带来问题，比如说你测试的代码和开发的版本不一样，这些不必要的消费都会带来不必要的时间。

所以这些都是需要我们考虑的，另外我们引入安全扫描的机制。因为2015年左右我看过一个研究，对于Docker Hub上面的镜像进行分析，大概有30%-40%的镜像是不安全的。

从今年开始Docker也是在最贵的那版里面引入镜像扫描的机制，同时CoreOS也提出了Clair，所以建议大家有空回去下一个，像Clair这样的东西对你的镜像扫描一下。

2014年的Heartbleed大家印象很深刻，那个心脏流血的，那个一直在流血，心脏就会失血而死亡，你可能就要搭桥，所有的买单都是企业级的客户来做，它要为你对安全的忽视来买单，这一切有可能是我们不能承受的，因为它在心脏上。我建议大家一定要下这样的东西看一下到底有多少的CVE。

然后生产环境保持一致性，这是理想的，但至少要达到 Infrastructure as Code。这考虑到什么呢，如果你的生产环境的一个节点突然坏掉怎么办？尤其是那些年久失修的系统，客户说给你拿一个机器给我立即换上，这是很简单的事情，那有太多的手工作业，你把这些手工作业全部都变成代码放到你的SVN或Git上，一定要这样做，我们在推这样的实践过程中也碰到很多的惯性的阻力，但是我们认为这样的实践很重要。

5.2 可定制流水线

我们讲可定制的流水线是非常重要的，安全检查也非常重要。可以定制的，可以提高我们CI/CD的流水线。可以使用开源的工具，也可以使用商用的工具。根据DORA调查，你使用可定制的话可以带来更好的效果。

5.3 可视化

监控，可以使得弹性扩容更加容易。

我们的一些客户，我们平时的业务量跟波峰的业务量相比是1%甚至更多，这种情况下怎么办？

六 弹性扩容需求下的高可用性

我们讲的三架马车每块需要做什么事情，在容器化的基础之上进行解耦和优化，同时DevOps要监控、判断，同时最重要的一点，我们要强调一下DevOps我们提倡的理念是Fail Fast，我个人认为这不是为了让我们die fast，你要做好我们的Plan B，我们recover plan，如果一旦失败了怎么办，如果事前不想好那真的有可能die fast。

所以我们提倡跟客户说你要Fail Fast，要戴好安全带，这点非常重要。根据DORA的调查，2017比2016年相比，我们的速度得到了明显的提高，但是那些低绩效的企业，他们在MTTR的修复时间比去年还要恶劣，这为什么？快了但是没考虑稳。

我们使用K8S能够很容易的进行横向扩展。具体的策略，通过确定交易的指标和资源使用情况，确认什么时候进行水平扩容，取一下业务日志和系统日志进行监控和计算然后告诉K8S扩容它就扩容，就是这么简单，但是实际应用的时候有很多的项，你在这个过程要保证安全，稳定地扩容。

七 案例分享案例 1

我们通过应用的多重启动，来保证应用的可靠。Front office和back office 进行前端的业务和后端的审批，这都非常常见，大部分都执行这样的做法。

另外，我们过去传统来做，可以看到整体的集群非常复杂，你有文件集群、应用集群、认证集群、RAC集群。而且这些资源相互之间协调非常痛苦，如果你出了问题了，依然有很大程度的可用性。

但全坏掉了，我们通过什么办法。通过共享存储和网络结合起来，跟容灾备份中心结合起来，它的数据一旦过去之后，另外一套系统结合起来，可以使它能够保证数据中心级别的可用性。

应用级别可用性，节点级别的可用性以及数据中心级别的可用性，我们都能达到。同时，这种传统的问题点，客户也问过我这个问题，他说，我加一个node，你们为什么花我这么多钱。

有一次，我们跟他说应用级别的资源不够了，加一个resource吧，他的文件集群依然有resource，你告诉我应用集群不够了，你用它的不好吗。我说，作为一个工程师来说，这个很难。他说我不管为什么难，我只看到我的系统，它依然有一部分是闲的，你没有做到。它做不到并不表示其他做不到，比如K8S就可以做到。

案例 2

这是一个典型的案例，是跟我们通信领域的一个客户做的在PaaS平台上运行微服务的架构。我们也实现了多Kubernetes集群的状态下，我们的双中心的这样一个应用。双中心双活，整体的话与刚才那个例子相比是有优点的。同时我们讲我们实现了按需扩容，怎样进行按需扩容，其实就是监控，监控的过程中注意安全，我们定期对客户安全进行扫描。希望大家注重安全，不要认为官方镜像的就很可靠。

我们会根据我们业务的，比如说我们达到300单/每秒业务的要求就会扩容。你CPU连续超过一段时间都超过了75%，那好生成一个Pod。很简单，所有这一切源于需求。我们刚刚提到了517电信日，订单的业务量增加126倍；京东618订单量也相当于平时10倍，这些都是给我们传统方式带来挑战的。像刚才金融的方式，就很难解决这个问题。

我们可以看到在应用级别的可用性，以及节点级别的可用性和数据中心的可用性，我们都可以以简单的例子进行分享。其实我们与电信客户做了很多的设计，跟金融的也有很多，今天举出这两个例子，主要是让大家进行对比。很多时候，我们在进行一个转型，转型的过程中怎样进行参照和思考，这是我今天给大家带来的分享的主要内容。

原创：刘淼

前言

本文给大家分享的题目是《基于DevOps、微服务以及K8S的高可用架构探索与实现》。整个企业的高可用架构面临很多的挑战，面向微服务、容器化以及敏态交付，是我们现在的三驾马车，而今天提到的一个比较接近的概念叫Kubernetes、DevOps和微服务这三驾马车也能够帮助企业级应用解决他们传统的一些问题。

本文给大家分享的主要内容都是从金融和通信领域中的具体案例总结而来，通过这次分享希望对大家能有所借鉴。主要内容包括企业级高可用性架构面临的挑战，面临这些内忧外患的挑战我们应该怎样做才能突破这样的困境，有哪些原则和方法。

然后Kubernetes、DevOps和微服务这三架马车如何各司其职为我们带来很好的高可用性架构，以及大家也知道面临的各种弹性的扩容需求。比如说我们的客户在517电信日的时候，他们的需求可能是平时业务量的120多倍，这样的情况下我们怎样进行弹性扩容，这都是我要跟大家分享的内容。

一 企业级高可用性架构的挑战

企业级高可用架构面临哪些挑战，其实有很多，可能有遇到天灾的挑战。

比如说2011年311大地震的时候我正好在东京，当时在做一个金融系统的相关工作。那次大地震导致很多很多的问题，虽然大地震不是在东京发生，但是还是给我们的系统造成了影响。

当时根据我们的系统和容灾备份中心进行合理调整，保证了我们的客户，因为我们的客户也是整个亚洲很大的一家银行，保证他的业务正常运行，这一切都是我们提前需要考虑才能做到的。

除此之外还可能有很多人为的Miss带来的问题。比如说，我们的一个银行客户，误删除根目录，这样的事情在十年之内发生了两次，其实只要保证节点的冗余性，就不难解决。

我们说企业级高可用性架构面临的天灾人祸的挑战，我们怎样才能保障它。

我们要事前考虑好这些因素。比如说我们可能会有应用程序的异常退出、有操作系统宕机、服务器的宕机、停电、大地震、人为操作失误、访问量突然增大，原本是没有问题的，我们企业是高可用的，但是突然业务扩展了100多倍。

我们在设计时是有一个原则，比如按照10倍设计，按照1.5倍测试，按照1.2倍发布这样都是可以的。但是突然扩大100多倍我的架构是很难实现的，所以动态扩容也是一个重要的课题。

这些挑战有这么多，其实我们还可以把整体的变得更加复杂。整个系统非常非常复杂，在整个金融领域当中可以看到复杂的架构比比皆是，复杂到什么程度呢？

举个简单的例子，日本超大银行的核心外汇系统来说，它大概有1500万行代码，我们之前还讨论过1500万行代码是什么量级。2006年我在做松下手机的开发时，总的代码大概是600万行，所以是3个手机的量，我们并行编译需要8小时，有4种操作系统，5种编程语言，倒不是说设计架构时就要变成这样，是因为很复杂的业务结合在一起就已经是这样的现状。

整个这样的一个系统，怎样才能保证高可用，我们有很多不同系统的集群，整个结合起来这么复杂、庞大的金融怎样才能保证整体的可用性，而且我们还要重构。这些给我们带来都是非常大的挑战，而且变更越来越多，频度也越来越大，还要求稳定性，因为我们的客户都会要求，你又要快又要好。

他们的要求也不过分，但是对于我们的实现来说，这其实是很难的。客户有的时候说我就改了一个Bug为什么不让我上线。这么大的架构我全编译都要8个小时，你改了这一行bug，那编译的过程你看不见吗，1500万行代码，要编译3个安卓手机。但是这些客户不会说，他会说我的同行他们做的就这么快，这都是我们面临的压力。

今天我也会给大家举一些案例，金融我个人接触的行业中也分为到两种，有传统的金融，他们还是以稳为主，今天的一些案例中就是一些稳的，还有一些是快的。所以我们的容器化并不一定都是需要快。

我们讲三架马车，这三架马车到底怎样开，开起来稳不稳，怎样进行扩展，这过程中我们需要注意什么，我们有些实践，不敢说最好的，但是可以给大家带来借鉴。

二 高可用性架构整体设计

整个来说高可用有这么多的挑战，如何进行整体的设计和架构。我这里的话列出了一些简单的点。

2.1 高可用性架构目标

我们说一个系统比较好的可用性，我们说它有良好的扩展性，整体是容易维护的，最重要的对客户来说，我这个系统是随时用都是可用的，很简单，我的系统拿出去至少能够跑起来，客户能访问。

所以我们讲整体业务的连续性和稳定性，对于我们高可用性架构是最重要的。

我们业界经常说几个9的目标，我们讲99%其实是系统基本可用。99.9%，这个系统是具有高可用性的特点，这是说，我们一年可以有8.8个小时可以把我们的系统停下来。更多来说，比如说银行，我们更多是做到4个9。这也结合了2017devops现状调查报告来说，高绩效的企业，他的业界banch　mark，平均下来他的MTTR的时间大概在一小时，也就是你的系统停一次，一年大概保4个9，如果停两次的话，那4个9的高可用就保不住了。

但是我们不一定要我们的系统一定是为了冲几个9，要看业务需求是否需要达到这个情况。我给客户做的时候，会跟他说你的高可用目标，为什么先列目标，因为目标定下来后，你的成本就会出现，如果1500万行代码全部要4个9或者5个9的，其实我们是做不到的。我们核心的系统、关键的领域，甚至是2个9都无所谓。

有一个二八定律，80%的功能客户基本上很少用，我们做的很复杂的功能，客户都不用，这也是一个现状。所以那些东西并不一定要达到4个9的可用性，所以目标设定非常重要。

除此之外，RPO和 RTO，从业务恢复的角度以及数据连续性的角度，对我们高可用性进行整体的规划。我们国家2007年发布了容灾备份相关信息产业的标准，将RPO和RTO分成六级，大家有兴趣的可以看一下，其实不同行业在做的时候应该是先定目标，这个成本就出来了，然后再往下做高可用架构的设计，这样才能往下细分。

比如我们要达到5个9，你一年只有5分钟，我要这样做。比如说我们的应用程序突然停了，既然停了把它重启起来就可以了，无论哪种方式都是这样的。但是关键是你是5个9，一年只有5分钟怎么办？你的策略就不一样，你是不是应该保证两个方式双方都能正常运行的时候你再起另外一个。所以整体策略不同，成本也会不同。

2.2 高可用策略和手段

整体的策略和手段有很多。我们提高可用最重要的一点是冗余。

我们会使用冗余的方式，你的一个application宕了，它要能访问，那一定是在另一个地方有备份，客户才会访问到。如果你的Note也宕了，一定是其他的地方也有备份。我们保证Application在一台机器上有多重运行，如果这台机器宕了的话，在另一台上也有运行，无论是哪种方式，它都是基础的策略。

除此之外，我们会结合成本，做Active-Standby或Active-Active的方式，然后我们做高可用的架构其实是说，我们的两台机器都放上去，一台机器一直是做一主一备，这对客户来说成本投入没有这么好，我看不到收益，所以我们一般做Active-Active双活。

比如我们做集群是保证节点级别的可用性。我们做服务多重化是保证应用层级的高可用性。我们做容灾备份，就像刚才给大家举的例子，2011年日本大地震，如果我们给客户没有做容灾备份的东西，他不可能依然能保证在整个过程中是可用的。

虽然是一主一从，但是两者相互结合还是能保证他的服务正常运行。但是除此之外，还有很多的因素。成本是无处不在。而且我们的客户也会知道，容灾备份中心做成两活其实是更好，但是成本会发生更大的变化。

另外我们平时的训练，因为这跟技术无关，但是又非常的重要，因为我看过很多的系统，他们做得都很好，但是为什么他不敢切。

我看过太多很好的系统，但是有的系统我也没见过，像2015年左右，纽约交易所停了218分钟，这么庞大的一个系统停了218分钟，后来我查了原因，他们说是因为技术的原因，后来我就没看出因为什么技术的原因。

但是我相信他一定会有容灾备份的策略，但是为什么不切。实际我接触过很多企业，他们训练不到位，导致他们不敢切，切过去OK，切回来怎么办？可能就会出问题。

除此之外，还有横向的扩容，我们的波峰来了，我们什么时候才能进行扩容，所以这个时候我们需要考虑。我们讲跟DevOps进行结合，我们监控做到我们能够确定什么时候进行横向扩容。

比如说DevOps的透明化和我们整体的可视化结合起来，然后这些能够保证我们系统的高可用性进行很好地对应，这是整体的策略和手段，当然还有很多，我只是列出了这几个常见且重要的点。

2.3 要素和原则

我们叫容器化、微服务和DevOps，是我们现在应用容器化的三架马车可能更敏捷的对应。因为K8S本身就是容器和容器编辑的平台，可以很好地进行管理。我们使用这三架马车如何才能保证我们的系统更加可用、方便和灵活。K8S是用什么样的方式来保证它的高可用性，首先有三个重要的点：

• 第一点，K8S是以容器化为基础的，运行在它上面的应该是一些容器，以容器形式存在的这些服务，K8S 平台保证了这些服务它本身是可用的。我们传统的，自己写SOA其实也是一样的，只是k8s做的更好，它把这些变成透明化了。
  
  

• 第二点，我们保证K8S本身是可用的，因为K8S保证它的集群运行在这之上的服务是ok的，但是同时，怎样才能保证K8S它也是高可用的，消除这些单点我们也会说到这些。
  
  

• 第三点，当我们业务的波峰来的时候我们如何处理。
  
  

然后我们讲微服务，微服务为什么要引入，各个企业有自己的想法。我们引入微服务有很多自己的想法，比如要简化，要解耦，要使我们的服务能够独立部署，它要能够进行整个是无状态可回滚的，整个来说我们是为了让容器化变得更加简单，这些微服务要按照这样的策略进行设计。

我们讲DevOps是怎样做成桥梁和纽带在微服务和K8S之间进行沟通。首先我们使用DevOps的理念，微服务的一旦落地，它带来的好处同时也给我们的部署也带来有压力，所以我们如何做持续集成和持续交付，使得这些部署，应微服务带来的部署这种压力得到缓解，这是我们Devops实践需要考虑的事情。

同时，我们通过环境的一致性，通过考虑安全的因素，使我们高可用性在很多方面得到整体的考虑。我们提到DevOps跟K8S自动的可动态的横向的调整，K8S如何才能知道我们什么时候进行横向调整。我们需要监控的机制，而我们DevOps的实践中，我们需要让整个的过程是透明的，可视的，所以我们通过使我们的系统具有整体监控的能力，让我们知道什么时候该横向扩容。

这是一个很简单的例子，我们说整体的做一主多从的K8S架构的话，可以看出，这就是简单的K8S的构成。K8S可以做成一主多从，同时我们的ETCD使用集群的方式来保证它的服务OK。消除单点的话就是Master一主多备，这是非常典型的很简单的思路。无论哪种方式，我们都是要保证它的冗余度得到保证。

如何使得我们的微服务更加专注于业务的开发，我们在与我们的客户进行实际应用时也使用一些传统开箱即用的，比如说Spring Cloud等一些组件。帮助他整体的下面的框架基本上就不用再进行开发了。

我们传统用Tuxedo时，都是要自己写。突然会发现压力一下全部减轻了，我们只需要注重业务的开发，突然发现非常顺畅。

我们讲DevOps他更多地是一种融合，所以我们最佳实践进行结合，通过自动化流水线，保证了自动部署和自动集成的稳定性。

通过可视化的监控来确认我们什么时候可以动态扩容，通过一致性的环境来保证整个的流程是更加顺畅的。

所以这是我们整体的一个架构和思路。在很多的系统之中和客户进行推荐的时候我们基本上都是用这样的方式。

三 Kubernetes的基础服务

下面我们讲三架马车第一架Kubernetes如何提供基础服务。这些都是Kubernetes的基础知识，我们可以很容易地得到，但是我们讲使用Kubernetes的时候，在整个的架构中起到什么作用，还是刚才提到这三点。

第一点，我们使用Kubernetes的RC或Daemonset这些东西，我们保证了这些服务是可以自愈的，简单来说就是有人帮我检测、重启，这些策略都可以进行调整的。

第二点，Kubernetes本身是需要ETCD和Master始终是可用的，所以我们需要通过具体的策略来保证我们的K8S本身也是可用的，所以这两点能保证整个集群是OK的。我们Kubernetes提供基础的平台和服务，但是如果你的平台和服务它本身是不稳定的，也是无法达到整个系统高可用的。我们讲这个平台应该比较厚重，同时也要比较稳靠，这是我们需要考虑的，我们实际跟客户落地的时候，这些点都需要考虑，我列出了其中重要的几点。

我们消除单点的ETCD。ETCD是CoreOS发布的关于键值的分布式数据存储。在Kubernetes之中，我们使用apiserver跟它进行交互，如果它不稳定，我们数据的保存就没有保障，所以我们要消除它的单点，那做一个集群就可以了。

我们做一主多备的Master。我们的Active Master一旦坏掉了切到另外一个，很简单就是冗余，多放两个在那里，坏了就切过去。理论上来说都非常简单和单纯，但是就用靠这种单纯和简单的方式，就能保证我们的客户的整体系统比较稳定。

就像在311地震的时候，我们给一个日本的核心银行的系统，做了一主一从的方式就能保证系统是高可用，所以我们事前需要考虑，同时考虑成本和整体策略，然后给客户提供一个价钱和其他东西结合的一个方案。

第三点，就是Kubernetes能够应付现在传统金融在做动态扩容时很难做到的一点。使用传统的方式，当客户想追加节点的时候很困难。客户想增加一个节点时会发现非常困难。

我们传统的方式做集群的话，我们可以做双机或者多机，或者是做其它的都可以跑。但是我要加一个节点很困难，大家知道如果我们开始做架构时，上来就是说你使用了Kubernetes这种神器，或者是你程序本身都是容器化的，你就碰不到这种困难。

但是如果你从十几年前开始做架构，会看到传统的这种架构一步步怎样走过来的时候你就会发现，这些真的是很厉害的神器。

为什么传统金融在往这方面靠的原因，我们加一个Node的时候，做一个双机集群，我们要自己划磁盘，自己划磁盘的仲裁，做心跳线，做设定。虽然做得很快但是也特别费工夫，关键的是对客户来说，你要把这些机器停下，这些是要命的，而且花了很多的钱，而且对于K8S平台来说这些都是透明的。

这是对客户来说非常有意义的点。也是我们推它的原因。在使用监控，首先第一步看到整个的趋势，问题会不会出现警告。同时对我们的动态扩容提供输入。

对动态扩容提供输入，我们整个动态扩容怎么做？我们做了简单的整理。其实一旦你把所有的条件做好，剩下的都非常简单了。

我们有些通信的客户可能在波峰的时候可能他的具体的业务量达到平时的一百多倍，这种情况下怎么办，找到时间点扩容就可以了。

我们还是按照步骤，定义业务、系统资源的指标，在这种情况下扩几个pod，然后采集数据。那我们怎么知道这些是可以进行扩展的，然后具体的监控是实现说我看系统的日志和业务的日志我们可以扩了。在Kubernetes或Swarm层上面一条命令就可以做到了，这就已经很简单了。

但是最关键的是我们之前需要做的这些，监控怎样做好，我们给客户的最佳实际案例是这样做的，不要上来就开始做这个自动。自动化其实可以做到最后再做，我们要保证整个流程是平稳的。

比如说举个简单的例子，我们在金融的系统是这样做的，我们如果想做什么样的调整，比如说我要做这样的动态调整，我会把整个的东西打到日志，把空跑的状态确认出来，然后根据事后我们进行分析他算错没算错。做完之后，再做动态的扩展，动态扩展相当于一个利器，很好用，但是用坏了也很危险，在具体实践的时候，我们跟客户实践了以后才会做。

如果Kubernetes提供了这样一个基础服务，微服务就很轻松了。比如说我们传统在做Tuxedo架构的时候，我们做微服务的自动重启，坏掉了怎么办？如果使用自己的SOA架构，你在里面写循环，你自己总不能启自己，需要有一个守护进程在后面做，守护进程宕了怎么办？因为企业级高可用架构，尤其是银行不可能像目前初创公司的做法，他要求他的系统一定是非常稳定的，你守护进程坏掉我也得保证，所以我们一般会再写一个，再坏了怎么办，没完没了的，所以那个要靠监控来做。

你要使用Tuxedo的话，就很简单，在里面设定一个什么时候这个Sever等于Y，这个架构基本可以保证服务的多重化或者节点之间的控制。但是有一个很不好做的东西时什么呢。这是一个整体的SOA架构，你要进行全部编译，这意味着你做服务动态调整要通过编译来做，这就很麻烦了。这个相对于Kubernetes的方式很不灵活。

四 专注于业务实现的微服务架构

使用了Kubernetes这种方式后，就会更加灵活，使我们的服务专注于服务的架构开发。

即使是这样，我们依然有很多的东西需要考虑，我们为什么进行微服务的设计和架构，这有很多很多的痛点。

就是说我们大型的系统一旦出来，就像多米诺骨牌一样，你拉其中的一块，就会整个轰塌。以我十几年的工程师经验，这个过程是非常痛苦的，痛苦的人都知道怎么来的。

我只改了一行代码，为什么整个程序宕了，整个应用毁了，这种情况会出现的。因为随着年久失修，这些大型的系统，它会成为巨石一样存在，谁都不敢改，改起来成本又非常大，维护的成本也非常高。

我接触过很多大型项目，跟他们一起做他们做得非常优秀，但是即使这么优秀的企业我们还是发现了很多有意思的事情。

比如说当年Alpha推出市场的时候，原本在Alpha上运行的话我们转到Hpux上，当然有一部分跑到了IBM的AIX上，但是无论你跑在哪种上面，如果有C这种通过编译型语言的话，你要进行重新编译和优化。

一个很有趣的规律就是超过百万行级的代码我们都会发现非常低级的bug，不管系统多么优秀。有一条到现在没破，我们知道像C这种父子语句和判断语句肯定会有用混的，If写成父子语句的，有专门的把两行写成一行，就是为了省一行空间的写法也有。我们明明确确的根据上下文判断就是一个进或不进，改不改。这就陷入两难，因为它有上百万的代码。

一个工程师我只负责以前在Alpha上面跑，现在在Hpux上跑，你们不是跟我说，我只是换一个机器，剩下都OK吗，为什么不OK了？所以我们不敢改，因为很多时候时错错得正，你改了这个地方其它地方还有一个错，最后结果正确的我怎么知道。

这个难点在于，还是整个的耦合度没有拆分，这种情况下如果你的功能很小的话那就很好办了。如果部署能够独立化，解耦做得很好，简化做得很好，规模又小型化，这样我们知道这块影响到哪儿，大不了我把它重新用backup运行。我知道它影响到哪个地方，只有不知道，我们才害怕，而且不知道可能真会出现各种问题。

所以这个才是我们实际与企业级客户在推的时候遇到的问题，企业级用户痛点也在这里，因为客户很多时候就问我，我改一行代码为什么要花这么长的时间，我跟他说一天为什么花这么长的时间。确实要花这么长时间，因为你系统太复杂了。我们解耦以后可以治这个病，但是整个的过程也会带来其他的问题。所以我们整个过程需要进行考虑。

我们使用Spring Cloud，可以使我们过程中更加方便。通过适当冗余，使用多个Eureka服务端，这样就能保证保证服务注册不会停止。如果我们做Tuxedo的架构话要自己写，我们使用Eureka就更加方便。

我们还要考虑负载均衡，像Ribbon这种客户端。我想大家做过SOA开发，对这种策略都不难进行，就是有所反馈。比如说我们就讲，我坏了应该怎样重启，要加权、随机要重启，这台坏掉了我看另外一台机器有几个，跑在另外一台机器上，自己写这个很痛苦的。这些如果使用了开箱即用的东西会整体地加快我们的速度。

除此以外还有很多，我再列举一个配置中心。我为什么提它呢。我们讲三架马车，最终一架是DevOps，像Spring Cloud也好，我们推DevOps时，我们推荐使用一套的部署机制，你不同的环境可以通过不同的配置来实现，我们认为Spring Cloud是它对DevOps的一种微服务发布方式，我们通过整体的具体实践进行结合使得发布更加方便和顺畅，更多地是与DevOps进行结合。

有这样的东西开箱即用，对于微服务，我们就很容易写我们的SQL语句，实现业务逻辑，就会非常简单，实际在使用的时候，尤其是容器化的过程中IP会变来变去，这些问题都会带来困难的点。但是想想你要从零开始创建这些东西，它的成本是值得的。虽然有些人说你没办法做这些东西，但是你看看传统企业痛苦的程度。

五 DevOps助力全生命周期的高可用性

我们讲DevOps能够在其中起到桥梁和纽带的作用，辅助我们三架马车，容器化的服务能够更好的落地实践。具体地有哪些点，我列出了这样一些点。

5.1 环境一致性

我们强调开发和测试环境、生产环境的一致性。因为开发环境，经常会有不同环境的开发，可能会带来很多的问题。测试环境的话，由于测试和开发环境的不同也会带来问题，比如说你测试的代码和开发的版本不一样，这些不必要的消费都会带来不必要的时间。

所以这些都是需要我们考虑的，另外我们引入安全扫描的机制。因为2015年左右我看过一个研究，对于Docker Hub上面的镜像进行分析，大概有30%-40%的镜像是不安全的。

从今年开始Docker也是在最贵的那版里面引入镜像扫描的机制，同时CoreOS也提出了Clair，所以建议大家有空回去下一个，像Clair这样的东西对你的镜像扫描一下。

2014年的Heartbleed大家印象很深刻，那个心脏流血的，那个一直在流血，心脏就会失血而死亡，你可能就要搭桥，所有的买单都是企业级的客户来做，它要为你对安全的忽视来买单，这一切有可能是我们不能承受的，因为它在心脏上。我建议大家一定要下这样的东西看一下到底有多少的CVE。

然后生产环境保持一致性，这是理想的，但至少要达到 Infrastructure as Code。这考虑到什么呢，如果你的生产环境的一个节点突然坏掉怎么办？尤其是那些年久失修的系统，客户说给你拿一个机器给我立即换上，这是很简单的事情，那有太多的手工作业，你把这些手工作业全部都变成代码放到你的SVN或Git上，一定要这样做，我们在推这样的实践过程中也碰到很多的惯性的阻力，但是我们认为这样的实践很重要。

5.2 可定制流水线

我们讲可定制的流水线是非常重要的，安全检查也非常重要。可以定制的，可以提高我们CI/CD的流水线。可以使用开源的工具，也可以使用商用的工具。根据DORA调查，你使用可定制的话可以带来更好的效果。

5.3 可视化

监控，可以使得弹性扩容更加容易。

我们的一些客户，我们平时的业务量跟波峰的业务量相比是1%甚至更多，这种情况下怎么办？

六 弹性扩容需求下的高可用性

我们讲的三架马车每块需要做什么事情，在容器化的基础之上进行解耦和优化，同时DevOps要监控、判断，同时最重要的一点，我们要强调一下DevOps我们提倡的理念是Fail Fast，我个人认为这不是为了让我们die fast，你要做好我们的Plan B，我们recover plan，如果一旦失败了怎么办，如果事前不想好那真的有可能die fast。

所以我们提倡跟客户说你要Fail Fast，要戴好安全带，这点非常重要。根据DORA的调查，2017比2016年相比，我们的速度得到了明显的提高，但是那些低绩效的企业，他们在MTTR的修复时间比去年还要恶劣，这为什么？快了但是没考虑稳。

我们使用K8S能够很容易的进行横向扩展。具体的策略，通过确定交易的指标和资源使用情况，确认什么时候进行水平扩容，取一下业务日志和系统日志进行监控和计算然后告诉K8S扩容它就扩容，就是这么简单，但是实际应用的时候有很多的项，你在这个过程要保证安全，稳定地扩容。

七 案例分享案例 1

我们通过应用的多重启动，来保证应用的可靠。Front office和back office 进行前端的业务和后端的审批，这都非常常见，大部分都执行这样的做法。

另外，我们过去传统来做，可以看到整体的集群非常复杂，你有文件集群、应用集群、认证集群、RAC集群。而且这些资源相互之间协调非常痛苦，如果你出了问题了，依然有很大程度的可用性。

但全坏掉了，我们通过什么办法。通过共享存储和网络结合起来，跟容灾备份中心结合起来，它的数据一旦过去之后，另外一套系统结合起来，可以使它能够保证数据中心级别的可用性。

应用级别可用性，节点级别的可用性以及数据中心级别的可用性，我们都能达到。同时，这种传统的问题点，客户也问过我这个问题，他说，我加一个node，你们为什么花我这么多钱。

有一次，我们跟他说应用级别的资源不够了，加一个resource吧，他的文件集群依然有resource，你告诉我应用集群不够了，你用它的不好吗。我说，作为一个工程师来说，这个很难。他说我不管为什么难，我只看到我的系统，它依然有一部分是闲的，你没有做到。它做不到并不表示其他做不到，比如K8S就可以做到。

案例 2

这是一个典型的案例，是跟我们通信领域的一个客户做的在PaaS平台上运行微服务的架构。我们也实现了多Kubernetes集群的状态下，我们的双中心的这样一个应用。双中心双活，整体的话与刚才那个例子相比是有优点的。同时我们讲我们实现了按需扩容，怎样进行按需扩容，其实就是监控，监控的过程中注意安全，我们定期对客户安全进行扫描。希望大家注重安全，不要认为官方镜像的就很可靠。

我们会根据我们业务的，比如说我们达到300单/每秒业务的要求就会扩容。你CPU连续超过一段时间都超过了75%，那好生成一个Pod。很简单，所有这一切源于需求。我们刚刚提到了517电信日，订单的业务量增加126倍；京东618订单量也相当于平时10倍，这些都是给我们传统方式带来挑战的。像刚才金融的方式，就很难解决这个问题。

我们可以看到在应用级别的可用性，以及节点级别的可用性和数据中心的可用性，我们都可以以简单的例子进行分享。其实我们与电信客户做了很多的设计，跟金融的也有很多，今天举出这两个例子，主要是让大家进行对比。很多时候，我们在进行一个转型，转型的过程中怎样进行参照和思考，这是我今天给大家带来的分享的主要内容。

原创：刘淼