汽车在转型！福特中国的架构实践

2022 年 3 月 4 日 CSDN

软件正在吞噬汽车！当数字化、智能化逐渐渗透汽车时，也给传统车企带来了诸多的技术挑战。在此背景下，本文作者对云边协同及车联网的众多特性展开深入研究，并进行了基于微服务与容器化，深入的车云实践。

作者 | 蒋彪王函赵伟责编 | 唐小引

出品 | 新程序员

传统车企在车联网中面临的挑战

近年来，随着大数据、新能源、智能网联、自动驾驶等现代科技、创新生态在汽车行业的迅猛发展，汽车与人们日常生活的联系正变得更加紧密。如何实现“以产品为中心”向“以用户为中心”转换的业务目标，如何快速响应、探索、挖掘、引领用户的需求，如何与用户形成触点、了解用户、与用户进行有效沟通，是当下传统车企进行数字化转型的根本立足点。面对新事物、新科技、新理念所带来的冲击，传统车企向数字化、智能化与网联化的转型已迫在眉睫，但在这个过程中，也面临着众多技术挑战。

首先如何加速企业零售、技术、生产、质量等部门的数据融合，联通各个业务领域的“数据孤岛”，建立统一的数据视图，最大程度确保企业层面的数据共享？

其次，如何实现智能网联？云边协同是关键。在云端和车端之间，需要用边缘计算来解决分布式基础设施资源、计算资源、安全策略、数据策略、应用管理等方面的协同。然而，根据姚建铨院士（中国科学院院士）于2020年12月在报告《边缘计算理论科学问题初探》里指出的：边缘计算目前仍存在两个方面的问题亟须落实，一是类似PC的软硬件解耦、SDN（软件定义网络）中的数据平面和控制平面解耦、云与数据中心解耦，从而实现动态自适应地支撑各种粒度的边缘虚拟化融合，以及在边缘硬件上实现网络面、数据面和业务面的充分融合；二是强调异构场景下边缘技术栈统一，研究通用软硬件技术，充分实现IT（Internet Technology，互联网技术）-CT（Communication Technology，通信技术）-OT（Operational Technology，运营技术）的边缘融合。

第三，车联网的数据特点除了数据量大、类型多、价值密度低、速度快，同时具备专业性、关联性和时序性。如何在云端实现存储资源的有效利用、弹性扩容，实现工业大数据的冷热分离和数据容灾？这是车企云端服务在设计和实施中需要考虑的问题。

最后，传统车企对云计算缺乏理性认知，云端设计和数据中心的建设经验匮乏。在多云服务商公有云和私有云混杂的情景下，如何建立统一的云端安全防范策略和防御措施？如何集中管控云端应用的一致性，屏蔽云端IaaS和PaaS的异构性？如何平衡公有云资源的计算优势和私有云的安全优势，合理规划数据资源的存储和迁移？

福特中国的架构实践

架构理念和全景设计

有人说架构是艺术—语言的艺术或者取舍的艺术，我更觉得架构是世界观的逻辑泛化。以下我们尝试用准逻辑化的术语来勾画出架构思想。

首先，我们提出如下架构定理1：

定理1. 架构是产品的骨架，理念是架构的准则(Principle)！

就好像大厦不能没有钢筋骨架，桥梁不能没有墩柱垫石，一个产品没有正确的架构，必然是失败的。但什么才能决定架构是否正确？正如TOGAF（开放组体系结构框架）之类的架构方法论指出的，准则是架构的灵魂，理念是架构的准则。

我们在架构实践中发现，很多传统主机厂在数字化转型过程中最大的问题，不是没有技术或产品，而是没有理念。不知道自己是谁、从哪来、到哪去。有些主机厂习惯从Tier1供应商的角度看汽车，或从云厂商的角度看汽车，还有从硬件厂商的角度看汽车，但是很少从汽车的角度看汽车。也就是说，大部分都没有认识到，汽车架构中最核心的理念其实是做一台好车。

