容器技术的优点使这项技术被广泛关注，已经有越来越多的企业开始或者已经采用容器技术来构建自己的云基础设施，或者和已有的云平台集成而提升整个云环境的能力。企业在实施容器平台时，几乎都需要对原生的容器技术、容器集群管理系统进行改造设计，满足自身特定的业务需求或限定条件。通过本期容器云方案设计的交流探讨，希望可以解决：如何更方便地和已有系统整合以发挥整个云系统的能力、如何让容器技术更适合自身当前的应用成熟度和未来的发展、容器技术的应用如何更适合自身业务规模的高可用性设计以获得性能和成本的最佳平衡等等。同时为了更充分地发挥容器平台的能力，在设计新的应用微服务架构、或如何改造现有的应用时，应该考虑哪些因素等。

和互联网企业相比，银行业在容器化方面起步稍晚，但近两年关注度空前提高，并且进步很快。有不少银行已经在生产环境使用容器技术支撑微服务化应用，获取快速、灵活、弹性、经济的优势，更多的银行也已经在积极地进行相关能力的建设。

这次的交流内容主要围绕方案设计进行，帮助大家在做容器云建设时提供一种参考。接下来会通过以下交流内容进行逐一说明：

1、容器云技术产品如何选型？

这个问题有很多复杂的影响因素，包括技术和非技术的。不同的组织情况不尽相同。

如果仅从技术角度、工作复杂程度来说，我们的经验是：

• 考虑自身的技术能力，包括开发能力、运维能力。例如PCF等要求银行对应用代码开发的掌控能力强，如果在可接受的成本下，银行对自身业务系统从开发平台、开发过程、开发规范等有决定能力，则采用PCF等方案是可以考虑的不错选择；如果希望采用成熟的平台降低运维中的复杂度，当然成熟的PCF相对要好。
• 考虑现有系统对接需求，包括监控、网络、安全需求等。例如现有网络架构对容器的网络方案有较大影响时，应该考虑开源方案更便于定制，PCF的方案因集成度高、相对封闭，不太适合大规模定制。

另外，如果用开源方案，那么生态丰富和社区活跃程度也是重要考虑因素，这样我们才可以借助社区和生态的力量来完善功能和解决问题。

总的来说：

商用方案有：PCF、OpenShift，优点是成熟，集成度高、功能全；缺点是不够灵活、定制空间相对小。

纯开源方案：Kubernetes、Swarm、Mesos、Rancher等；优点是灵活；缺点是需要考虑众多走边对接的开源方案。

2、所有应用运行在容器云上，那么日志管理应该如何设计？

容器常被用来运行需要快速故障迁移、弹性伸缩的应用或微服务，因此容器中运行的应用，在运行的过程中随着迁移、弹性伸缩的发生，应用日志很可能会在不同的运行节点中产生，对应用通过日志进行监控、问题排查带来了很大的麻烦，所以和大多数传统应用把日志写在本地文件系统不同的是，容器应用需要考虑把日志进行集中收集，写入外部的集中日志管理系统中，比如上面bryan提到的ELK方案，或者采用Flume进行采集，进一步通过Kafka等消息队列把日志信息实时传递到外部的日志收集、日志分析系统；或者最简单的方式就是让容器在运行时挂载外部共享存储卷当做应用的日志目录，这样应用的日志会被实时写入外部共享存储以备后续处理，这种方式对外部工具依赖少，但需要我们做好控制，不同的容器不能挂载同一个外部卷，否则就会出现写日志冲突的问题，容器迁移的时候还需要重新挂卷。

除了日志的集中收集这一系统层面需要做的工作，在应用改造上我们还应该重视容器应用的日志标准化问题。通过标准化应用写日志的格式和内容，我们可以通过应用日志进行交易率、成功率、响应时间等关键业务指标的分析，用作问题预警、容量扩缩的依据。越来越多的容器应用正在采用这一做法，原因一是因为某些传统的APM工具因容器快速迁移、实例数量、IP地址都在不断变化的特点而失去监控能力，其二是避免传统埋设探针方式带来的性能下降太多、监控指标变化不灵活的特点。

此外，越来越多的用户采用容器来运行微服务架构应用，一个业务调用往往需要经过多个微服务的调用链，整个业务处理过程的日志记录分散在不同的微服务日志中，这对通过日志进行问题诊断带来了不小的困难。通过标准化日志，例如带上唯一的ID信息等，我们做到把同一个业务在不同微服务中的处理过程给关联起来。针对这一点，微服务框架在一定程度上已经帮我们做到了，例如Spring Cloud Sleuth，如果只是微服务服务链路的追踪，使用这样的框架工具可以很好地帮到我们，它其实就是在应用写日志的时候，添加上标准化的字段内容实现的。

