基于DevOps、微服务以及k8s的高可用架构探索与实现

前言

本文给你们分享的题目是《基于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个安卓手机。可是这些客户不会说，他会说个人同行他们作的就这么快，这都是咱们面临的压力。

今天我也会给你们举一些案例，金融我我的接触的行业中也分为到两种，有传统的金融，他们仍是以稳为主，今天的一些案例中就是一些稳的，还有一些是快的。因此咱们的容器化并不必定都是须要快。

咱们讲三架马车，这三架马车到底怎样开，开起来稳不稳，怎样进行扩展，这过程当中咱们须要注意什么，咱们有些实践，不敢说最好的，可是能够给你们带来借鉴。

高可用性架构总体设计

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

高可用性架构目标

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

因此咱们讲总体业务的连续性和稳定性，对于咱们高可用性架构是最重要的。

咱们业界常常说几个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分钟怎么办？你的策略就不同，你是否是应该保证两个方式双方都能正常运行的时候你再起另一个。因此总体策略不一样，成本也会不一样。

高可用策略和手段

总体的策略和手段有不少。咱们提升可用最重要的一点是冗余。

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

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

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

虽然是一主一从，可是二者相互结合仍是能保证他的服务正常运行。可是除此以外，还有不少的因素。成本是无处不在。并且咱们的客户也会知道，容灾备份中心作成两活实际上是更好，可是成本会发生更大的变化。

另外咱们平时的训练，由于这跟技术无关，可是又很是的重要，由于我看过不少的系统，他们作得都很好，可是为何他不敢切。

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

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

除此以外，还有横向的扩容，咱们的波峰来了，咱们何时才能进行扩容，因此这个时候咱们须要考虑。咱们讲跟DevOps进行结合，咱们监控作到咱们可以肯定何时进行横向扩容。

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

要素和原则

咱们叫容器化、微服务和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可以在其中起到桥梁和纽带的做用，辅助咱们三架马车，容器化的服务可以更好的落地实践。具体地有哪些点，我列出了这样一些点。

环境一致性

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

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

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

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

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

可定制流水线

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

可视化

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

咱们的一些客户，咱们平时的业务量跟波峰的业务量相比是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倍，这些都是给咱们传统方式带来挑战的。像刚才金融的方式，就很难解决这个问题。

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

转载网址：https://mp.weixin.qq.com/s/7L...