那么，什么样的架构理念才是正确的呢？我们接下来提出定理2：

定理2. 软件定义汽车，服务定义软件

软件定义汽车的概念大家都很清楚，我在此不再赘述。我想指出的是，对于主机厂而言，怎么定义“软件”？很多人讲到软件就想到车内SOA（面向服务的架构）生态，把车内生态和云生态割裂开来。但是，车无法脱离云生态而存在，如果脱离了，那主机厂和代工厂又有什么区别？

那么，如果我们把“车内SOA+云生态”看成一个整体够不够？答案还是不够，因为很多车联功能极度依赖于传统IT系统。例如，用户在提车前需要从移动互联网入口进行用户偏好设置，在这个环节中最大的问题不是车端硬件如何FOTA（无线固件升级），也不是云如何下发，而是制造系统什么时候下发车辆元数据。所以，主机厂需要从全局看待软件，即要站在服务的视角，用服务定义软件。

如何在具体实操层面交付（Delivery）服务定义软件这个理念？我们提出如下定义1：

定义1 SDN（Service Delivery Network）跨多种通信网络（广域网/车内以太网/边缘网络）向车联网中的生产者和消费者提供服务，以及流量路由、车辆元数据、鉴权与熔断等多种基础能力。

SDN是概念上的服务交付网络，其概念有点类似于中台，但又有很大不同。我们常见的中台有数据中台、业务中台、技术中台等，但它们都有一个特点——站在云的角度看待整体业务。而主机厂很多情况下恰恰相反，需要站在端，而且是异构多端的角度梳理业务。

正如图1所示的逻辑图，我们在SDN中用通道链接端和云，站在主机厂的角度定义软件产品，从真正意义上实现软件定义汽车，而非软件嫁接汽车。

图1 用通道链接云和端

进一步地，又该如何定义服务？服务的边界是什么？服务到底是逻辑单元还是物理单元？为此我们提出了定义2：

定义2 服务（Service）是基于逻辑实体（Entity）的部署单元（Deployment Unit），以API的方式对外提供服务，可以跨硬件进行异构计算。

这里首先强调了服务的基石是逻辑实体，如车辆元数据就是个典型的逻辑实体。这里需要注意的是，没有强调逻辑实体的颗粒度，如果要求颗粒度细到不可切分，那么这里的服务就很类似于微服务（Microservices）概念。但在汽车软件中，并不要求所有的服务都有统一的颗粒度，因为同样的逻辑实体在不同硬件和环境下，算力资源和分布式环境各有不同，不适合一刀切。

其次，这里的服务要求以API形式对外提供服务，并且不仅仅通信协议，还可以是Socket接口、RESTful，也可以基于Message broker（消息代理）。但是会要求具备统一的接口Uniform Resource Name、统一的安全机制、基于JSON的数据结构、统一的Error Code。

最后也是最重要的，要求可以跨硬件计算，这是为了边缘计算或者混合云做准备。对于主机厂而言，保证算力的自由调度，将数据搬运到计算节点上是非常关键的一个核心能力，为了达成这个目的，可以采用Docker、WebAssembly等容器技术。

基于容器的混合云模式

混合云策略是将公共云和私有云环境结合在一起，使企业能够将两者的优点结合起来。公有云的优势在于可根据企业需求按需付费、弹性扩展；私有云为企业提供敏感数据的环境隔离，保障企业数据安全。为了有效利用各个云服务厂商网络资源整合、垂直领域发展、流量推广等各方面的优势，也避免被单个云服务厂商深度绑定，企业在公有云的合作上往往会对接多个公有云提供商。

尽管混合云集成了公有云和私有云的优势，但也带来了更多的安全防范成本，云之间的数据交互控制和设计带来了更大异构资源管理的复杂性。仅仅从应用管理的角度来，混合云的背景下，运用容器化技术来实现应用层的抽象，并利用大规模分布式资源和服务管理工具来对接不同的云服务厂商，屏蔽IaaS层的异构性是非常有必要的（见图2）。

