从下面讲到的所有项目中：项目简易难度、可行度排序，考虑动态变更容器资源限制、多集群一体化。
联邦集群
数据同步自动化
主站体系的接入同样代表着数据的互相流通 需要有一个工具保障简单快速的流程
主体：是接入主站各种服务
副产物是：数据快速流通的流程、监控问题、快速解决问题（集群打通），即监又控
体系：确立服务迁移标准
目的：打造全球一体化服务
断路器 数据同步失败 用户无法登陆 流量转移到其他集群
推动了 PaaS 层的面向终态自动化改造
通过 智能调度与 PaaS 平台，让自动迁移应用，修复不稳定因素成为了可能
应用yaml托管
云原生应用管理工具
云原生rocketmq
节点发布回滚策略
15 点 17 开始发布，17 点 30 才收到报警，18 点 15 还未能止血，直到 19 点
才通过切流 + 回滚的方式恢复。
全场景的验证
缺乏快速止血的手段，17:30 收到报警，到 18:19 都未能止血，直到 19 点 才恢复，这样的恢复速度，实在是难以接受。
恢复的方法是什么?回滚，切流，重启，隔离，新发布?
稳定性是什么?不是完全不发生问题，而是能够将问题影响降到最小。所以， 这就要求我们，所有的线上异常，都要能自动化发现，自动化处理，才能对 客户影响减少到最小。在产品研发阶段我们不仅需要适配性能，功能，我们 也需要做到可监控，充分考虑发布的场景，在研发阶段就需要考虑清楚每一 个异常应该怎样隔离。对于做不到的产品，SRE 有权拒绝上线。
如果故障处理经验丰富的人一定知道，除了回滚， 其实还有隔离，降级等多种方案。
kata 给容器提
pouch cri
Deployment 和 StatefulSet 解决了“服务节点版本一致 性”的问题
并且通过 https://www.cncf.io/blog/2018/08/29/cncf-survey-use-of-cloud-native-technologies-in-production-has-grown-over-200-percent/ update 实现了滚动升级，提供了基本的回滚策略
1. AWS Fargate
https://github.com/cncf/wg-serverless/blob/master/whitepapers/serverless-overview/cncf_serverless_whitepaper_v1.0.pdf
在交流过程中，我们发现 Serverless 很好地解决了客户的一些诉求:包括通 过 0-1-0 的伸缩能力来提高资源时用率，降低成本;支持代码包出发，从而让客 户无感化实现云原生，历史应用无需经过容器化改造;支持灵活的触发器配置，引 导用户对应用进行事件驱动的改造，从而适应业务的高速发展等。这些优势，使得 Serverless 在小程序开发的场景下大放异彩。
采用 Serverless 架构后，应用往往进行更细粒度的拆分，并通过事件串联。因 此用户希望平台能集成大多数通用的事件源，并支持自定义事件，使得触发机制更加 灵活。
提供了 Serverless 引擎管理、应用与服务管理、版本管理 与流控、根据业务请求或事件触发较快的 0-M-N-0 自动伸缩、计量、日志及监控 等配套能力。
SAS 提供了丰富的引擎全生命周期管理、诊断、监测等能力
性能简析:横轴为完全在同一时刻触发冷启的 Java 应用个数，纵轴为冷启应 用的平均与最小耗时。随着压力增大，50 个 Java 应用同一时刻调度加冷启平 均耗时 2.5 秒左右，100 个 Java 应用同一时刻调度冷启平均耗时 3-4 秒，最 短耗时 1.5 到 2 秒。

