云原生驱动企业转型——降本增效与安全集成实战

维稳降本 容器集群计算资源调控实践 小鹅通容器负责人张安哲2024.08.22 目录Menu •1.多模型高体量的业务场景 •2.集群资源调控：Serverless+常驻节点高效利用 •3.服务资源调控：HPA+HPC解决业务场景需求及成本痛点 •4.落地效果及未来展望 导师介绍 小鹅通容器负责人 张安哲 小鹅通容器负责人，曾参与大型开源PaaS项目研发，主导了小鹅通容器化转型，对弹性伸缩、FinOps领域有深入研究，现负责小鹅通容器调度及集群稳定性 多模型高体量的业务场景 多模型高体量的业务场景 公司简介 小鹅通是一家以知识产品与用户服务为核心的技术服务商，创始至今已服务逾百万家客户 现如今，私域运营正在逐渐成为数字化经营的重要手段，并助推企业的业务升级和组织建设升级。小鹅通作为私域运营的一站式工具，解决产品和服务交付、营销获客、用户运营、组织角色管理、品牌价值输出等痛点并形成闭环，扎根多个行业与生态，可在企业经营过程中发挥重要作用，成为企业数字化经营的好帮手 多模型高体量的业务场景 秒杀场景 直播带货，直播间海量用户同一时刻抢购商品 考试场景 商家发布定时考试，海量学员瞬间涌入作答 直播场景 晚高峰海量用户在线观看直播 Serverless+常驻节点高效利用 集群资源波峰波谷明显 全天集群CPU用量示意图 集群资源受业务场景(如直播)及庞大用户量影响，存在明显规律的波峰波谷现象，集群资源差值达100%以上，集群闲时资源冗余明显 Serverless+常驻节点高效利用 常驻节点 Serverless(超级节点) 优势单位时间费用较低支持Crane* 调度灵活维护成本低 劣势就绪速度较慢，不够灵活 不支持超卖(Request/Limit)单位时间费用较高 *Crane是腾讯云开源的FinOps方案，其中集成节点放大等核心功能 Serverless+常驻节点高效利用 省了 但还有空间 Serverless+常驻节点高效利用 Serverless详细计费规则 单Pod成本模型对比 1.较大原则:max(max(containerLimit),sum(containerRequest)) 2.升格原则(CPU为例):3C(使用)->4C(计费)，6C(使用)->8C(计费) 常驻节点计费规则 1.(节点核数*Crane放大系数-系统组件核数)/CPURequest 如何找到节点的“黄金配比”？ Serverless+常驻节点高效利用 相同用量，成本降低12%+ HPA+HPC解决业务场景需求及成本痛点 扩缩容副本数示意图 固定HPC扩容+HPA回收高峰期整体资源保障 场景1：直播带货 商家数字化转型，将线下庞大流量带到线上直播间讲解完商品后，发出商品链接抢购瞬时成百上千倍流量涌入系统，造成压力 场景2：KA保障 扩缩容副本数示意图 商家报备时间段HPC扩容+HPA回收闲时KA资源保障 在B端场景下，长尾效应明显，单租户的流量比重会占到整个系统的大部分流量，与此同时KA客户时间段不固定，因此需要对KA客户进行特殊保障，助力用户体验顺畅 业务发展中的一些问题 大量HPA/HPC维护，人力成本较高集群利用率低下 云资源成本陡增 容器计算资源标准 通过结合业界经验与生产经验经过大量背景搜集及多次试点 最终落地容器计算资源标准并执行 容器计算资源调控服务 •Prometheus秒级数据源 •自动化定期调整 •降低资源冗余 •处理资源风险 •释放人力 HPA+HPC调控解决成本问题 容器计算资源调控服务 •Prometheus秒级数据源 •自动化定期调整 •降低资源冗余 •处理资源风险 •释放人力 落地效果及未来展望 落地效果及未来展望 复合容器资源云成本降低20%+集群整体利用率较上限提升20% 日常容器资源维护人力成本降低50% 冗余容器资源维护人力成本降低90% 落地效果及未来展望 精细化HPC时间段调控精细化规格/配置调控 引入事件驱动扩缩容，拓展更多实用场景 感谢观看！ Thankyou 服务治理场景下 借力云原生架构支撑业务稳健增长 侯诗军●腾讯云中间件产品资深架构师 导师介绍 侯诗军 腾讯云中间件产品资深架构师 目前在腾讯主要负责云原生PaaS产品架构，以及企业数字化转型与落地工作。硕士毕业于香港理工大学与华中科技大学，曾参与十余项国家信通院的云计算标准制定，拥有二十余项云计算领域的技术发明专利，kube-router、redis-operator、polaris等开源软件贡献者，云原生社区优秀讲师。具备16年研发、架构设计与运维实践经验，专注于云原生、分布式中间件、IT架构转型等领域。 目录Menu 企业IT系统架构演进趋势 分阶段场景化的治理实践 实际落地建议与应用案例 企业IT系统架构演化路径 应用孤立，按烟囱式排列，唯一的共通点在于都与底层的数据库相连； 架构中的应用较少，应用与应用之间的交互关系简单 服务调用者与服务提供者通过企业服务总线相连接； ESB成为瓶颈：无论在性能上还是成本消耗上，ESB都会导致瓶颈出现 服务的注册发现； 轻量级网络代理； 应用无感知，无侵入； 异构跨语言； 调用方 调用方 调用方 注册订阅 注册订阅 APP Sidecar 注册发现 熔断限流 服务调用 Sidecar 注册发现 熔断限流 APP 服务注册中心 解耦应用与云融合 应用更关注业务； 解耦业务和非业务； 中间件能力下沉； 云提供基础设施和各种能力 Oracle Oracle Oracle APP APP APP 提供方 提供方 提供方 ESB服务总线 资源、技术需不停的匹配业务需求，不断的促使IT架构的转型与演进 满足业务的核心需求与政策趋势 业务随时发布 及时响应业务需求，对于特定用户进行版本发布 小版本灰度迭代，金丝雀发布 业务弹性伸缩 基于访问量和请求耗时等业务参数，进行实时弹 性扩缩容 云原生包括容器化封装、自动化管理、面向微服务、服务网格、声明式API，满足数字化转型技术需求。同时本地化的适配、关键技术的把控等，符合政策指引趋势。 采用开源堆栈进行容器化，基于微服务架 需求 构提高灵活性和可维护性，借助敏捷方法 、DevOps支持持续迭代和运维自动化，利 机遇用云平台设施实现弹性伸缩、动态调度、 优化资源利用率。 系统平滑演进 能力沉淀复用 基于微服务的springcloud或servicemesh，可以进行跨语言，跨系统的和已有业务对话 开发的代码或者接口，都可以进行复用，达到越来越快的效果 落地云原生微服务架构的价值 微服务 容器化 服务网格 不可变基 础设施 声明式 API 组织管理考虑： 优化组织结构，符合康威定律，微服务职责专一，适合小团队 敏捷开发； 促进团队沟通协作，微服务就是团队的责任范围。 技术架构考虑： 可扩展性增强，微服务架构使得软件可按不同功能独立扩展； 高可用性增强，在发生意外问题时，错误范围和修复范围控制 在单个微服务内。 交付管理考虑： 提升交付效率，微服务具有自治性，独立开发/部署/运维，缩短发布周期； 多技术选择，摆脱单一技术限制，特定技术解决特定问题。 云原生微服务应用发展趋势 到2025年，全球近三分之二的企业将成为软件生产商，超过90%的应用程序为云原生应用。 ◉Kubernetes ◉SpringCloud ◉Istio 目录Menu 企业IT系统架构演进趋势 分阶段场景化的治理实践 实际落地建议与应用案例 研发阶段：多研发测试环境的流量路由 请求流量 企业中往往存在开发、测试、预发布、生产等多套环境。在代码的研发测试阶段，我们有大量的业务线要测试，在研发全流程中各种混用环境，导致各个环境运行不稳定。链路长的服务经常会不可用，阻塞测试开展。以手Q举例，由于手Q业务调用链路设计几十到上百个服务，为每个分支部署特定环境，会导致成本非常高。 解决方案： 环境信息在Deployment部署时候，作为env参数注 入到Pod的环境变量里面。 用户使用SpringCloudTencent，支持直接通过环境变量，将环境信息作为标签注册到微服务治理中心。 SpringCloudTencent提供元数据透传的能力，结合 微服务治理中心元数据路由能力，实现特性环境隔离及基线环境的共享。 方案优点： 节约部署资源，用户只需部署本次特性所需要服务。 用户侧不感知，不依赖复杂规则，可实现环境转发。 发布阶段：支持金丝雀/滚动/蓝绿多种灰度 调节比例 90% 10% V1 V1 V1 V2 服务A（入口层） 服务A（入口层） V1 V1 V1 条件路由 服务B 其他 条件A V1 V1 V1 V2 服务C 服务C PolarisMesh 云原生网关 基于PolarisMesh与云原生网关实现蓝绿、金丝雀或者滚动发布： 金丝雀发布：对于本次发布的服务，先升级一个实例，如果没有问题，再升级 剩余实例； 滚动发布：对于本次发布的服务，先升级一个/批实例，再分批升级剩余实例； 蓝绿发布：旧版本实例保持不动，另部署新版本实例，流量切到新版本实例。 灰度场景 入口层服务 非入口层服务 指定流量比例进行灰度发布 金丝雀发布 支持 支持 滚动发布 支持 支持 蓝绿发布 支持 — 指定部分用户、地域或者其他条件进行灰度 金丝雀发布 支持 支持 滚动发布 支持 支持 蓝绿发布 支持 — 业务配置 新上线功能根据地域、 用户等信息灰度 促销活动开关，中奖率 参数动态控制 中奖率40%->20% 活动时间13:00~ 15:00 动态公告，控制公告展 示以及公告文案 公告：我是一条限时公告 基础组件配置 通过配置中心管理应用 数据源，访问私钥等 Config 动态调整日志级别 作为其它基础组件配置 下发通道，例如服务治 理规则、xds协议 发布阶段：各业务场景的动态配置变更 运行阶段：实现多活容灾和就近访问 Gateway 对于多地域或跨境类业务，往往需要兼顾性能，解决跨地域的容灾 问题。建议通过云原生网关和微服务治理中心提供接入层与应用层 的多活容灾与就近访问，实现故障快速恢复、容量快速扩容。 基于自动获取服务实例的地域信息； 自动根据地域信息进行就近路由； Gateway 跨可用区、跨地域容灾切换。 运行阶段：多维度精细化限流 Gateway Polaris Mesh 为了更多的帮助业务获客，企业往往会举行一些运营活动，比如优惠券 领用等，这就会导致活动期间存在突发流量。为了防止资源被突发流量冲垮，我们可以借助于微服务治理中心设置了多级流量管控策略，保障运行活动可以顺利进行。常见的精细化限流策略如下： 基于服务/接口/标签的限流； 秒、分钟、小时、天等时间级限流； 单机限流、分布式限流。 运行阶段：熔断降级，弃车保帅 故障熔断能力是也是服务框架的必备能力，当微服务在现网运营过程中发生故障时，采用熔断、降级等手段最大限度保障服务高可用。 通过故障熔断，基于服务调用的失败率和错误数等信息对故障资源(服务、接口、分组、实例)进行剔除； 熔断监控 通过服务降级，支持当资源不可用时，进行Fallback操作的执行，防止出现超时雪崩的现象。 运行阶段：实例隔离，减小爆炸半径 将异常实例隔离，可以确保服务消费者不会访问到异常实例。在异常恢复后，您可以取消实例隔离，恢复至正常使用，帮助提升您业务的稳定性与质量。 在微服务场景中，当服务提供者的某些实例出现异常时： 避免服务消费者访问到异常实 例； 保留异常现场，便于后续的问 爆炸半径 题排查。 运维阶段：可观测与故障诊断分析 多维度观测，提供全场景下的系统分析洞察。 系统现状分析：通过服务注册数、服务间调用QPS等指标，在日 常运维中快速了解系统运行状况是否符合预期。 系