图2 混合云架构设计

建立抽象层屏蔽云服务差异:

云服务厂商的Serverless功能，通常以相同的方式工作，具体场景上存在特定的差别。类似Cloud Foundry的BOSH引擎，可以通过建立对IaaS资源的抽象，解耦应用与服务管理层和下层资源管理层的依赖差异。资源抽象层的核心功能有：

对接云服务厂商的云平台接口。通过集成服务厂商的资源管理接口，向上提供统一的资源管理API，屏蔽资源层的异构性。
提供资源运行状态的监视数据，对每个云提供商的VM进行统一的异常检测、自动恢复及告警通知。
提供统一的资源管理入口。对IaaS层资源进行抽象的描述，同时就可以提供统一的资源管理界面和管理API。

基于容器的平台无关性实践:

容器能提供比虚拟机更轻量的隔离技术，类似Docker和Cloud Foundry的Garden。在汽车行业逐步进行以用户为中心的数字化变革背景条件下，一套基于容器化的分布式服务治理体系对车企非常重要，主要体现在以下几个方面：

主流的云服务厂商都支持容器技术。容器技术给车企带来的环境适配性是不可替代的，车企可以集中在自身的业务发展和开发上，无需担心具体云平台的捆绑问题。
容器技术屏蔽了系统环境的差异，使得开发、测试和运维人员仅关注应用和服务的镜像部署、测试和发布，简化了沟通和环境成本。
容器生态系统完善，开放容器倡议（OCI）就制定了关于容器运行环境和容器镜像格式这两个核心部分的规范。

最后，容器技术结合Kubernetes编排工具，可以进一步提高应用的资源利用率，简化部署提升扩展性。

基于容器和微服务的车云协同计算

随着汽车智能化的逐渐推广，汽车已经从单纯的交通工具转变为承担着越来越多功能的载体。如最近比较流行的智能座舱、无人驾驶等概念，不管是智能座舱主打的人机交互体验、实时安全提醒、智能AR导航等功能，还是无人驾驶L2~L5的各项能力，背后都需要众多服务和计算去支撑。是否能够快速将这些服务能力交付给客户使用，就成了一个主机厂需要迫切解决的问题。

对于传统的车辆开发来说，通常都需要一个较长的周期。要将一项功能部署到车辆上，从设计到生产通常需要3~4年的时间，这就导致车辆上的硬件规格相对较为保守。此外，受限于成本和能耗因素，硬件算力可能不足以达到要求，特别是在无人驾驶场景下，需要大量基于计算机视觉或雷达数据的路况实时分析等服务。因此，将这些服务迁移到云端的想法便很自然地产生了。这样不仅可以大幅降低车辆的制造成本，且基于云端高性能、可扩展的计算能力，还可以做很多车端胜任不了的计算任务。

但云端计算存在时延问题。自动驾驶对于智能决策的时延要求非常高，如果移到云端去计算，势必会造成时延的增加，这将带来严重影响。例如，车辆在高速公路上以120公里/小时的速度行驶，每秒钟就能行驶三十多米，时延增大就可能会引发严重的交通事故。由此就出现了为解决时延问题的边缘计算解决方案，即把云端那些计算任务移到路侧的边缘计算平台上来进行，从而辅助车辆进行实时的智能提醒和决策。它带来了三个好处：第一，计算能力大幅提升，有利于提高准确度；第二，不需要占用过多的核心网或骨干网络带宽；第三，可以有效降低时延，车辆通过基站就可以连接路上的终端，缩短了数据传输路径，取消了从互联网到无线核心网再到无线接入网的时间。