控制理论中常见的负反馈闭环控制系统
节点故障自愈组件用于管理业务集群 的工作节点，提供节点新增、删除、升级和故障处理能力
实现如等待日志采集 DaemonSet 部署完成才可以开启调度的需求
系统会从事件中心、监控系统中获取集群业务指标(如:Pod 创建成功率)，如 果出现异常指标，则自动熔断变更。
核心组件大量使用 Operator 面向终态设计模式
APIServer 等核心组件的日志
Service Mesh/Ingress 等接入层的日志
还提供了上层的日志分析能力，默认提供了 基于 APIServer 的审计分析能力、接入层的可观测性展现、应用层的日志分析。
HPA 是 Pod 水平伸缩的组件，除了社区支持的 Resource Metrics 和 Custom Metrics，阿里云容器服务 Kubernetes 还提供了 external-metrics-adapter，支持云服务的指标作为弹性伸缩的判断条件。目前已经支持例如:Ingress 的 QPS、RT， RMS 中应用的 GC 次数、慢 SQL 次数等等多个产品不同维度的监控指标。
Cluster-Autoscaler
通过 PTS 模拟上层产生的流量
基于 Kubemark 搭建了大规模集群模拟的平台
提前通过科学的手段预判应用需要的副本数和资源量
这个是用户最能感知到的不符合预期的了，一旦 IP 冲突就回导致服务时断时 续，如果是关键服务，还可能会造成各种故障，这是挺严重的一个异常，现有 K8S 是没有针对这种情况的检查的。
我们知道，绝大部分情况，在 Pod 创建完之后，还会有元数据同步到其他服 务上，在 Pod 交付之后，还会有外围的服务进行操作(部署、导流等等)，这 些外部服务会依赖某些元数据，一旦这些元数据未及时同步完整，会导致后续 操作的失败。
除了让人心力交瘁的混乱，系统还面临着应用容器的各种崩溃问题:内存不足导 致的 OOM，CPU quota 分配太少导致的，进程被 throttle，还有带宽不足，响应时 延大幅上升 … 甚至是交易量在面对访问高峰时候由于系统不给力导致的断崖式下跌 等等。这些都使我们在大规模商用 Kubernetes 场景中积累非常多的经验。
资源不足就势必造成整个应用服务稳定性下降的问题。例如上图的场景:虽然是 同一种应用的副本，或许是由于负载均衡不够强大，或者是由于应用自身的原因，甚 至是由于机器本身是异构的，相同数值的资源，可能对于同一种应用的不同副本并具 有相等的价值和意义。在数值上他们看似分配了相同的资源，然而在实际负载工作 时，极有可能出现的现象是肥瘦不均的。
而在资源 overcommit 的场景下，应用在整个节点资源不足，或是在所在的 CPU share pool 资源不足时，也会出现严重的资源竞争关系。资源竞争是对应用稳 定性最大的威胁之一。所以我们要尽力在生产环境中清除所有的威胁。
在预防维度，我们可以进行全链路的压 力测试，并且提前通过科学的手段预判应用需要的副本数和资源量。如果没法准确预 算资源，那就只采用冗余分配资源的方式了。在兜底维度，我们可以在大规模访问流 量抵达后，对不紧要的业务做服务降级并同时对主要应用进行临时扩容。但是对于陡 然增加几分钟的突增流量，这么多组合拳的花费不菲，似乎有些不划算。或许我们可 以提出一些解决方案，达到我们的预期。

其中 api server 用于服务外界对于 policy engine 运行状态的查询和设置的请求;command center 根据实时的容器画像和物 理机本身的负载以及资源使用情况，作出 Pod 资源调整的决策。Executor 再根据 command center 的决策，对容器的资源限制进行调整。同时，executor 也把每次 调整的 revision info 持久化，以便发生故障时可以回滚。
同时在测试中探索在时 分复用的场景下动态调整 memory limit 和 swap usage 而避免 OOM 的可行性;在 未来我们将支持对容器的网络和磁盘 IO 的动态调整。
熔断异常服务
各种资源调整策略通过 Daemonset 部署，可以自动地、智能地在节点上运行，减少人工干预，降低了运维的人力成本。
我们在开源社区基础之上，优化集成了阿里云的其他服务。大家知道 Istio 社 区版本中自带的一些开源组件在生产环境中直接使用并不可靠，譬如分布式 跟踪组件 Jaeger 社区版本中并没有整合数据存储部分，Prometheus 的数 据存储等，而 ACK Istio 中通过优化整合阿里云服务，提供了更加稳定易用 的服务能力。
通过 Istio 将多集群下的应用服务实现互联互通和统一管理。