3、在银行业内部已有监控系统的前提下，如何进行容器云及其容器上面应用的监控的方案设计？

嘉宾观点一：

IAAS层：

1.容器云首先是搭载在IAAS层上的，传统监控仍然可以用于IAAS层监控（CPU、内存、网络等），只是针对容器特性这块，IAAS层监控需要增加额外的监控KPI，如专供docker image使用的文件系统的使用率，docker service状态，开源网络组件服务状态，K8S node service状态等等。

PAAS层：

1.首先是PAAS框架自身的状态，如K8S自身就有大量的命令可以列举集群状态，集群事件等等，这部分监控可以通过额外定制监控agent完成。

2.PAAS内部应用的状态，比如镜像是否宕机重启过，服务是否可用等，如果使用的k8s，需要结合k8s命令以及框架提供的应用健康侦测功能实现监控。

3.对于单个容器所使用的资源监控，其实很多框架都提供了非常完善的开源解决方案，选择合适的实施就可以。

4.针对应用监控，个人感觉其实应用上云后，单个容器应用监控其实意义不大，系统要做的是能够正确发现异常并恢复异常，比如框架尽早发现应用hang或者应用压力比较大，然后由框架决定是重启容器还是自动扩容。这部分如果使用K8S，框架层面本身就有这个功能，上线的时候做好规范规划就行。

如果一定要深入容器监控应用，监控总体思路是一样的，不是主动推数据，就是工具拉数据，由于容器数量及IP会经常变更，所以一般情况下采用主动推送的方式，容器启动后就自主收集数据并推送至监控平台。至于如何监控应用其实和传统方式没有差别，大体就是监控中间件提供的性能数据，再通过APM监控应用的性能数据。如果是采用的K8S，可以考虑将监控单独做成一个docker镜像，发布是同应用发布在同一个pod中，而不是将监控写入应用镜像。

嘉宾观点二：

这个问题说以银行内部已有监控系统为前提，那么我认为问题的场景是需要容器平台和已有监控系统进行对接。在这个前提下，我个人的想法是：

首先监控是分层的，可以分为系统层面、应用层面、服务层面。

• 对于系统层面，主要是针对资源使用情况、网络连通性、节点健康情况的监控，传统的监控系统在这方面已经非常完备，我们直接可以利用传统的监控系统对容器平台的宿主机进行系统层面的监控，对接大屏幕等。至于单个容器本身使用的资源等，我个人觉得这些数据对进行弹性伸缩、迁移等容器平台内部动作是比较关心的，而对于外部资源监控意义不大，所以我个人认为多数场景下单个容器的资源使用情况、健康状况这样的信息没有多大必要送到外部的传统监控。系统层面的监控还有一层意思是容器平台本身的监控，即控制节点和相关服务的监控，这些在容器管理系统是必备的功能，用户可以根据需要决定是否需要把这部分信息上报到传统监控进行统一展示。
• 对于应用层面，容器平台本身通常都带有类似K8S的replication control这样的机制保持某个服务运行实例数量的能力，所以通常情况下容器平台都能保证应用和应用下每个微服务的运行正常。但我个人认为关于应用层面的健康监控，还是需要来对接传统的监控系统，进行适当的告警输出，例如当遇到应用逻辑错误而导致启动反复失败、或资源不足导致启动总是不成功等问题时，容器平台本身的replication control机制就不能解决问题了。这种情况就需要我们把应用的故障信息传递到传统监控，并根据问题的严重情况进行不同等级的告警通知等，由相关的应用人员介入来解决问题，比如升级补丁或回退等。那么怎样和传统监控的对接？方法就因用户的喜好而异了，例如可以写一个独立运行的程序，定时调用容器平台的接口，获得应用中每个微服务的当前实例数、预期实例数、应用的资源使用总量等，调用相应接口把数据传递到传统监控，在传统监控中设立告警策略，例如当运行实例数低于预期实例数持续2分钟后，抛出告警等。
• 对于服务层面，是监控应用提供的服务是否运行正常。例如某个提供WEB服务的应用，在一些时候虽然应用和应用中微服务的运行实例数量正常，但它的WEB服务已经失去响应，或者返回的是错误的状态，这种情况在多数容器平台中是无法监测到的，这个需要我们丰富容器故障的监测手段，或者自己编写服务访问+检测逻辑来判断，并把检测出现的问题上报到传统监控，在传统监控中设立相应的告警策略、告警等级。

