享道出行是一家专注于出行服务的专业品牌，是上汽集团实现汽车产业“新四化”（即“电动化、智能网联化、共享化、国际化”）的重要组成部分。
作为上汽集团移动出行战略品牌，享道出行充分利用全产业链竞争优势，从消费者对安全及品质的需求出发，通过为消费者提供安全、高效、舒适、便捷的品质体验，打造品质出行服务平台。
在快速的业务发展过程中，基础设施规模的不断增长，为企业管理者带来了对于效率和成本的高度关注。容器技术作为云计算时代基础设施的核心，自然成为了我们关注的焦点。随着容器技术及其生态的不断成熟，对于企业级开发者来说，在提高部署速度、优化资源利用率以及降低环境间差异等方面展现出了巨大的潜力。然而，随着容器数量的激增，如何管理和调度这些容器也成为了一个挑战。
当前业务开发主要采用 Java 技术栈，应用部署架构如图所示：
针对以上痛点，为解决弹性滞后的问题同时兼顾成本最优，方案如下：
作为出行行业，享道的业务特征具备明显的潮汐效应，通过弹性架构改造，我们能够充分发挥云弹性算力的优势，进一步提升了业务自身的容错性。
针对传统弹性能力所存在的问题，在方案设计阶段我们采用了 阿里云ACK 容器服务推出的 AHPA（Advanced Horizontal Pod Autoscaler）弹性预测，可以根据历史 Pod 的 Ready Time 以及历史 Metrics 自动学习规律，在业务量上涨之前的一个 Ready Time 开始扩容，在业务量上涨时 Pod 已提前准备，可以及时供给资源，解决弹性滞后的问题。
AHPA 弹性预测根据历史数据自动规划未来 24 小时每一分钟的应用实例数，相当于进行 1440 个点（一天为 1440 分钟）的 CronHPA 定时配置。
预先扩容
由于业务具有很强的潮汐属性，每日的涨潮落潮时间比较固定，AHPA 会根据过往的数据推测之后的所需要的 Pod 数量。例如，服务A根据以往双休日情况预测出这个双休日可能出现的 Pod 数量最大值为 16，那么就可以预先扩出来满足这些额外 pod。
如前文所述，AHPA 只能够解决应用层的弹性滞后问题，并不能提前对底层资源是否足够提前做出判断。这也意味着当底层资源不足时，仍存在使应用扩容时间被无限拉长的风险。
弹性容器实例 ECI（Elastic Container Instance）
作为一种纯 Serverless 容器运行服务，对于用户而言，无需管理底层服务器资源，同样也不需要关心运行过程中的容量规划，只需要提供打包好的 Docker 镜像，即可运行容器，非常适合应对这种流量突发
场景下的
业务场景。
但从成本性上讲，单位价格会相对裸金属 ECS 较贵，该方案结合了各付费模式和底层架构的优势，当前采取混合部署模式，兼顾成本及稳定性两方面的业务目标。如下图所示，未来目标是一半以上的应用作为业务基线部署在裸金属 ECS 上，对于周期型应用部署在按量付费的 ECS 资源，结合出行行业早晚高峰，剩余 10% 以上的场景均通过 ECI 实例保障。
注：
ECI 的计算资源与 ECS 等实例完全解耦，在每个可用区有单独的资源划分给到 Serverless 架构相关产品，对于大部分场景（CPU 数不超过 1 万 Core），无需担心资源不足的情况产生。因此 ECI 也是一种相对可靠的算力容量保障手段。
在资源的调度策略上，由于采用了 ECS 及 ECI 两种部署模式，我们期望应用扩容和缩容行为都是确定性的，当应用需要部署一个 Deployment，此时集群中有对应的多种类型的资源，分别是包年包月的 ECS、按量付费的 ECS 和弹性实例 ECI。
那么，
部署的服务优先调度顺序理论上依次为：包年包月的 ECS、按量付费的 ECS、弹性实例 ECI。
同时在服务缩容时优先删除 ECI 上的 Pod，释放 ECI 的节点资源，然后删除按量付费的 ECS 上的 Pod，最后删除包年包月的 ECS 上的 Pod。
对于包年包月及按量付费两种不同付费类型的节点需通过打上不同 label 标签实现。然后创建 ResourcePolicy 自定义节点池调度顺序。
apiVersion: scheduling.alibabacloud.com/v1alpha1 kind: ResourcePolicy metadata: name: DEMO namespace: demo-ns spec: units: - max: 15 nodeSelector: env: prd resource: ecs - max: 5 nodeSelector: foo: bar resource: ecs - resource: eci whenExceedMax: NeverEvict
这里具体的调度策略可根据实际业务场景区分，若对于成本不敏感，且业务的波峰波谷抖动较大的场景，也可以考虑当 ECS 资源不足时，使用 ECI 弹性资源，进而加速 Pod 的启动时间。
在享道的集群架构中，存在采集微服务日志的场景，日志采集器会在 ECS 节点上通过 DaemonSet 方式部署 Agent，但虚拟节点不是真实节点，不支持运行 DaemonSet Pod，如何让调度到虚拟节点的 Pod 也支持上述 Agent 的同等能力呢？答案是向虚拟节点 Pod 注入 Sidecar 容器。
