为增强IT资源成本控制、业务创新迭代效率、微服务治理等能力,2022年开始,CSDN全面实施云原生战略。以云原生的方式建立从应用开发、持续部署到监控运维的全栈式平台,探索业务上云/跨云迁移的企业级解决方案。

图进度图所示,自2022年年中起,CSDN后端业务线开始Serverless化改造,然而,随着云原生改造的逐步深化,我们在效率、稳定和成本三个层面的不断评估中面临着一系列的考验,例如:

  • 云原生能在哪些领域降本增效?如资源利用率、环境隔离、开发测试提效、平台运营等

  • 为充分利用云原生带来的技术红利,我们需要做哪些技术改进?如弹性能力、CI/CD等

  • 降本不能降质,降本的同时如何保障系统稳定性和业务连续性?

带着这些问题和挑战,这篇文章和大家分享CSDN在云原生深化改造中的演进路线以及相关经验,主要分为以下三部分:

  • 现状:引入云原生技术之前CSDN的架构现状和痛点

  • 选型:调研云原生技术方案时的思考与决策

  • 落地:我们是如何分阶段将CSDN全平台几十个系统全面改造落地的,以及最终效果和规划

云原生改造的实现路径-LMLPHP

1. 背景

当前,云原生已经成为企业数字化转型的关键策略。那么何为云原生?CNCF最新定义如下:

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

可见,相比传统架构,云原生架构在编程模型、交付方式、运维体系都产生了巨大的改变。云原生架构通过从业务代码中剥离了大量非功能性特性(如弹性、韧性、可观测性等)到 IaaS 和 PaaS 中,让业务更敏捷,很稳定的同时成本更低。【关于云原生的更多相关知识,可通过云原生入门技能树进一步了解】

作为全球最大中文开发者社区,CSDN月活用户达到1000万+,每月超过40万+用户原创文章和48万+评论,日均PV和UV分别达到3600万+和800万+。随着业务的高速发展,CSDN的整体应用架构也在持续不断的进化,但仍存在了以下问题:

  • CSDN业务场景丰富且系统众多,应用层、数据层碎片化严重,管理复杂,整体技术架构待优化

  • 核心业务线按照峰值以整机形式长期独占云上资源池,缺失自动扩缩容能力,资源利用率低

  • CI/CD体系虽已率先完成改造升级,但部署交付时由于异构环境部署复杂、云服务依赖等问题,人效损耗严重

面对以上问题,我们始终在寻求一种能同时兼顾系统稳定性、业务创新迭代效率、以及IT资源成本控制的有效解法,而这些诉求与云原生架构的核心能力天然契合。

其实在几年前,我们便对云原生技术赋能业务有过选型和试点,吹响云原生转型的号角。从18年的微服务改造和Kubernetes实践、到20年非核心/增量业务向阿里ACK容器服务迁移等。经过这段时间的实践积累,为更好支撑业务发展,今年我们开始全面推行云原生战略。

2. 方案

在面对海量互联网用户服务及历年大促场景的实践中,CSDN运维团队沉淀了丰富的方案和经验,如服务流量管控、熔断限流降级、高度自动化软件交付、可观测架构等核心技术。

结合自身业务特性和复用已有的成熟技术,CSDN在设计云原生架构时制定了以下方案。在满足云原生+多云迁移需求的同时,尽量减少系统建设和运维带来的成本。具体如下:

  • 容器云平台方案:华为云CCE+CCI高弹架构

容器作为一种不可变基础设施,天然具有 “跨平台迁移、自动伸缩” 的特性,能够有效屏蔽多云间的异构性,实现应用开发、测试、部署环境的标准化。根据公司服务规模和基础设施规划,采用基于原生Kubernetes的华为云cce集群+cci 容器实例搭建容器资源池。通过CCE+CCI高弹架构,平峰时段使用AutoSaler对node节点进行调整,实现常备资源的分钟级调整;高峰期和突发流量基于自定义指标监控秒级弹性到CCI容器实例。即可保证资源的有效利用,又能维持业务的常备冗余度。

  • 微服务注册及流量管控方案:nginx+consul

CSDN业务架构通过自建的nginx集群网关作为流量接入层,通过接入层控制所有业务线的流量分发,实现跨业务线、跨平台的服务发现和互通性。而在业务线全面k8s化的过程中,我们基于华为云CCE Turbo集群提供的云原生网络2.0模型,通过打通consul微服务注册框架实现对后端容器组IP的动态发现,使nginx接入层可直连后端容器,直接对接k8s的服务体系,不仅大大降低了网络损耗及网络资源,也解决了分布式环境中的网络调用问题,实现微服务之间的互通互访和统一管理。具体的,应用微服务注册方式是通过轻量级SDK将逻辑下层到Sidecar容器实现,轻度改造业务代码即可接入,有效降低了多语言的维护成本。

  • 敏捷提效:jira+gitlab+jenkins