嘉宾观点三：

个人认为分几个层面。

• 第一个是系统层面，包括主机系统监控，这个已有监控系统可以搞定；
• 第二个是容器层面，容器启停都是秒级，有些动态变化也比较快，现有监控不一定能搞定，需要使用新的开源框架或者对现有监控系统改造；
• 第三个是应用层面，应用的状态，传统是通过打探针agent方式，但在容器环境下，这种方式不一定可行，我认为可以根据具体的应用使用场景，采用不同的监控方式，比如健康检查、agent、主动上报等多种方式。

4、在容器云平台建设方案设计上服务编排应该如何设计?

流行的各种容器集群管理系统都支持服务编排，用yml格式的文件进行描述，但Swarm、K8S、Rancher Cattle等各自的服务编排语法并不统一。如果直接使用这些系统的编排语法，当未来重新选择容器管理系统的类型时，已经积累的应用编排就都会成为限制，或者需要根据新的容器管理系统进行重新编排，这非常不利于复用已有的IT资产，也是不愿意看到的技术上的锁定。

所以建议设计自己的编排语法，同时开发一个翻译模块，把自己的编排信息翻译成容器平台能够处理的编排语法。当未来更换底层容器管理平台时，上层积累的应用编排资产不会受到影响，只需要开发新的翻译模块对接新的容器管理平台即可。

5、容器上的应用可以分为有状态和无状态两种类型的应用，对于有状态的应用需要使用存储。那么底层存储应该如何选择？选择的策略依据是什么？

嘉宾观点一：

个人经验：

容器云存储目前针对私有云的可用选择其实不多，主要是nfs，nas，glusterfs，ceph等等。

这类存储各有特点，适用于不同的场景。
所以使用哪类存储其实取决于你的应用是哪种类型的存储需求。
如果是纯日志类输出，可以选择nas、gfs类的存储。
如果是类似数据库类、缓存类的存储需求，需要vSan、ceph类的块存储。

当然了，如果系统对于存储读取效率速度等要求特别高，比方oracle什么的，我个人建议还是别上容器云了，可以想想别的PAAS方案，容器云能提供的存储性能目前看远远不能满足需求。

嘉宾观点二：

既然是有状态的应用，因为容器灵活迁移的特点，建议容器应用最好是把状态数据写到外部的存储中，可以是共享存储，缓存，数据库等，这样避免容器发生位置迁移后导致状态数据不可访问。

具体到存储技术的选择，应该根据应用的场景来决定。如果访问效率要求不高，例如一般的日志数据，可以考虑使用分布式存储方案CEPH+NFS或NAS；如果对数据的访问效率要求较高，例如应用的业务数据，或者数据量较大而读写延迟可能较大的场景，用SAN比较适合；如果是要考虑灾备如同城双中心间的数据复制，那么可能NAS或者SAN更合适（CEPH目前还难以跨中心进行复制同步）。

实际情况下，都是根据不同需求对各种因素的权衡，没有绝对的应该用什么或者不应该用什么，因此以上的建议仅供参考。

6、银行业容器云平台建设方案设计需要遵循哪些原则？为什么？

嘉宾观点一：

• 首先我们要明确上容器云的目的，容器云是为业务服务的，都是为了能够更好的服务业务，这是我们的出发点；
• 其次结合业务特点选择合适的容器框架，我们的业务是不是基于新型微服务架构，业务特色是不是具有变化快、业务弹性大、更新迭代快等特点，容器云平台能够帮我们解决以上痛点；
• 最后，我们业务哪些要上容器云，无状态的，易扩展的等等。

总之，容器云平台建设从业务需求、平台框架选型、架构设计、运维维护等等多个方案都可以展开来说。

嘉宾观点二：

除了具体的技术，我个人的建议是：

