FOTA技术专栏—云原生之微服务

FOTA的技术演进，往往聚焦于车端的电子电气架构、诊断刷写方式、AB升级、差分升级等方面，目的以减少升级时间、提高升级稳定性和成功率。然而，FOTA作为一个云管端的应用，伴随着OTA业务场景的逐渐丰富，车厂对于FOTA云端亦存在敏捷开发、快速迭代、弹性计算等需求，以便满足FOTA平台的可操作性、灵活性等特点。

云原生（Cloud Native）是目前流行的，基于微服务、容器、DevOps等技术设计的产品体系。微服务和容器构成了云原生应用架构的基础思想，微服务偏向于解决开发问题，容器偏向于运维问题。云原生的快速发展也开始潜移默化影响各车联网系统。

本文主要介绍云原生中的微服务架构。

01云原生简述

首先了解云原生应用的构建思路以及优势。云原生旨在设计专用于在云端运行的应用，易于维护和开发，具备弹性扩展能力。与云原生系统相对的是以物理机房服务器为基础建设的传统系统。

云原生应用一般具有如下的特点。

（1）开发敏捷。随着公司业务逐渐庞大，开发团队人员日趋增长，需要按一定颗粒度拆分服务，保持服务独立运行和扩展，并支持多语言跨团队的协作开发。

（2）易于扩展。具备良好的跨平台可移植性，可动态弹性在云端扩展服务。

（3）自我修复。服务宕机可自动修复或重启服务，保持对外的高可用，无需人工处理。

（4）自动化部署。支持业务持续交付和自动化部署，减少人工参与。

（5）热部署。支持不停机热部署，避免服务出现不可用的场景。

云原生应用可以为企业在私有云、公有云和混合云中提供一致的体验，利用响应迅捷、可靠、可扩展的云原生应用，充分发挥云计算的优势。

02微服务的演进过程

微服务云原生应用架构的核心，其将应用分解为多项独立服务，并支持 DevOps，提供出色的灵活性和更高的可扩展性。

应用的发展，以业务的规模度量，一般会经历如下几个阶段。

一、单体架构阶段

一般在业务的最初始阶段，可考虑采用传统的单体应用架构。传统的单体架构服务开发完成后，打包并部署为一个Web应用便可对外提供服务，应用的打包和部署方式则依赖于编程语言和框架的选择。例如用Java语言开发的的应用，可打包为jar包，在Web服务器上运行java –jar指令即启动服务。单体应用的优势在于运维简易，只需管理迭代单一服务。例如OTA初期的DEMO或者给甲方爸爸的展示版本，简化了开发流程，以最快的速度部署上线。

应用体量较小的时候，采用单体应用效率较高。随着业务规模和复杂度提升而，单体架构会产生下述一些问题。

（1）运维困难。业务的快速增长导致代码量直线上升，增大了团队开发的二次开发和维护的难度。

（2）可用性降低。庞大的单体应用启动时间慢，运行时崩溃或宕机会导致应用整体下线。

（3）扩展性变差。对于水平扩展的场景，需重复部署所有的服务代码，不仅浪费资源，同时难以进行分布式管理。

（4）不兼容新技术。单体应用仅能实现单一语言开发。例如JAVA开发的单体应用，由于JVM仅能编译JAVA，无法加入其他语言开发的业务代码。

二、SOA架构阶段

随着单体应用逐渐发展，势必对应用进行拆分。同时企业的发展会孕育出多种异构化应用，如企业传统的SAP、ERP系统与真正的业务系统往往是由不同语言、架构、接口风格开发，在打通各系统交互时困难重重。此时便可考虑采用面向服务的架构架构。面向服务的架构（Service-Oriented Architecture，SOA）是一种架构设计理念，以一定的颗粒度划分服务，通过规范化接口重复使用组件。

传统的SOA架构方案以企业服务总线（Enterprise Service Bus，ESB）为基础，ESB通过标准网络协议开放服务接口以发送请求或访问数据，实现与各种系统间的协议转换、数据转换、透明的动态路由等功能。SOA架构需要集成独立部署和维护的通信中间件服务，各个服务是相互独立运行的，通过ESB减少各个服务间的依赖和互相影响，实现了服务的松耦合。

SOA的应用对象为庞大、复杂、异构的企业级系统之间的兼容和重用。大部分企业系统会经历多个发展阶段，各服务迥然不同的技术选型、通信方式以及开发团队，随着时间推移会导致多样化的异构服务，无法大规模的优化和重构，只能采用兼容的方式进行处理，而ESB犹如一个润滑剂，实现了各服务的兼容。

