共计 4240 个字符，预计需要花费 11 分钟才能阅读完成。
近年来，汽车产业向「电气化、智能化、网联化、共享化」疾速演进，「软件定义汽车」模式和 SOA 理念在汽车研发和设计畛域逐步深刻。无论是作为智能网联汽车云端底座的 TSP 平台、基于单车智能 ADAS 的主动驾驶体系，还是实现软件定义汽车的 SOA 框架，均须要更加灵便的软件开发、迭代、复用和运行架构保障。
云原生技术的疾速倒退和落地，大大扭转了车联网利用传统的开发和运行形式。以其灵便、弹性、麻利、自动化、高可用、易扩大等个性，为汽车行业智能网联和主动驾驶相干软件的开发和运行，提供了平台层面的助力，解决了车联网平台在新趋势下面临的上述挑战。
云原生： 在 CNCF（云原生计算基金会）的定义中，云原生技术有利于各组织在私有云、公有云和混合云等新型动静环境中，构建和运行可弹性扩大的利用。云原生的代表技术包含容器、服务网格、微服务、不可变基础设施和申明式 API。
本文旨在深入分析云原生技术如何作用于车联网物联网基础设施构建，基于体系中最要害的车端音讯采集、挪动、解决和剖析畛域，联合 EMQ 相干数据基础设施软件，实现云原生的车联网基础设施架构。
传统车联网平台构建的挑战
传统车联网的音讯解决框架在构建底层资源和运行平台端的整体框架时，往往采纳本地数据中心虚拟机 / 物理机或云服务商虚拟机进行部署。此种模式在联网车辆疾速增多、车端上传数据更加简单的场景下，通常会面临如下的痛点和挑战：
- 各大主机厂若想将在公有数据中心提供车联网服务的模式转变为通过私有云提供车联网服务，传统的以虚拟机为利用承载形式的架构会过于惨重，无奈平滑实现车联网混合云迁徙需要和混合云的部署模式；
- 随着智能化和网联化的疾速倒退，车联网零碎对于音讯解决平台的软件迭代能力要求逐步进步，传统的软件迭代模式无奈应答智能网联对于车联网零碎麻利、灵便和疾速的能力要求，针对纷繁复杂的音讯解决需要和软件迭代也无奈响应；
- 车联网零碎作为主机厂同终端客户最重要的实时沟通零碎，须要具备极高的可靠性、可用性和可撑持性。音讯解决平台作为外围利用组件，应具备弹性的资源获取能力和自动化伸缩、运维等经营撑持能力。传统的巨石型利用架构和虚拟机部署模式无奈满足音讯解决平台弹性和自复位的能力要求。
云原生技术赋能新一代车联网音讯解决
CNCF（Cloud Native Computing Foundation）旗下我的项目中以容器编排零碎 Kubernetes 最为外围和根底。Kubernetes 通过将应用程序的容器组合成逻辑单元，以便于管理与服务发现，其为开源零碎，能够自在地部署在企业外部、公有云、混合云或私有云，不便用户做出自由选择。
越来越多的主机厂在业务平台的生产交付场景中，采纳云原生技术打造以下能力，助力智能网联汽车的利用演进和倒退。
- 对立部署 ：提供屏蔽底层资源型基础设施差别，一次构建，多处应用的能力
- 易于施行 ：提供 CaaI(Config as an Infrastructure)，即配置即设施的能力，达到配置即运行时成果的能力
- 弹性扩容 ：依据业务应用状况进行资源型资源的疾速弹性伸缩，提供运行时伸缩，业务利用无感知的能力
- 监控告警 ：提供欠缺的监控告警体系，满足生产环境前期保护的可控性能力
- 版本迭代可控 ：提供危险可控的版本变更伎俩，包含版本追溯与回滚的能力
基于 Operator 的 EMQX 云原生框架
晚期 EMQ 产品云原生部署采纳的是 Helm 部署形式，Operator 模式的呈现为实现自定义资源提供了规范的解决方案，解决了通用 Kubernetes 根底模型元素无奈撑持不同业务畛域下简单自动化场景的痛点，为实现更加简略、高效的 EMQX 部署提供了全新的形式。
简略来说，Operator 模式是一组自定义控制器的汇合以及由这些控制器所治理的一系列自定义资源，咱们将不再关注于 Pod（容器）、ConfigMap 等根底模型元素，而是将它们聚合为一个利用或者服务。Operator 通过控制器的协调循环来使自定义利用达到咱们冀望的状态，咱们只须要关注该利用的冀望状态，通过自定义控制器协调循环逻辑来达到 7*24 小时不间断的利用或者服务的申明周期治理。基于 Operator 的 EMQX 云原生框架，使得用户能够轻松基于 Kubernetes 的模式部署和运维 EMQX 集群。
Operator VS Helm
Operator 的治理不仅限于 Pod，也能够是多个资源（比方 SVC 域名等）。从这个角度上来说，Operator 跟 Helm 一样，也是具备编排能力的。从编排角度来看，Helm 与 Operator 有十分多的共性，很难对两者的作用进行辨别。Helm 也能够实现分布式系统的部署。
那么 Operator 跟 Helm 又有什么样的区别呢？
- Helm 的侧重点在于多种多个的资源管理，而对生命周期的治理次要包含创立更新和删除，Helm 通过命令驱动整个的生命周期。
- Operator 对于资源的治理则不仅是创立和交付。因为其能够通过 watch 的形式获取相干资源的变动事件，因而能够实现高可用、可扩大、故障复原等运维操作。因而 Operator 对于生命周期的治理包含创立、故障复原、高可用、降级、扩容缩容、异样解决以及最终的清理等等。
- 如果把 Helm 比作 RPM，那么 Operator 就是 systemd。RPM 负责利用的装置、删除，而 systemd 则负责利用的启动、重启等等操作。
Operator 工作原理
Operator 应用自定义资源（CR）治理利用及其组件的自定义 Kubernetes 控制器，自定义资源 Kubernetes 中 API 扩大，自定义资源配置 CRD 会明确 CR 并列出 Operator 用户可用的所有配置，Operator 监督 CR 类型并且采取特定于利用的操作，确保以后状态与该资源的现实状态相符。
Operator 中次要有以下几种对象：
- CRD：自定义资源的定义，Kubernetes API 服务器会为你所指定的每一个 CRD 版本生成 RESTful 的资源门路。一个 CRD 其实就是定义本人利用业务模型的中央，能够依据业务的需要，齐全定制本人所须要的资源对象，如 EMQX Broker、EMQX Enterprise 等这些都是能够被 Kubernetes 间接操作和治理的自定义的资源对象。
- CR：自定义资源，即 CRD 的一个具体实例，是具体的可治理的 Kubernetes 资源对象，能够对其进行失常的生命周期治理，如创立、删除、批改、查问等，同时 CR 对象个别还会蕴含运行时的状态，如以后的 CR 的实在的状态是什么，用于察看和判断，CR 对象的真正所处于的状态。
- Controller：其实就是控制器真正的用武之地了，它会循环解决工作队列中的动作，依照逻辑协调利用以后状态至冀望状态。如察看一个 CR 对象被创立了之后，会依据实现的逻辑来解决 CR，让 CR 对象的状态以及 CR 对象所负责的业务逻辑缓缓向冀望的状态上凑近，最终达到冀望的成果。举例来说：如果定义了一个 EMQX Broker 的 Operator，那在创立 EMQX Broker 的时候，就会始终协调和察看 EMQX Broker 真正的集群是否已创立好，以及每个节点的状态和可用性是否衰弱。一旦发现不合乎冀望的状态就会持续协调，始终保持基于事件的机制一直检查和协调，以保障冀望的状态。
EMQX 在车联网场景中的云原生实际
基于 Operator 模式，咱们提供了 EMQX Operator 来帮忙客户在 Kubernetes 的环境上疾速构建和治理 EMQX 集群。
EMQX Operator 是一个用来帮忙用户在 Kubernetes 的环境上疾速创立和治理 EMQX 集群的工具。它能够大大简化部署和治理 EMQX 集群的流程，将其变成一种低成本的、标准化的、可重复性的能力。
作为车联网的外围底层撑持组件，EMQX 能够通过 Kubernetes Operator 进行部署、治理和运维。通过基于云原生的音讯解决平台，为车联网场景中的客户开发和运维部署带来了诸多益处：
- 无感和滚动更新：以云原生技术构建的车联网音讯解决框架，能够轻松实现车联网利用的灰度公布，使得车联网系统升级迭代过程中无需中断服务，让车联网利用的使用者齐全无感知，实现无感迭代和滚动更新，晋升用户体验；
- 对立监控：基于云原生技术，车联网零碎的运维者可轻松进行利用集群和节点的监控和治理。通过与 Prometheus 等监控工具的集成，能够轻松获取车联网中最重要的音讯解决平台的运行信息，从而更直观清晰地理解业务运行状况，进行相应的业务迭代；
- 疾速部署：云原生技术能够让车联网开发和运维人员疾速部署和调整利用，无论是基于私有云还是公有云环境，均能够轻松部署相应的 EMQX 集群，实现对业务的撑持；
- 标准化镜像：EMQX 基于云原生环境提供了标准化的官网容器镜像，当用户零碎通过镜像来进行 EMQX 的部署和构建时，可基于标准化镜像进行相应的工作，对于车联网环境中的疾速公布和屡次构建等需要提供了很好的撑持；
- 弹性伸缩：随着车联网利用的深刻，整个音讯解决框架所须要对接的利用逐渐扩大和车联网规模的增大，音讯解决平台对资源的弹性能力要求也越来越高，通过 Kubernetes 弹性灵便的资源撑持模式，能够针对利用的使用量进行资源获取、减少和开释，从而节俭资源，升高经营老本；
- 疾速迭代：基于云原生框架构建的车联网利用，可利用继续集成和继续交付流水线实现利用的即时更新和公布，撑持业务对于车联网疾速迭代的需要；
结语
随着云原生理念在各行业的深刻，咱们置信云原生也将为车联网畛域的平台构建与利用开发模式注入新的能源。将来 EMQ 将围绕对 EMQX 新版本个性的反对，不断完善迭代 EMQX Operator，致力于在云原生模式下提供更加丰盛牢靠的数据基础设施能力，服务于车联网行业。
本系列中的其它文章
- 车联网平台搭建从入门到精通 01 | 车联网场景中的 MQTT 协定
- 车联网平台搭建从入门到精通 02 | 千万级车联网 MQTT 音讯平台架构设计
- 车联网平台搭建从入门到精通 03 | 车联网 TSP 平台场景中的 MQTT 主题设计
- 车联网平台搭建从入门到精通 04 | MQTT QoS 设计：车联网平台音讯传输品质保障
- 车联网平台搭建从入门到精通 05 | 车联网平台百万级音讯吞吐架构设计
- 车联网平台搭建从入门到精通 06 | 车联网通信安全之 SSL/TLS 协定
- 车联网平台搭建从入门到精通 07 | 国密在车联网平安认证场景中的利用
版权申明：本文为 EMQ 原创，转载请注明出处。
原文链接：https://www.emqx.com/zh/blog/cloud-native-smart-connected-car-messaging