• 第一，要和已有系统较好地对接整合。银行在建设容器云平台之前，通常都已经有比较成熟和稳定的其他IT能力，例如网络系统、集中监控系统、安全防护系统等，因此在建设容器云时，为了充分发挥整个系统能力，避免重复建设，同时也为了容器平台能够更容易被接受和使用，容器平台应仔细地设计和已有这些系统的对接，让容器平台融入银行整个IT系统，而不是另起炉灶重新建设，这样不仅工作量大、难度大、成本高，现有应用和运维人员也不容易接受；
• 第二，既然是银行，如果容器平台要作为生产环境，就需要符合安全的监管合规，例如隔离不同安全等级的应用、支持对应用容器的安全漏洞扫描、有效的防火墙策略管理等，容器平台应该有能力实现以上这些安全监管的要求。市场上多数的容器平台还不能支持这些能力，所以银行在建设容器平台时，都应该在所选的技术产品上做相应的改造，加入功能，或集成外部的能力；
• 第三，如果是生产环境，还要符合银行业务所需的高可用性、连续性的要求。除了容器平台本身支持像K8S的replication control等容器故障检测和自动恢复，还应该考虑在整个应用层面的高可用性、数据连续性。因此，双中心建设容器平台，双活部署应用；数据的双中心同步等，这些传统的同城双活、两地三中心的方案，容器平台可以尽量融入其中，借助已有的能力，以比较经济有效的方式实现高可用和连续性；
• 第四，容器平台的建设应该同时有新应用开发、或旧应用改造的配合。建设容器平台的目的是为应用带来灵活、弹性、节省资源等优势，这要求应用最好具备微服务架构、无状态化等特点，让这些优势更好地发挥。否则容器平台建设后，如果不能给应用和业务带来可见的价值，不仅浪费了大量投入，还使得容器平台的价值得不到认可，后续的改进和升级就难得到上层的支持了，这是每一个投入大量精力和热情进行容器平台建设的人最不愿意看到的。

7、容器云中大量容器之间在相同应用之间要互相联通，在不同应用之间则需要互相隔离，网络应该如何设计？

嘉宾观点一：

个人认为：
容器云网络其实不同于传统网络。

传统运维环境中，应用对应IP是固定的，且应用开发人员自己掌控自己的服务器，能登录能操作。
应用上云后，应用开发只会面对云管平台，根本没有机器IP，用户，密码什么的都没有。且容器云一般都是通过SDN自我组网，内部ip都是自我分配调整的，外部根本无法使用，这种情况下，如果要将应用网络隔离其实意义不大。

如果一定要做，从技术上是可以的，可以在负责内部网络的SDN上面想办法。

有一类情况可能需要考虑：比如某类应用需要访问外网，某类应用只在内网区，这个其实就是传统网络分区，我的建议是：在不同的网络分区中分别建容器云集群，不要公用一个集群。

嘉宾观点二：

这个问题应该有多种解决方案，基本上就是把不同的应用容器放置在不同的vlan/vxlan中，通过让不同的vlan/vxlan不能互访而实现隔离。简单的方案可以尝试用docker overlay来解决，首先创建不同的network，然后在启动不同应用的容器时，使用--net参数指定容器所在的对应的vxlan即可。结果会看到同一个network中的容器是互通的，不同的network中的容器是不通的。

8、容器发布如何对接银行现有的变更事件流程？

银行因为较为稳健严谨的做事风格，IT变更事件的流程一般都要有较为长的审批流程，便于权责明晰、事后追踪。但容器上了之后，相比较而言更为简单便利，对现有ITIL变更流程的影响会有哪些？或者说如何在现有的变更事件流程中更加的游刃有余，既满足合规流程，又满足其方便简单的上线特性。

嘉宾观点：

这点各家银行都在探索方法，目前都还没有很好很彻底的解决方法。银行严格控制风险的特点，多年建设的流程体系、特别是决策人员多是在传统的方式下工作多年，思想观念在短时间内还很难变化，所以在银行实现随时发布还需要逐步推进。我个人觉得可以先从完善操作审计日志以提高事后追踪和责任判定、完善应用金丝雀发布、蓝绿发布、版本滚动升级、快速回滚等能力减少风险，提高故障快速响应恢复能力等方面进行努力。当能力完备后，再从等级较低的应用放开做试点，稳定后逐步放开范围，只有这样才可能逐渐转变银行的现有发布变更流程。

9、容器云管理平台如何设计，如何实现容器云平台的devops？

嘉宾观点一：

说一下个人浅见

1）容器云管理平台的作用主要就是实现容器云管理的自动化，其中包括镜像管理、应用实例管理、应用监控等多个方面，一般是通过底层API调用去做一些应用部署、管理等多种操作，开发人员和运维人员通过管理平台即可实现应用全生命周期的相关管理和管理功能管理，对于底层和IaaS的结合，很多产品的管理也放在了里面，当然这个视企业情况而定；

