在云计算与容器技术高速发展的今天,企业 IT 系统的流量特征正呈现出鲜明的潮汐规律------业务高峰时资源紧张、低峰时大量闲置,静态的资源配置难以匹配动态的业务需求。碧桂园服务也面临着同样的挑战:物业收费、办公协同、多元业务等系统在不同时段呈现出显著的峰谷差异。
借鉴行业云原生弹性架构的最佳实践,碧桂园服务结合企业多业态、多系统的实际情况,以部分业务系统为试点,探索基于云原生技术的弹性伸缩能力建设------通过混合计算资源池消除固定架构边界,借助智能伸缩策略实现按需弹性,结合无损上下线与全链路灰度发布保障变更零感知,推动资源管理从"静态固守"迈向"动态智变"。
本文将以碧桂园服务的试点实践为基础,详细解析这套可复制、可落地的云原生伸缩架构方案,分享如何通过技术革新实现资源利用率提升 40%+、算力成本节省 70% 的实战经验。
[圆角星星] 业务场景与挑战 [圆角星星]
碧桂园服务面临三大类潮汐场景:
-
收费系统:
- 流量特征:月末至月初为固定缴费高峰,该时段流量集中且量级显著高于日常水平。
-
办公系统:
- 潮汐规律:工作日早高峰、每周一、每月初及节假日前集中审批与协作,夜间及假期访问量骤降。
-
多元业务系统:
- 典型场景:零售促销、节假日充电桩使用激增等,资源需求峰谷差异显著。
核心痛点:
火箭
成本困境:静态资源配置导致低峰期资源闲置,冗余成本高。
火
效率困境:缺乏弹性伸缩能力,资源调整滞后业务变化。
灯泡
架构困境:底层节点与上层应用联动不足,弹性效果受限。
旗子
决策困境:依赖经验配置,缺乏数据驱动的精准预测模型。
[圆角星星] 解决方案 [圆角星星]
基于 Knative+ACK 混合云架构 ,构建三层弹性体系(资源层-弹性层-治理层),实现HPA+CA组合,达到降本、增效、稳业务目标。
一、资源层:混合计算资源池,消除单一固定架构瓶颈
当前基于静态资源配置的固定架构存在刚性约束:为应对业务峰值必须过度预留资源,导致低峰期资源利用率骤降,形成"预留-闲置"的恶性循环。这种僵化的供给模式与动态负载严重失配,不仅抑制了基础设施的弹性能力,更持续推高运维成本。亟需通过架构革新,破解资源利用率与成本控制的核心矛盾。
技术方案:
-
分层部署架构:
-
ECS 节点池:承载有状态服务(如数据库、核心业务),保障稳定性,包月计费。
-
ACS 节点池:支持无状态服务及突发流量,通过 Virtual Kubelet 实现 Serverless 容器化运行,按量计费。
-
-
算力质量分级管理:
-
Default 型:适用于微服务、Web 应用,保障基础性能(无强制驱逐)。
-
BestEffort 型:用于非核心任务(如批处理),利用低价保留实例降低成本。
-
-
智能调度策略:
- 核心业务运行于 ECS,突发流量自动扩容至 ACS,实现底层资源与应用的协同伸缩。

二、弹性层:智能按需弹性体系,解决成本与决策难题
核心策略:
-
常规业务自动弹性:
-
策略:Knative KPA 基于实时并发数动态调整 Pod 数量。
-
配置示例:
yamlapiVersion: serving.knative.dev/v1 kind: Service metadata: name: project spec: template: metadata: annotations: autoscaling.knative.dev/maxScale: "3" # 最大实例数 autoscaling.knative.dev/minScale: "0" # 最小实例数(可缩容到零) autoscaling.knative.dev/metric: "concurrency" # 伸缩基于并发数指标 knative.aliyun.com/reserve-instance: enable # 启用保留实例 knative.aliyun.com/reserve-instance-acs-compute-class: general-purpose # 保留实例计算类型 knative.aliyun.com/reserve-instance-acs-compute-qos: best-effort # 保留实例算力质量 knative.aliyun.com/reserve-instance-type: acs # 保留实例使用ACS POD labels: knative.aliyun.com/instance-use-resource-policy: enable # 使用自定义调度策略 spec: containers: - name: main image: "registry.example.com/project:v1.0.0" -
-
周期性业务定时弹性:
-
策略:月末月初、年底缴费高峰等周期性固定流量,通过 Knative+AHPA 预设定时策略。
-
配置示例:
yamlapiVersion: autoscaling.alibabacloud.com/v1beta1 kind: AdvancedHorizontalPodAutoscalerTemplate metadata: name: billing-service-elastic spec: metrics: - type: Resource resource: name: rps target: type: Utilization averageUtilization: 100 # 目前阈值,100表示RPS使用目标阈值是100。 maxReplicas: 50 # 定义了Pod最大副本数为50。 minReplicas: 0 # 定义了Pod最小副本数为0。 prediction: quantile: 95 # 表示预测使用95%的置信度进行预测。 scaleUpForward: 180 # 表示向前预测的时间范围为180秒。 # 在2023-06-01 00:00:00~2123-06-01 00:00:00这个时间范围内,Pod副本数的数量将受到AHPAT中定义的最大和最小副本数的限制。 instanceBounds: - startTime: "2023-06-01 00:00:00" endTime: "2123-06-01 00:00:00" bounds: # 每月1-5日,最小副本数为20,最大副本数为50。 - cron: "0 0 1-5 * *" maxReplicas: 50 minReplicas: 20 # 每月6-28日,最小副本数为3,最大副本数为20。 - cron: "0 0 6-28 * *" maxReplicas: 20 minReplicas: 3 # 每月29日,最小副本数为20,最大副本数为50。 - cron: "0 0 29 * *" maxReplicas: 50 minReplicas: 20 # 每月30-31,最小副本数为3,最大副本数为20。 - cron: "0 0 30-31 * *" maxReplicas: 20 minReplicas: 3 -
-
预测性弹性:
- 策略:基于历史 CPU、内存、并发指标构建流量预测模型,提前扩容并预热应用。