ESB虽然功能强大，但ESB本身为重量级的实现，随着协议种类增多，要完成大量协议和数据格式的转换，计算性能开销较大，在某些场景下ESB自身会成为性能瓶颈。

三、微服务阶段

微服务可以解决单体应用和SOA架构产生的问题。微服务架构是当今互联网流行的架构风格，将系统业务功能垂直拆分为更细粒度的服务，每个服务通过Restful接口对外提供API，微服务的服务们之间亦通过Rest接口通信。微服务的理念要求快速交付，因而对开发流程、自动化部署方面的拥有更高的要求。

微服务适合于当下轻量级、迭代频繁、多种设备访问基于 Web 的互联网系统，这类系统业务变化快，需要敏捷开发和快速交付。

下图为微服务架构在FOTA应用的示例，以此为例了解微服务的架构设计方式。FOTA的微服务同样以业务垂直划分服务的粒度，如车辆管理服务、策略任务服务、数据统计服务、主数据同步服务等。各服务对外通过Restful风格的接口通信。

手机、PC等设备首先接入API网关，通过API网关实现负载均衡、服务路由等功能。服务发现模块负责服务的注册、健康检查、服务提供和服务消费。可将其想象为电话时代的黄页，记录着各服务的“联系方式”。

各服务向注册中心注册，注册中⼼存储各服务的地址信息、属性信息等，当服务消费者调用其他服务时，地址信息由服务注册中心提供，调用者自身无需知道被调用服务的部署信息，实现了透明化路由。分布式管理则可以保证服务数据的一致性，实现节点发现、监控、选举等功能。统一的配置中心可以进行配置的读取和推送操作，进而实现服务在不停机即可修改配置。

03微服务的架构分析

微服务的优势可从技术框架和开发流程两方面进行分析，具有如下的特点。

（1）技术选型灵活。微服务架构下，各服务只要遵守约定的接口规范，即可自由选择开发语言和框架。例如云端最流行的开发语言是JAVA，但由于JVM的对内存和计算资源的占用，在某些多线程的业务场景下，使用Go语言能够提高服务的执行效率。

（2）可独立部署。每一个微服务都拥有独立进程。发布新版本时无需编译打包整个应用，不仅节约资源、缩短发布流程和交付周期，并降低了正式环境的发版风险。

（3）易于扩展。在业务需要水平扩展时，仅需复制小粒度的微服务至其他节点，并通过微服务的服务治理对扩展服务进行负载均衡，体现了极强的弹性和灵活性。

（4）容错度高。更细的服务颗粒度划分，使得某一组件发生故障或宕机时的影响面控制到最小。其他服务可通过重试、容错机制保护整个系统的稳定运行。

（5）跨团队开发。一个微服务可专注单一功能，通过良好的接口定义划分业务的边界。简化了跨语言跨团队的合作开发。同时由于服务规模小，更易维护。

当然也不存在万能的架构，微服务在解决单体架构矛盾的同时引入了新问题。首当其冲的是服务的依赖关系导致服务部署和测试的复杂度上升，增加了运维和测试工程师的工作难度。其次，微服务架构增加了分布式系统的管理难度，对分布式事务管理提出了更高的要求。

04SOA与微服务的对比

SOA和微服务有相似性，但在细节上大相径庭，下表为两者之间的对比总结。

05FOTA的微服务应用展望

FOTA业务在车厂受到愈发的重视，适配车型和业务场景也在加速丰富的进程中，使得FOTA系统更复杂，快速迭代的需求却更为紧迫。车厂迫切希望加速系统开发和部署的周期，同时降低成本。微服务在互联网行业的推进，其架构理念已经得到行业的广泛认可，在当前的背景下，FOTA应用微服务架构是利大于弊的。

首先，随着微服务推进，FOTA业务部署块粒度变细，可降低资源成本。例如对于车辆和零件的属性配置信息，拆分成独立服务后，可将服务提供给更多的相关业务，如远程诊断服务、数据采集服务等。这些服务的基础数据可复用该微服务。

其次，FOTA业务的逐渐庞大，避免不了跨团队的开发方式，微服务架构划分出了清晰的业务边界，让开发过程更敏捷，减少了模糊地带的扯皮行为。同时，对于FOTA数据统计模块，可灵活选型，譬如选择数据统计更强的python相关框架。

往后几期我们将会介绍微服务服务治理、分布式管理的相关技术内容，敬请期待。