软件交付的困难在于环境之间的差异,以及软件交付和运维人员的技能差异。为屏蔽不同环境之间的差异对交付人员造成的困扰,公司采用jira做研发流程管理,通过集成gitlab与jenkins等相关工具,实现高度自动化软件交付。将需求上线流程和流水线进行整合,基于容器进行标准化的软件交付,上线的每一阶段都经过可靠性验证,以支持随时自主上线。

  • 应用配置隔离

在服务多云迁移的过度架构中,各环境应用的配置项和中间件的配置应该保证与目标部署环境的一致性,并且分别维护基线。基于此,我们使用Apollo分布式配置中心集中化管理应用不同环境、不同集群的配置,配置修改后能够实时推送到应用端,实现多云环境的隔离,以及动态调整日志等级、开关驱动等功能特性;并且具备权限管理、流程审计等特性。

  • 微服务可观测性

在云原生架构下,应用数量较多,定位问题复杂,因此,服务可观测性要求非常高。我们在华为云CCE集群中,基于开源Prometheus构建的监控告警服务及云厂商应用实时监控ARMS产品,从基础架构、容器层到应用层涵盖基础监控、调用链、实时日志、事件等,提供完整数据大盘监控,有助于线上故障紧急诊断、排查与恢复,切实提高监控效率,压降运维工作量。

  • 多云迁移方案

基于上述方案,如何提高迁云效率,建议迁移期间对企业业务的影响便是此次改造的关键所在。针对CSDN各业务线的重要程度,结合数据割接与业务割接步骤,我们将迁移方案分为停站迁移和不停站迁移:

停站迁移:最为朴素的多云迁移方案,指的是在迁移期间,将应用短暂停机,待数据从阿里云增量同步至华为云并验证后,修改华为云业务连接地址并重新启动应用,同时将流量全量切至华为云。该方式特点是操作简单,但劣势是影响面广,多云回滚难度大。

不停站迁移:适用于对 不要求停机进行增量数据的同步。而是在迁移前,建立阿里云和华为云流量接入层的双向对接机制,必要时可实现双注册双订阅,确保线上切流的可控可回滚性。而在数据割接过程中,同时运行两套系统,并将业务限制为只读权限,待同步完毕后,切换连接地址并重新开放写入权限。该方案对实时业务的影响面小,容错性高,保证业务可靠性和稳定性;但劣势是流程繁琐耗时,代价较高。

云原生改造的实现路径-LMLPHP

3. 落地实践

云原生架构体系内容众多,我们采取多阶段、标准化的方式循序渐进推动,边建设边交付,使整个架构体系具备可持续性。

第一阶段:Serverless化

由于CSDN业务场景丰富且系统众多,每个业务团队根据自身的业务特点采用合适的技术栈和基础架构,因此内部出现了ECS、ACK+ECI等不同计算平台共存的局面,并且同期仍运行在ECS平台的博客、下载、搜索等核心业务线,定期峰谷、业务洪峰、频繁迭代的业务特性显而易见,此外,还缺少统一的可配置的管理模式,让整体系统的公共部分可以尽可能的抽象并复用。

综合上述考虑,CSDN运维团队一直在寻找一个简单完美的解决方案一并解决上述问题。经过对各大云厂商云原生产品的调研,结合CSDN系统架构对阿里云体系的依赖,我们选择了阿里云SAE产品(Serverless应用容器引擎)完成初步的云原生改造。这一阶段改造重点是将后端业务通过Serverless应用容器引擎将计算能力弹出去,即将资源层面托管在SAE,极大的简化了运维复杂度,而系统整体的流量接入层不变,迁移期间通过流控系统切入部分流量至SAE,若出现特殊情况时,可以将流量瞬间切回ECS/ACK,充分保障系统的高可靠性。