三、治理层:微服务无损治理,化解变更风险
基于 Knative 流量治理能力与 K8s 原生特性,构建全链路无损变更体系,保障业务稳定性:
-
无损上下线改造:对 Spring Cloud Gateway+Spring Boot+Nacos 架构进行云原生适配,通过 K8s Service 实现服务发现,配置 Readiness Gate 与 Spring Boot Actuator 健康检查,确保 Pod 就绪后再接收流量,实现伸缩、更新无感知。改造步骤:
-
南北向,Spring Cloud Gateway 禁用基于服务发现的路由,改用静态配置;
yamlspring: cloud: # 1. 取消nacos配置 # nacos: # discovery: # config: gateway: discovery: locator: lowerCaseServiceId: true # 2. 禁用基于服务发现的路由,改用静态配置 enabled: false routes: - id: main-app # 3. 由于禁用了服务发现,需要手动配置路由规则 uri: http://main.prod.svc.cluster.local predicates: - Path=/api/main/** filters: - StripPrefix=2 - name: Retry args: retries: 1 -
东西向:FeignClient 指定 url,url 使用内部域名;
java@Component @FeignClient(name = "main-app",contextId = "SysUserServiceApi", url = "http://main.prod.svc.cluster.local") public interface SysUserServiceApiConsumer extends SysUserServiceApi { } -
引入 Spring Boot Actuator,开放 actuator endpoint,配置优雅停服;
xml<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> </dependencies>yaml# 开放actuator所有endpoint,根据实际情况按需开放 management: server: port: 8081 endpoints: web: exposure: include: "*" # endpoint按需开放 # 优雅停服 server: shutdown: graceful spring: lifecycle: timeout-per-shutdown-phase: 60s -
通过配置 Readiness Gate 确保 Pod 平滑更新
yamlapiVersion: serving.knative.dev/v1 kind: Service metadata: name: main spec: template: spec: terminationGracePeriodSeconds: 120 containers: - name: main image: "registry.example.com/main:v1.0.0" readinessProbe: failureThreshold: 3 httpGet: path: /actuator/health/readiness port: 8081 scheme: HTTP initialDelaySeconds: 60 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 5无损上下线流程时序图:
Pod Pod Spring Boot 应用 queue-proxy kubelet EndpointSlice ALB Ingress Pod Spring Boot 应用 queue-proxy kubelet EndpointSlice ALB Ingress 🟢 上线:注册与流量接入 🔴 下线:触发与流量切断 terminationGracePeriodSeconds 开始 🔄 优雅关闭与排空 par [并行处理] ⏹️ 最终清理 alt [优雅关闭成功] [优雅关闭超时] 1. 启动容器 2. 应用就绪 3. 报告 readiness 成功 4. 注册 Pod IP 5. 开始转发流量 6. 发送 SIGTERM 7. 立即失败 readiness 8. 移除 Pod IP 9. 停止转发流量 10. 继续处理已接收请求 11. 返回结果 12. Spring Boot 优雅关闭 时限: timeout-per-shutdown-phase 13. 进程正常退出 14. 进程被强制关闭 15. 清理容器与 Pod -
-
全链路灰度发布:Knative 除了基于流量比例灰度,还支持基于 Header 指定版本灰度。基于 Header 进行流量灰度配置步骤:
-
配置 knative service traffic ,并对
revisionName:main-00002设置tag: canaryyamlapiVersion: serving.knative.dev/v1 kind: Service metadata: name: main annotations: route.serving.knative.aliyun.com/revision-tag: "on" spec: template: spec: containers: - name: main image: "registry.example.com/main:v1.0.0" traffic: - latestRevision: false percent: 0 revisionName: main-00002 tag: canary - latestRevision: false percent: 100 revisionName: main-00001 -
访问灰度服务
-
yaml
curl -H "Knative-Serving-Tag:canary" http://main.prod.svc.cluster.local/actuator/health/readiness

[圆角星星] 业务价值 [圆角星星]
该方案通过技术架构重构,推动系统应用计算云原生升级,系统性解决"成本、效率、稳定性"三重矛盾。
火箭
成本优化:资源利用率提升 40%+,算力成本节省 70%,弹性资源按需付费降低冗余成本;
火
效率提升:智能弹性体系替代人工干预,资源伸缩响应时间从小时级缩短至分钟级;
灯泡
稳定性保障:无损上下线 + 灰度发布,彻底规避变更风险,保障业务持续可用。
某业务管理系统经改造后,其成本结构已从固定支出转为按实际使用量动态计算,从而使服务器成本预计大幅降低约70%,降至改造前的20%-40%。

展望:AI 驱动的弹性智变
面向未来,碧桂园服务将在试点基础上进一步深化云原生弹性能力建设:一方面,推动 AI 与云原生技术深度融合,探索基于大模型的流量预测与智能决策能力,通过分析历史流量模式、业务活动计划等多维数据,实现从"被动响应"到"主动预判"的跨越;另一方面,持续深化 FinOps 成本运营实践,完善标签化成本分摊、实时成本监控和预算预警机制,让云资源投入从"粗放式消耗"转向"精细化运营"。
从"为峰值买单"到"按需所用",从"人工运维"到"智能自治",碧桂园服务将继续以弹性智变赋能业务发展,在降本增效的道路上持续深耕。
本文作者:
黄志鸿:基础设施运维高级工程师
指导人:
张旺其:技术管理专家