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

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