通过与阿里 SAE 团队的不断磨合验证,历时两个月,我们将CSDN包括博客、下载、会员、学院等30+业务线,130+项目全面 Severless 化!整个迁移过程采用ECS/ACK+SAE混合切流方式有序推进,落地平滑,改造成本低,每条业务线只需投入1名研发人员配合运维团队即可完成迁移。最后,CSDN在Serverless化改造阶段的成效总结如下:

  • 快速上云:作为一站式应用PAAS平台,SAE开箱即用的特点有助于快速升级微服务+Serverless云原生架构。同时 SAE底层采用的托管K8S集群,在借助SAE解决业务测核心痛点的同时,我们也积累了一些新的云原生能力,这也为CSDN后续全面K8S化提供了坚实的技术保障。

  • 敏捷+标准化交付:基于jenkins+IaC+SAE打通CI/CD流水线,在标准化的基础上进行自动化,解耦各类环境的交付复杂性,实现整个软件交付和运维的自动化。得益于IaC脚本优化和SAE发布的稳定性,版本迭代期间,部署效率有了很大的提升,解放运维团队的人力投入,专注于横向高可用等体系的建设。

  • 极致弹性:SAE具有灵活多样的弹性策略,可以基于CPU、内存、QPS、RT等指标进行设置,也能设置定时弹性。对于CSDN定期峰谷、活动洪峰的业务特性,主要是通过QPS、RT指标和定时弹性方式共同作用,面对高峰时急剧增长的业务量,能在短时间内自动扩容,而在峰谷时回收资源降本,整体资源利用率大幅度提升。相比于以往ECS长期保有的方式节省了IT资源成本。

  • 微服务治理:在迁移过程中,我们也碰到了一些应用状态异常的问题,如博客API499、消息系统502、文库实例缩容超时等。SAE提供的全套微服务治理能力,如集成的可观测性ARMS监控、MSE无损上线(小流量预热机制)、prestop脚本优雅下线、灰度能力、sls日志分析等,支撑了从发布、运⾏、故障排查、故障恢复的全链路流量治理能力,这也为我们运维团队后续对微服务治理生态的构建提供了成体系的指导。

第二阶段:架构多云化

当前,CSDN的整体架构主要依托阿里云平台构建,其中,PAAS资源涵盖RDS,Redis,MongoDB,RocketMQ、对象存储、视频点播、直播等产品;业务底座通过ECS、ACK、SAE计算平台支撑;大数据平台Flink、Dataworks、PAI等;上层流量通过SLB+WAF防火墙+API应用网关安全接入业务层;在治理层面采用ARMS、SLS、PTS压测工具等云服务保障稳定性。企业上云部署已是大势所趋,然后过度依赖单一云服务商的给整个系统体系带来了不少的捆绑风险,从企业层面而言,无论是避免厂商锁定,还是出于对数据主权、安全隐私的考量,都需考虑多云/混合云的部署形态。

随着业务的高速发展,CSDN的整体架构也在持续不断的进化。自Serverless化之后,为了满足成本优化、避免云厂商锁定、及统一运维体系的需求,CSDN运维团队开始考虑多云部署战略的实施。对于跨云迁移中的核心风险点,如迁入/迁出成本控制,跨云调用稳定性、数据一致性等问题,我们基于原来系统架构进行了重新的评估和审视,首要任务是对原来架构进行一定范围的重构,以具备持续演进的能力来支撑整个多云架构的建设。在这一阶段,我们重点针对跨云调用、交付和管理进行改造,以支持混合云部署,提高迁云效率,竭力降低迁云风险。具体措施如下:

  • 网络多云重构:要完成服务跨云迁移,首要切入点就是解决跨云调用问题。因CSDN产品线比较多,服务之间耦合度很大,跨云平台之间调用的稳定性、网络延时必须得以充分保障。我们通过两条专线静态路由NQA做负载,实现跨云调用,满足高可用、低延迟要求,同时做到网络资源的集中管控、灵活按需分配。

云原生改造的实现路径-LMLPHP
  • 统一应用交付:针对研发运维流程效率问题,沿用 我们对现有CI/CD架构进行改造升级,通过Jenkins+Iac+Kubernetes operator等自动化交付工具,统一多云环境的对接标准和交付方式,支持多云混合架构,解决对接和部署上的效率问题。

  • 统一管理平面:在过往的体系建设中,由于不同的底座计算平台、开发模式等差异造成了IT系统和运维体系的割裂。因此,建立全链路、实时和多维度可观测性的一站式管理平面也是云原生改造的一大诉求。我们通过构建PaaS体系,建立统一可配置的管理模式,内部实现运维一体化,如统一日志管理平台、监控预警系统、流控等,降低对 IaaS 层的差异。

第三阶段:全面接入K8S

虽然一直在强调云原生降本增效,但实际过程中仍可能会产生一些不必要的支出。Serverless是微服务架构下降低迁云复杂度,减少维护成本的最佳解决方案之一,然而对于一些低吞吐的业务而言,在SAE中的单位算力承载效率并不高,统计之后发现一些业务为确保稳定性和连续性,在波谷期间仍维持冗余部署。而SAE的计费方式是以“limit”值计费独占了整个资源池,存在大量闲置浪费。也就是说,我们不仅为波峰资源买单,还需要为一直处于高水位的波谷资源买单。

