飞行中换引擎 长城汽车 业务中台同城双活架构升级 toC (飞行中换引擎 出处)

飞行中换引擎 长城汽车 业务中台同城双活架构升级 toC (飞行中换引擎 出处)

据 IDC 调研数据显示,在汽车云基础设施市场中,公有云占比高达 59%。云作为汽车行业的创新性基础设施,汽车上云已经成为事实趋势。然而,单一云服务对国内主流汽车企业带来了高度依赖与绑定的风险。为了提高汽车企业的业务可靠性,多云已经成为汽车企业的一大上云趋势。

长城汽车 是一家全球化智能科技公司,一直以来积极拥抱数智化变革,通过云计算等先进技术,不断优化提高用户体验。作为车企品牌与用户之间的高度信息与机会互动的生态载体,车企移动端 APP 与小程序业务的稳定性与质量直接关乎存量车主用户留存与潜客试驾转化。当前,长城汽车的移动端 APP 与小程序业务分布在不同的云环境,这对故障时的业务快速迁移、业务持续高可用带来了较大挑战。

为应对该挑战,长城汽车选择与火山引擎进行营销侧移动业务的双云双活探索与论证,依托火山引擎云原生产品方案,构建多云双活应用架构,实现了不同云环境中应用的自动部署、扩展和管理。同时,通过建立完善的全生命周期多云观测体系,在应对业务故障时实现流量的无缝切换,减少故障感知,满足长城汽车对多云部署下敏捷性、弹性、高可用性的多方面需求:

同城多云双活架构设计方案

容灾架构从最早期的单活形态(同城主备)发展到同城多活形态,再演化到异地多活,随着容灾能力的提升,伴随的是更复杂的技术架构、更高的业务改造成本和更高昂的资源成本。

相比自建基础设施,公有云厂商往往能提供 SLA 更有保障的服务,因此对于云上用户来说,容灾能力的建设目标非常明确: 即能够应对和处理单云单地域的故障,从而保障业务的连续性 。同城不同云厂商机房间的网络延时较短,数据库、缓存和消息等在数据容灾方面容易实现得多,所以 同城多云多活架构 是企业提升业务韧性最有效、最经济、最务实的手段之一。

下面是长城汽车营销云同城多云双活架构的整体方案:

多云发布:构建以应用为核心的开发能力

企业在执行多云战略的过程中,最核心的是要围绕自身的业务应用。在多云环境中,屏蔽多云带来的环境差异、让开发人员可以聚焦业务本身将有助于业务敏捷。

火山引擎多云容器应用发布为客户提供了一种灵活、高效的 跨云平台部署 管理容器化应用 的能力。它解决了传统单一云服务可能遇到的资源瓶颈、地域限制和单点故障风险问题,通过在不同云环境中实现应用的自动部署、扩展和管理,充分保障服务的高可用性和快速恢复,实现业务连续性。这种发布策略满足了企业对敏捷性、弹性、高可用性的多方面诉求,为企业在快速变化的市场中保持竞争力带来了重要价值。

在上图的多云发布的方案中,本着 控制与业务解耦 的整体原则,客户使用 A 厂商的 CI/CD 产品提供代码托管、流水线、应用交付等控制流,并用火山引擎云原生集群联邦方案承接多云纳管、跨云调度、故障迁移等核心业务流。实现了由 A 厂商将编排应用下发到火山引擎云原生集群联邦方案,再将应用涉及的 Kubernetes 工作负载及配置资源分发到火山引擎容器服务 VKE和 B 厂商容器集群的多云业务集群中。该方案提供的关键能力与优势包括:

上述方案中的多集群调度引擎 KubeAdmiral目前已经开源,也已经过字节跳动内部超大规模(数十万节点、千万级核资源)集群管理实践打磨,火山引擎云原生集群联邦方案基于该引擎进行产品化能力增强,为用户提供性能高、稳定性强的多集群资源分发管理体验。

多云流量治理:多地多中心统一调配管理

双云多活部署架构可以很好解决单云/单 region 资源瓶颈及单个云厂商故障快速容灾切换问题,但在实际业务架构改造或多云迁移过程中,无法做到多云全量业务的对等部署,需要解决单云/单 region 部署服务的互联互通和跨云服务访问,保障多云场景下业务流程闭环。同时,当本 region 内的单个服务实例异常时,服务消费方需要及时感知并屏蔽服务提供方异常实例将流量自动调度至对端相同服务的可用实例,避免因长时间等待造成服务雪崩。

结合上述实际业务场景,火山引擎云原生团队提供云原生集群联邦方案、微服务引擎 MSE、API 网关产品组合方案,助力用户快速落地多云双活应用架构,解决跨云流量调度的多云服务寻址、就近路由访问、自动故障转移、多云流量观测等核心问题,保障流量优先在本 region 内闭环避免额外的跨云带宽和业务性能损耗,通过精准流量调控策略实现自动 failover 收缩故障影响范围。该方案的核心优势和关键能力包括以下内容:

多云注册打通 :在业务多云部署后,为了确保应用在多云部署后能够互联互通,首先需要能够打通多云间的服务发现。同时为了保证注册中心组件可靠性和数据一致性,一般会推荐在单云本地部署注册中心。因此就需要具备多个注册中心进行双向同步,保证每个注册中心都具备全量服务发现数据。火山引擎微服务引擎MSE 提供兼容主流注册中心(Nacos、Eureka 等)的同步引擎,构建注册数据双向同步链路,可实现多云场景下统一服务发现。如果采用 Kubernetes svc 服务寻址方式,为了在跨集群场景中不改变原有的服务发现的方式,MSE 会将不同集群的 svc 进行合并——在不同集群下,只要是在相同namespace 下的同名 svc,都会被认为是相同的服务,能够被对端集群消费方服务正常服务发现。

跨云流量调度 :在业务多云部署的过程中,由于数据一致性、资源负载成本、业务改造等原因,部分有状态业务、第三方开发业务等只能单云集中化部署,对于单云部署的应用,在应用层还需要提供跨云服务调用能力,保证在当前云上没有部署下游服务时,能够自动访问到对端云上部署的服务。同时,如果本云中已经部署了下游服务,则需要优先调用本云。MSE 具备跨云流量调度能力,当服务实例启动时,会将实例的归属地域自动写入注册中心元数据信息,消费方在路由调用时根据服务寻址列表的地域归属实现亲和路由,保证流量优先在本云闭环,同时 MSE 支持无侵入 java agent 和 sidecar 接入方式,用户仅需在 deployment 引入 MSE 注解即可完成实例接入,无需代码改造,极大降低业务迁移改造成本。

自动故障转移 :在业务多云部署后,由于业务发布、底层依赖故障等诸多原因,可能会造成单云上部署的某个服务不可用。在出现服务级别故障时,我们需要能够根据健康检测和熔断策略自动发现故障,将请求调用到健康实例,并在故障恢复后自动回切。MSE 支持消费方在服务调用时会根据请求状态码识别下游实例健康状态,达到指定阈值后主动剔除异常实例,当本云内的相同服务实例均检测异常时,将自动 failover 至对端相同服务可用实例保障业务逻辑闭环;同时,本云的访问实例达到隔离时间后,将自动注入少量流量判断其恢复状态,若达到健康阈值则恢复原有的就近路由调用,避免跨云调度额外带宽损耗。

多云观测:一站式跨云资源观测

相比单个云上部署的应用、在多云环境构建应用的可观测性会变得更复杂,主要会面临以下挑战:

以上挑战都导致最终观测数据难以统一查询、聚合和可视化,导致无法对多云的观测数据进行统一查询和使用,无法构建一个全局视角的监控大盘,管理员也无法一目了然地了解所有集群的状态和性能。

对于云上业务来说,观测领域核心关注的主要是指标、trace 与日志三类观测数据。指标数据可以借助火山引擎托管 Prometheus VMP实现多云指标的统一采集和监控告警,trace 与日志数据可以借助火山引擎日志服务 TLS 实现多云环境下的统一分析和查询,帮助企业轻松管理跨云资源。

指标数据多云观测

在业务多云部署后,企业用户往往需要统一多云集群监控运维方式,使用多云一致的数据采集能力抹平环境差异、降低采集组件改造和维护成本,同时也需要统一的数据查询入口,最终形成统一的监控视图。这种设计有助于运维人员从全局视角对分布在不同环境的集群和应用进行统一监控运维,一目了然地了解业务在不同云上的用量和健康情况。

火山引擎托管 Prometheus VMP 通过与平台的无缝集成,实现了监控数据采集、元数据、存储、视图和告警五个方面的统一指标监控能力:

trace&log 数据多云观测

多云网络:根据需求动态调配资源

相比单云部署,多云在网络架构上更加复杂,通过火山引擎专线连接、云企业网、中转路由器、私网连接等网络产品,企业在实施过程中可以构建一张灵活、高可用的混合云网络:

结语

未来,火山引擎云原生团队将继续推动并深化与长城汽车的合作,在多云容灾等领域进行更深入的合作,更好地保障业务连续性。我们也希望能帮助更多企业积极利用不同云厂商的特点和优势,通过统一多云管理、统一流量调度、统一多云观测,保障系统的高可用和性能优化。

火山引擎云原生团队聚焦应用多云容灾架构专题联合云上多款 PaaS 产品构建多云资源分发、智能 DNS 切换、跨云流量调度、多云容灾观测、双向数据同步的一站式解决方案,致力于帮助客户构建多云应用发布、数据层同城高可用、中间件同城高可用、容灾平台构建、应用单元化改造最佳实践,满足资源弹性伸缩同时保障业务连续稳定。

相关链接

[1] 火山引擎: www.volcengine.com

[2] VKE:www.volcengine.com/product/vke

[3] MSE:www.volcengine.com/product/mse

[4]APIG:www.volcengine.com/product/apig

[5] VMP:www.volcengine.com/product/prometheus

[6] TLS:www.volcengine.com/product/tls

[7] ECS:www.volcengine.com/product/ecs

[8]字节跳动容灾实践:同城容灾+异地多活是最好的模式吗?

声明:本文来自用户分享和网络收集,仅供学习与参考,测试请备份。