2) 容器云平台包括容器技术和编排引擎两个核心技术，还有一些诸如网络、存储等重要功能的选择，如果选定了容器技术还有编排引擎，基本很多大的框架就确定了基本方向。

3）devops的落地实现需要很多工具保证，它是一种管理或者研发理念，并不是和容器绑定。devops涉及到项目整个生命周期的管理，容器云又恰好以应用为中心提供多种功能支持，因此二者很容易被一起提及。题主问题就变成了如何实现devops，首先想好devops的落地实现方式，然后再从容器中需要相关功能支持。

嘉宾观点二：

容器云管平台基本就是在容器集群管理软件上，根据企业自身的需要进行定制扩充，需要考虑资源的管理、容器网络方案、应用的建模/编排/部署/安全隔离/高可用管理、多租户隔离、统一身份认证、监控日志等，这些不仅要求容器云管和底层容器集群软件的接口对接，还需要充分照顾好企业内已有其他IT系统的整合，例如是否需要对接集中监控、网络方案怎样选择以支持容器和已有系统的三层互通、怎样和周边系统实现统一认证和单点登录、租户怎样统一管理等。

问题中说如何实现容器云平台的DevOps，这个问题不太好回答。DevOps是解决软件开发测试和运维脱节的方法论，和是否使用容器并没有直接关系。我猜问题时想问如何通过践行DevOps，让软件能够在采用容器技术后，让开发测试运维一体化更有效？如果问题是这样，那么我的建议是，首先你的组织要能做到DevOps，其次才是用容器来提高DevOps的效率。要做到DevOps，需要对现有的应用开发进行标准化、在标准化的基础上通过构建流水线实现CI/CD，对于银行来说CD还可能需要改变现有的生产环境发布和变更流程；更重要的是团队组织分工要有变化，一个团队要负责应用的全生命周期，这个需要政策的支持；再有一条是要推进应用向更高云成熟度演化，发展微服务架构，这样便于更频繁地交付新的能力，DevOps更能体现优势。有了DevOps的方法和文化，我们把容器用于其中，提高构建版本的效率、跨环境交付成功率、一键部署，快速版本升级回滚、故障自动恢复运维效率等。所以容器是让DevOps能做得更有效率，但关键的还是DevOps，用了容器技术并不等同于你的企业就实现了DevOps。

10、整个容器云平台的资源，在真正交付生产时需要有一个门户网站来管理，从而简化各种管理操作，那么租户和资源如何在门户中进行体现呢?

嘉宾观点一：

个人经验：

1.租户的问题
容器云大部分底层核心技术，包括网络，控制节点等等，应该是由运维部门负责。和应用发布有关的内容，比如编排模板、镜像、应用发布更新等操作由开发人员负责。云管平台首先要将这两部分功能分开。
针对应用组成员，云管还需要在应用层面进行隔离，比如个人发布的应用只允许原作者或者同组人修改，这个要根据实际行内应用的组织架构来安排。同理，针对应用镜像、编排文件等等也要进行隔离。
另外还有什么审计呀，权限呀，都可以在云管平台上配置。看实际各行的内部要求而定。

2.资源分配
这部分功能，我建议统一由运维团队或者系统团队负责，应用系统上云前一般会进行压测，有个容量估算的过程。通过容量估算和趋势分析，系统人员可以规划大致的资源池给相关应用。

具体的话，一般可以通过划分底层资源池实现。如果用K8S，可以在计算节点上通过lables进行规划，另外还需要在编排文件上设置好最小资源和最大资源，让应用可以弹性扩容。云管平台需要将上述相关功能集成进来并做好权限管理。

嘉宾观点二：

首先多租户之间的资源、应用、服务实例等需要隔离，不同的租户在登进门户后，只能看到所属租户内的对象，不同租户间的对象在一般情况下隔离、不可见、不可访问；其次，平台服务商（Service Provider）本质上也是一个特殊的租户，它也有自己用于平台运维管理所需的资源、服务等，我们也需要把平台服务商这个租户和用户租户进行隔离，至少在没有用户租户授权的情况下，也不应该看到和访问用户租户内的对象。在同一租户内，根据业务的需要，可以进一步设计分级的权限、角色等，一个租户内拥有不同角色的用户，对资源可以有不同的操作权限，例如高级用户可以对资源、应用等有创建/删除/修改/读取权限，一般用户只可以修改/读取权限，用于审计的用户账户只有读取权限，租户管理员做为一个租户下的最高权限，还可以对其它用户的权限进行修改等。