鉴于此,我们一直在探索更具性价比的 IaaS 资源,以期实现资源的极致弹性。为了进一步满足在成本控制、效率提升、避免厂商锁定等方面的需求,通过调研业界主流的技术方案,2022年9月,CSDN开始全面接入K8S。我们最终选择华为云CCE Turbo云容器引擎作为新的计算底座,并围绕CCE整合周边云原生能力。华为云容器引擎提供高度可扩展的、高性能的企业级Kubernetes集群,在系统可靠性、高性能、开源社区兼容性等多个方面具有独特的优势,满足企业在构建容器云方面的各种需求。

云原生改造的实现路径-LMLPHP

在此阶段,CSDN前端Node.Js和后端Java业务线都将迁移至CCE,并围绕CCE增强云原生能力,打通 DevOps、监测体系、日志链路等平台,统一云上运维和资源管控能力。截止目前,在华为云CCE集群中已累计迁移部署140+服务和应用,具体成效如下:

  • 高性能网络模型:在业务线全面k8s化的过程中,我们基于华为云CCE Turbo集群提供的云原生网络2.0模型,通过打通consul微服务注册框架实现对后端容器组IP的动态发现,使nginx接入层可直连后端容器,直接对接k8s的服务体系,可以有效减少因容器而引入的网络性能下降,不仅大大降低了网络损耗及网络资源,也解决了分布式环境中的网络调用问题,实现微服务之间的互通互访和统一管理。同时通过关联容器就绪探针和微服务注册,保证微服务应用的发布态与运行态的对齐,避免应用发布上线的有损问题。

  • 弹性+容量规划方案:通过CCE+CCI高弹架构,平峰时段使用AutoSaler对node节点进行调整,实现常备资源的分钟级调整;高峰期和突发流量基于自定义指标监控秒级弹性到CCI容器实例,有效应对流量洪峰。此外,通过Prometheus SQL精细化统计容器cpu、内存的全天使用率,继而通过关联集群负载阈值和容器使用率,指导容器requests、limits值的设置,既能保证资源的有效利用,又能维持业务的常备冗余度,有效提高资源利用率

  • 业务全景监控体系:按照统计数据,迁移CCE后CSDN业务线每天的的API调用量高达20+亿次。因此,必须构建可靠且有意义的监控系统需,具备对系统⻛险和异常的快速定位和能力。在这方面,我们通过整合联邦Prometheus系统、华为APM、阿里AHAS等产品,构建业务全景监控体系,监控微服务之间的拓扑、会话请求调用链、各环节耗时和RPS、RT等性能状态,实现对应用的全方位监控,以快速定位出错接口和慢接口、发现系统瓶颈,提升线上问题诊断的效率。

第四阶段:微服务治理

随着云原⽣技术的不断发展,微服务治理也仍旧在快速的发展和变⾰中。调研发现,服务治理数据⾯将会逐步下沉,与业务逻辑逐步解耦将是云原生阶段微服务治理的发展趋势。在完成容器云平台运行时支撑建设之后,CSDN运维团队下阶段的工作将侧重实现更深度的微服务治理。本阶段还在实施过程中,规划如下:

  • 无损上下线:基于当前sidecar方式部署的consul agent自研小流量预热机制、应用下线主动注销、以及对齐应用上线健康检查与生命周期等技术手段实现应用的无损上下线发布功能。

  • 云原生网关:实现全链路灰度是微服务治理深化过程中必须面临的挑战。CSDN计划构建基于KONG的微服务网关,并通过融合流量网关和应用网关,提供精细化的流量治理能力,实现如全链路灰度分流、金丝雀发布、流量防护、安全控制等功能。

4 总结与展望

我们首先在年中快速完成了Serverless化,这一阶段的改造重点是通过SAE将算力资源弹性起来,然而完整的云原生架构不仅仅只是考虑资源层面,还包括其它众多因素。随着云原生改造在CSDN的逐步深化落地,我们开始全面拥抱k8s,并且同期完成了系统层面的改造加固升级,通过增强平台微服务路由管理、DevOps、弹性、韧性、可观测性等方面的能力,整合内外部多系统,有力支撑了业务的敏捷发展和稳定运行。

在未来,我们希望能够更进一步通过云原生技术去解放运维人员在垂直业务线的人力投入,专注于横向高可用保障、监测体系、服务治理等能力的建设,期望沉淀更多的云原生使用经验,助力探索不同场景下业务迁移/上云的企业级解决方案。

后续,针对改造过程中的一些关键技术点和解决的典型问题,我们将持续发布博文,敬请关注。

附:

这是我们年度总结的一部分,完整的总结见:2022年下半年部分团队的总结

需要了解更多云原生内容的可以浏览:云原生频道

01-06 17:43