这里出现了车、云、边缘计算等多种部署位置。如果为每个场景都单独开发，必然会带来巨大的成本和不便性。因此，通过容器构建一个统一的运行时环境就成了必然选择。一个服务根据场景的需求，可以运行在车、云或边缘节点上，使用统一的技术栈既能减小部署成本，也可以根据实际情况进行调整，为主机厂带来了非常大的发挥空间。

另外，车联网的数据有着数据量大、类型多、速度快等特点，而这些正是微服务架构所擅长的。通过微服务容易水平扩展的特性，可以跨多个服务器和基础架构进行部署，从而很好地支持高并发连接数和高吞吐量的需求。同时，利用微服务架构也能解耦不同业务，降低系统的复杂性，使其更加易于部署。

通过容器和微服务的结合，主机厂可以快速将服务部署到需要的位置上，也能从容面对日益增长的客户数量和需求，由此可见这是一种十分合适的解决方案。

基于吞吐的弹性扩缩容和异地双活

一个车型的销量通常都会经历一段发展过程，如果在开始时建设大量的云基础设施，将会产生巨大的财务成本，基于容器化技术的快速扩容和动态调整可以显著降低成本。例如，在前期车辆数量不多时部署少量容器，在销量扩大后根据实际的吞吐量去部署相应的服务，就可以减少不必要的成本浪费，降低财务压力。

并且，因为容器的创建十分快速，能够根据吞吐量的变化快速扩张或收缩节点的数量，可以更进一步地节约成本。

“以用户为中心”的车企最需要考虑的是云服务的连续性和可用性，体现在技术上就是异地双活。基于Kubernetes管理的容器平台可以通过联邦的管控能力，来达成多机房多地域多集群的单元化架构，在一些复杂的场景中为业务提供统一的发布管控和容灾应急能力。

联邦具有如下特性：

简化管理多个联邦集群的Kubernetes API资源。
在多个集群之间分散工作负载（容器），以提升应用（服务）的可靠性。
在不同集群中，能更快速、更容易地迁移应用（服务）。
跨集群的服务发现，服务可以就近访问，以降低延迟。
实现多云（Multi-cloud）或混合云（Hybird Cloud）的部署。

通过利用这些特性，我们可以协调各集群资源、应用和配置，以实现应用变更管控、分组发布、镜像管理、流量调拨、元数据管理、集群资源管理等功能，从而降低运维成本。但任何技术都不是万能的，这里我们必须认识到几个问题：

异地多活是有成本的，包括开发成本和维护成本。需要实现异地多活的业务越多，投入的设计开发时间也会越多。同时也会提高维护成本，需要更多的机器、带宽。
并非所有业务都一定适用于异地双活，比较典型的有强数据一致性的业务，因为数据同步需要时间，可能出现不一致的问题。

因此，在考虑异地多活时，需要从业务和用户角度出发，识别出核心和关键业务，明确哪些业务是必须实现异地多活，哪些可以不需要异地多活，哪些是不能实现异地多活的。例如“登录”要实现异地多活，“修改用户信息”和“注册”不一定要实现异地多活。

总结

最后，随着技术不断进步，特别是无人驾驶技术逐渐投入使用，汽车行业必然会出现一个大变局。人们在汽车出行上越来越方便，享受越来越多个性化的服务，汽车会从一个单纯的交通工具演变成为人们移动的家。如何快速地为用户提供这些服务成为了主机厂们必须要面对的问题，这也是软件定义汽车的由来。而基于微服务和容器化的车云实践，正是我们通向未来、更贴近用户的一个探索。

—END—

本文出自《新程序员002：新数据库时代&软件定义汽车》，由60余位专家倾力创作。随书附赠《2021数据库全景图V1.0》和《2021汽车技术与产业生态全景图V1.0》，同时内含《2021年度数据库发展研究报告》和《2021年度软件定义汽车研究报告》，图文与视频多媒体呈现。

本书高屋建瓴的产业分析和趋势预判适合中高端从业人员参考决策。同时，多位专家亲历的入门和实践之旅也为初学者提供了可借鉴的专业路径。