11、开发测试环境下容器集群的交付策略？

在传统的开发测试过程中，基于不同的应用、不同的测试阶段以及不同的版本，会搭建多套环境，比如开发环境、功能测试环境、非功能测试、用户测试测环境等。在容器化实施过程中，应该采用什么样的环境交付策略？

一种策略是部署一套跨环境的容器管理平台，通过命名空间或者租户等对不同的应用和不同测试阶段的测试资源进行隔离。

另外一种策略是在每个不同的环境都部署一套容器管理集群。

对于第一种策略，增加了资源的复用度，但是不同隔离区的开发测试对象是否会是否影响。第二种策略要同时管理多套环境，增加了管理的复杂度，没有体现出容器交付的优点。

嘉宾观点一：

1、开发测试可以统一管理，即跨环境，用同一容器管理平台，部署多套环境没有必要，一套就可以管理开发测试，至于您说的开发测试对象是否受影响，如果容器平台租户隔离做的可以的其实不影响的。而且搭建一套环境的话，对开发、测试、运维之间的流转都是非常方便的。

2、针对生产环境，与开发、测试环境都是隔离的，生产环境可以搭建一套独立的管理平台。

嘉宾观点二：

建议开发测试环境下使用同一套容器集群管理不同测试阶段，通过问题中说的多租户等方式对不同的应用和不同测试阶段的测试资源进行隔离，主要是因为管理方便，个人觉得没有大的必要去搭建多套容器集群，实际使用时只需要生产和测试隔开，各自独立建设容器集群即可。

至于资源复用度问题，个人意见认为只要是对不同测试阶段的测试资源进行了隔离，宿主机资源也是只分给某一个租户或者测试环境的某个阶段使用的，所以无论是搭建多套容器环境，还是一套容器环境用多租户进行资源隔离，在资源复用方面是一样的。如果这一点上很在意，可以考虑在物理机上运行虚拟机，在虚拟机中再运行容器，通过让不同租户的虚拟宿主机复用同一台物理机，来实现不同租户、不同测试阶段的容器混跑在一台物理机上，间接来提高资源复用度，对于开发测试环境一般还是可以接受的。

嘉宾观点三：

首先生产环境和开发测试环境应该是独立的集群，一方面，金融企业生产系统的访问有严格的限制；另一方面对于平台自身的变更，可以在开发测试环境进行测试，保证生产环境的稳定性。利用容器的特点，通过内部镜像仓库，在不同环境发布，方便进行版本控制。

开发测试环境建议一套环境。

12、容器技术的应用如何更适合企业自身业务规模的高可用性设计以获得性能和成本的最佳平衡？

嘉宾观点一：

容器云需要考虑平台自身的高可用，实现多可用区多数据中心部署。

容器上的应用高可用需要结合应用架构实现。目前微服务架构是最适合云基础设施的应用架构之一。微服务应用通过服务注册发现，全局配置管理，熔断，服务追踪等容错设计，保证应用的高可用。成本上，细粒度的应用工，弹性伸缩都有利于提高资源使用率，降低成本。

嘉宾观点二：

对高可用等级不高的应用来说，为了节省成本，可以考虑仅在一个数据中心内部，通过以下措施提高可用性：

• N+2实例运行，保证即使在滚动升级时也至少有N+1的实例在运行
• 故障恢复和保证微服务运行实例数
• 服务限流，我们需要对超出服务处理能力上限的服务请求进行限流，对超出服务能力的请求要拒绝，避免引起服务的宕机
• 服务降级，指在极端情况下，服务虽然还没有达到SLA的规定级别，但却已经出现了资源使用率过高、响应超时等不健康的情况，对此我们可以在服务网关处提前启动限流，拒绝新的服务请求、或只放行少量比例的服务请求
• 弹性扩容，增加微服务运行的实例数量，配合负载均衡策略的使用，我们通过新增加的实例来分流已有实例上的处理压力，减少因压力过大而导致运行实例宕机的情况
• 负载均衡，让多个实例均匀承担负载，避免某些实例因负载过大导致宕机
• 对高可用等级较高的应用来说，除了按以上方法在一个中心内部实现高可用外，为了确保SLA，还可能依赖多中心、多AZ的架构，例如同城双活，两地三中心部署等，这里就要考虑灾备切换方案、数据同步方案等。