基于车联网应用场景架构设计PaaS平台以实现DevOps同行技术探讨经验总结

声明：本文作者为edwin1986，上汽通用汽车 系统架构师。本文已获得授权转载。

一. 前言

眼下大部分车企都承担着自主品牌汽车的研发、制造与销售，在“电动化、网联化、智能化、共享化”的“新四化”趋势下，车企IT平台积极向互联网架构转型，推出了IaaS、PaaS、SaaS服务，适应多元的系统架构以及微服务的开发方式。其中，基于Docker容器技术的PaaS云平台，其建设目标是给企业内部以及合作供应商的开发人员提供一套服务快速开发、部署、运维管理、持续集成、持续部署的平台。平台提供应用运行时、中间件、数据库、信息安全及人工智能等PaaS资源，以及创新性地将公有云PaaS服务资源通过封装API实现私有云快速调用。让开发人员在构建应用过程中，真正实现秒级接入，弹性扩缩，一键部署，资源最大化利用。 车联网TSP平台承载了车辆数据收集和车辆指令下发的重要功能，通过PaaS平台可以解决车辆数据的稳定并发问题，保证车辆数据不堵塞，不丢失。

车企PaaS平台，承载了企业协同平台、B2B、B2C、智能制造等多领域应用，在PaaS平台构建与应用落地推广时，我们发现，对于传统车企数字化转型的的过程中，面对从传统巨石到模块化到微服务的各种架构的应用接入需求，对平台的稳定性、灵活性提出很高要求。因此，在平台构建时，不仅需要满足新框架的快速对接，在暂时无法重构的情况下，老框架的应用也可以通过适当改造接入PaaS服务，以适应业务快速的发展需求。并且，我们还在积极探索kubernetes技术，以及贯彻DevOps理念，提高开发效率，解放运维双手。在此需要和同行多进行沟通，吸取这方面的经验。

为了帮助大家了解如何基于车联网应用场景架构设计PaaS平台以实现DevOps同行技术探讨，社区特别组织了本次交流活动，请大家一起交流探讨。活动中，大家踊跃发言和积极答疑，提出了许多真知灼见。为了更好、更方便的让大家了解到本次交流活动的干货，更好地进行PaaS项目建设，在此我将本次活动的问题和解答进行了总结，如有不妥之处，还请谅解。

二. 基于车联网应用场景架构设计PaaS平台以实现DevOps同行技术探讨在线答疑

1. PaaS技术

Q：PaaS中如何实现服务注册和服务发现？

ASIS： 目前主流开源的服务发现框架包括spring cloud相关、dubbo等。K8S平台运行在其之下，若整合需要定制开发。PCF源生支持Spring Cloud体系。 对于服务发现本身而言k8s使用了服务器端的HA和服务发现而非spring等通过客户端实现的服务发现，这是两种模型。前者通过应用层实现：如springcloud。springcloud中的eureka组件可以向各个微服务提供注册和服务发现的功能。后者在系统层实现：K8S/OpenShift本身自带服务发现机制，其通过DNS域名解析来实现。 TOBE： istio等service mesh是一个方向

Q：如何基于PaaS平台构建上层服务？

用户可以根据需求，可以自行定制构建特定的上层服务。除了上面提到的两种途径外，用户还可以通过使用RedHat开源的Operator Framework项目进行快速定制化开发。

1.CRD (CustomResourceDefinitions) 用户通过使用CRD将定制资源添加的K8S/OpenShift集群中，扩展K8S/OpenShift API。CRD仅定义了某种类型的资源对象，而该资源对象的控制器，则需要用户自行定制开发。 CRD用法可参考：https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/ CRD开发工具框架：https://github.com/kubernetes-sigs/kubebuilder

2.Service Catalog openshift目前支持两种service broker： - template service broker - ansible service broker 用户也可以根据需要定制自己的service broker，目前社区提供Open Service Broker API：https://github.com/openservicebrokerapi/servicebroker

3.Operator Framework Operator利用K8S/OpenShift的扩展性来进一步增强云服务的运维自动化能力，如创建、伸缩、备份与恢复等。根据OpenShift Roadmap中的规划，18年下半年将会推出etcd/prometheus/Vault Operator. https://github.com/operator-framework/operator-sdk

Q：paas如何实现自动扩容？

不同paas会有不同的实现方式，k8s的实现可以参考 水平扩展参考：https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/ 垂直扩展参考：https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#known-limitations-of-the-alpha-version Cluster Auto Scaling 需要依赖下层基础IaaS实现，可参考： https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-autoscaler

Q：gfs和ceph或者其它的， 哪种比较适合容器的数据落地？

如果建设初期，建议使用主机储存和NFS之类的传统网络储存：前者满足高IO需求，后者满足低IO需求 K8S持久化卷的支持情况可以参考K8S官网：https://kubernetes.io/docs/concepts/storage/persistent-volumes/ 多种持久存储使用示例，可以参考OpenShift的官方使用教程： https://docs.openshift.com/container-platform/3.10/install_config/persistent_storage/index.html

从存储选型角度来看，建议用户结合具体的使用场景进行测试，以验证是否满足自身的应用场景需求。 RedHat也推出CNS(Container Native Storage, 容器原生存储)方案,详细内容可以参考：https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.3/html/container-native_storage_for_openshift_container_platform/index

Q：在云架构中 OLAP和OLTP的架构如何建立？

OLAP 能很好的契合云平台，因为 AP 是计算密集性场景，例如使用 Spark 及一些其它 SQL 引擎去做一些 SQL 计算，这类场景特别适合云，特别容器云，对计算资源的更细粒度化，能灵活的弹性扩展，这都是 OLAP 场景所需。 云架构处理 TP，这中 IO 密集型的场景，我建议从以下两个层面去考量： 1) 采用新的持久化产品或架构，例如文件数据库，例如 Couchbase, MongoDB，及一些 In-memory 的方案，例如 Redis 等 2) 采用互联网一些技术，例如使用消息中间件，去保证数据原子性等。

Q：车联网通讯协议的选择？MQTT与HTTPS的优劣势？从未来发展，哪种协议更适合车联网构建？

MQTT 和物联网 (IoT) 联系在一起，MQTT（消息队列遥测传输） 是基于 TCP/IP 协议栈而构建的，已成为 IoT 通信的标准。车联网也是类似的场景，也是选 MQTT 偏多。 MQTT 和 HTTPS 最主要区别在于，MQTT 是异步消息通性机制，HTTPS 是同步请求响应式的机制。车联网这种应用场景，需要处理大量事件消息，MQTT 后端一般都是高性能消息中间件，消息中间件可以有效处理这些消息。如果采用 HTTPS 会有一定的局限性。根据 [1] 链接中描述，这些局限体现在： 1) HTTP 是一种同步协议。客户端需要等待服务器响应。Web 浏览器具有这样的要求，但它的代价是牺牲了可伸缩性。在 IoT 领域，大量设备以及很可能不可靠或高延迟的网络使得同步通信成为问题。异步消息协议更适合 IoT 应用程序。传感器发送读数，让网络确定将其传送到目标设备和服务的最佳路线和时间。 2) HTTP 是单向的。客户端必须发起连接。在 IoT 应用程序中，设备或传感器通常是客户端，这意味着它们无法被动地接收来自网络的命令。 3) HTTP 是一种 1-1 协议。客户端发出请求，服务器进行响应。将消息传送到网络上的所有设备上，不但很困难，而且成本很高，而这是 IoT 应用程序中的一种常见使用情况。 4) HTTP 是一种有许多标头和规则的重量级协议。它不适合受限的网络。 从现在来看建议选择 MQTT。另外 [2] 链接，红帽的 MQ 很好的支持 MQTT，事件流，也可以和容器云集合，是车联网很好的一个选择。 [1] https://www.ibm.com/developerworks/cn/iot/iot-mqtt-why-good-for-iot/index.html [2] https://www.redhat.com/en/technologies/jboss-middleware/amq

Q：PaaS云平台架构设计？如何搭建好微服务架构、Docker容器技术、DevOps，设计和实施时需要注意哪些要点？

微服务、DevOps、Docker相关PaaS三者逻辑可以分开建设 1) 微服务：首先考虑必要性，灵活度需求和开发团队成熟度需求真是否到了需要微服务化的地步。始终觉得，无状态服务是必要的，但微服务不是必要的。 2) DevOps：同样存在成熟度陷阱。首先CI/CD做好了么？CD部分生产切换灰度等方案完善了么？传统针对VM同样可以通过定义模型和脚本进行与容器类似的自动化批量部署。 3) Docker：与2有点类似，只是通过更加方便的手段来构建黑盒。与1中的无状态性比较相关（有状态应用你可以通过Stateful相关容器实现，但是我始终觉得这违背了容器的初衷）。但需要注意平台构建对于下层计算资源和网络的要求。 另外，要做好日志收集和监控。因为PaaS上的应用都是基于容器来运行的，而且都是多个节点运行，这就造成了获取日志文件的难度。很多情况下，如果系统有报错，需要调阅日志文件的时候，不知道取哪个容器里面的日志。目前我们是基于fluentd+elasticsearch(hdfs)+kibana的方式来进行日志收集。fluentd负责收集容器日志并上送到elasticsearch以及hdfs里面（HDFS主要是做日志持久化存储便于后续审计），elasticsearch里面的日志只保留7天。Kibana用于日志的检索和可视化。 对于监控平台，我们使用了heapster+influxdb+grafana的技术栈。heapster用于收集节点cAdvisor上的监控指标，上送到influxdb，由Grafana查询influxdb做可视化展现和监控预警。

Q：在云环境下，如何将openstack和openshift进行整合，并统一管理，分配资源？

推荐红帽和 Intel 联合推出的开源云解决方案，主要围绕的是 OpenShift on OpenStack, 可以参照如下链接：http://ksoong.org/cloud-labs/content/ 进行统一整合、管理、资源分配是有方法的，首先 OpenShift 和 OpenStack 都是红帽主导的产品，在红帽内部，这两各产品都属于云设施 BU。

存储，网络等可以很好的整合，另外，CloudForms 是一款全面的 IaaS 云和 PaaS云的混合云管理平台，提供适用于虚拟环境和云基础架构的自助服务，同时保持安全及合规性。可以去做一些集中管理的方案。

Q：如何降低PaaS的学习和使用成本？

PaaS是一个企业级平台，K8S是平台中的一个核心组件。 从学习和使用角度来看，用户不仅要理解K8S的原理与机制，还需要深入学习存储、网络、日志、监控等多种组件，成本相对较高。如果PaaS平台产品的供应商能够提供详细的培训/知识转移计划，相对来说，效果会好很多。

以OpenShift这样的PaaS平台为例，从前期规划开始，RedHat就会提供详细的技术培训计划，随着项目交付的推进，相应的培训课程也会一并开展，最终实现用户可以自行维护使用PaaS平台，并且有能力向其它业务部门提供技术培训。

2. DevOps与敏捷组织

Q：基于openshift的容器方案，如何将CICD落地以及应用场景主要有哪些？基于openshift的容器解决方案，如何将CICD落地？openshift的容器方案现在哪些车企有落地？应用的场景主要是在车联网么？应用的效果如何？ 关于CICD落地，包含以下两个部分:

• 工具 OpenShift自带CICD功能，具体实现由jenkins来完成，其中RedHat开发了一些Jenkins插件进行辅助集成，OpenShift也可以直接集成用户现有环境中Jenkins工具。
• 针对应用的CICD流程落地 通常，RedHat会和运维开发团队讨论某个具体应用的CICD流程，确定最终的方案，然后开发相应流水线的脚本(groovy/shell)，接着进行测试验证。 应用上PaaS平台的流程可以参考下面的框图

CICD具体流程可参考下图:

CICD的效果图:

Q：微服务和soa架构在企业应用实践及未来趋势？微服务和soa架构适合哪些企业应用场景？将来微服务会代替soa吗？

微服务和 SOA 是有一定联系的，他们的核心思想是相通的，例如微服务和 SOA目的都是：

• 松散耦合能力
• 分布式能力
• 服务重用的能力

微服务跟强调的是服务，通过一系列松散耦合的服务去实现满足业务需求的应用，目的是将大的、复杂的应用通过CI/CD、DevOps 等方式去管理维护，极大的缩短了复杂应用从开发到部署的时间（数量级）。

SOA 理论层面也讲面向服务架构，但在实践中都进行的是面向系统的整合，或集成的方向，所以可以说 SOA 强调的系统。

关于未来，新的架构会成为必然，根据某咨询公司的调研结果，目前以及有 50% 的应用采用新的，轻量级、互联网化、微服务化的架构，如下图：

Q：不是微服架构的应用采用容器部署的方式有那些实际意义？

可以获得以下3点好处：

1、提高资源的使用效率。例如传统安装了WebSphere的4C8G配置的Linux虚拟机，在生产环境下，最多也就部署4、5个应用。但是同样配置的虚拟机，可以跑10个左右的容器。这样就大大提高了资源使用效率。

2、环境的隔离。在Docker容器内跑的应用，我们会将中间件和应用版本构建到一个镜像里面去，这样就将应用与外界环境 做了隔离，可以做到应用之间互不影响。例如，假设一个安装在传统虚拟机和WebShere中间件上的应用，如果需要JVM虚拟机的字符集是GBK的话，那么这个WebSphere上运行的其他应用也需要以GBK作为字符集，这样就导致应用之间强耦合。如果采用容器方式部署的话，就不存在这个问题。

3、对应用而言容器定义了一种新的黑盒交付模式。

Q：现有的应用不是微服架构有必要做改造吗？

微服务，在互联网企业甚至传统行业移动端业务得到大规模采用，已然成为主流的应用架构。

微服务旨在帮助组织实现两个基本目标 - 敏捷性和规模 - 因此首先要评估组织的需求。

1) 敏捷性：笨重单一的应用程序或ESB基础架构可能需要长达数个月的部署时间，从而导致冗长的发布周期，阻碍组织跟上市场需求的能力。在构建、部署、扩展和管理各个服务时，微服务可以使您转向更灵活的持续交付环境。

2) 规模：对于希望更有效地利用现有硬件资源的组织，微服务可通过容器化提高计算密度。另一个可扩展性要求可能是快速弹性以适应峰值负载并在非高峰时刻减少资源 - 例如，亚马逊能够处理各种促销活动的购买量或Netflix在新节目发布时处理流量的能力。随着组织的扩展，一致的性能是另一个特别关键的需求。如果您需要更新应用程序的某些部分，微服务架构可实现独立部署和扩展，而不会影响应用程序的其余部分。 如果有敏捷性或者业务规模扩展的需求，建议对现有应用进行微服务化改造。同时随着微服务架构的落地，DevOps将会成为加速业务价值流动的重要一环。

Q：车联网paas一定要采用devops吗？优势是什么？

没有必然联系。

paas是弥补传统开发到中间件平台的gap，并一定意义上提升组织的能效。其一个技术架构，狭义地讲就是容器云。因为如果应用是通过容器镜像来发布的话，就是将中间件和应用程序一起打成镜像来发布，这就意味这开发人员在构建镜像的过程中其实就是做了运维人员的一些工作。另外容器云还提供对容器行编排调度，动态扩容等等功能。这两个容器云的特性在一定程度上大大减少了运维人员的工作量。所以说基于PaaS云平台的组织，很容易搞DevOps。

devops解决的是敏捷组织持续开发持续交付的演进过程，解决的是业务交付效率和开发团队成熟度问题。其是组织内部解决开发人员和运维人员之间鸿沟的一种方法，所倡导的是开发人员向后走一步，多往运维方向考虑一下，运维人员向前走一步，多往开发方向想一下，最终目的是实现开发和运维水乳交融，提高组织的效率。

Q：如何基于paas云实现持续交付？

持续交付之所以困难，不仅仅是在技术上，更主要在制度上。特别是我们这种金融企业，对变更非常谨慎，审核非常严格。并且我们的开发测试环境跟生产环境在网络上是隔离的，这就进一步增加了版本从开发测试环境交付到生产环境的难度。因为这些原因，我们必须设计一套完整、成熟、经得住推敲的持续交付流程，才能够说服质量监督和生产安全部门在企业内部推行持续交付。

基于PaaS的持续交付，其实就是两样东西在三套环境之间的同步。三套环境很好理解，就是开发环境、测试环境、生产环境。有些公司可能还有预投产环境。两样东西指的是镜像仓库里的镜像，策略仓库里的容器编排策略。我们企业内部的镜像仓库使用的是VMware提供的开源企业级镜像仓库Harbor。Harbor提供了镜像的同步策略配置，可以很好地帮助我们实现镜像仓库之间的同步。对于容器编排策略的同步，我们使用自研的PaaS云管理控制台来完成不同环境之间的策略同步。当开发环境发起策略同步申请到测试环境时，开发环境的管理控制台会将编排策略导出一个zip包，以FTP的形式上传到测试环境管理控制台，并给相应的测试人员发送通知邮件。测试人员登录测试环境管理控制台后，首先将策略包导入，之后进行审核以及修改参数等等，审核通过后，就可以一键在测试环境部署这个容器编排策略。如果这个策略之前在测试环境已经存在，本次只是对原有策略的更新，那么管理控制台会比较本次提交的策略和已有策略的不同，并将不同之处提示给测试人员。并且在这种情况下，运行这个策略的时候，在K8S集群里面就不是创建一个Deployment，而是基于原有的Deployment进行Rolling Update。

对于生产环境，根据制度的需要，我们采用了双人复核的机制。当策略包由测试环境提交到生产环境的管理控制台以后，首先由QA人员审核，QA审核通过后，就意味着发布版本，之后再由运维人员复核，并修改相应的生产参数，审核通过后，就可以部署运行。同样如果提交部署的策略已经存在，为了保证生产上运行的应用服务不间断，在K8S集群里面就不是创建一个Deployment，而是基于原有的Deployment进行Rolling Update。

3. 平台管理

Q：应用上openshift容器云平台后，开发和运维的工作模式会发生改变，当前的人员组织架构是否要同步进行调整？

应用上OpenShift容器云平台后，在 DevOps 流程自动化程度上有一定的提高，确实会带来组织形式的变化。常见的有两种形式： - 构建虚拟化团队，由运维、开发、业务等团队的成员参与组建。 - 组建实体运维团队，专门负责PaaS平台的事务，对企业内部业务开发团队提供统一的支持服务。 细节可参考：http://v1.uncontained.io/playbooks/fundamentals/openshift_roles_responsibilities.html

Q：私有云平台建设中，平台主机的生命周期是如何评判的？是否有标准？标准参考的对象是什么？

服务器生命周期管理涵盖了计算能力的规划，交付，运营和淘汰四个阶段。 由于服务器generation更新导致计算力有较大提升，故对早期generation的MA总会平衡其计算力和成本。 一般根据generation进行定义和淘汰，一般结合实际情况，生命周期在5-7年左右。当然，无论是VM还是Docker的虚拟化，通过自动化的运维手段定义，使得底层计算资源更新已经对应用几乎透明。

Q：云平台和物理机哪个性价比好，方便管理？包括费用对比、后期管理费用对比、管理难度、故障率、操作难度

可以探讨下裸金属和VM构建的差异点： • 性能损失。我记得早期测试过，容器化本身性能基本无损失，hypervisor好像在20%左右。 • 场景。考虑到大部分java应用使用jdk8以下版本，容器化是高内存低CPU占用。如何提高宿主机资源使用率？ • 管理复杂度：本质上是VM和bare metal的差异。但需要注意2点：1.容器的无状态性导致和主机基本无关联性。2.集群主节点可用性和快速恢复。

Q：车联网应用场景下，云架构如何设计？传统IDC应用中容易以下问题：

1.服务器扩展性差，假如新增车联网用户200万，服务器扩展周期长。 2. 运维不灵活。 3. 信息安全无法保障，管理人员数目增多，潜在人为因素增大。 4.车辆行驶的场景对动态网络要求较高，传统 IDC 无法实时支持对网络的动态调整。 车联网应用场景下，云架构如何构建，能否解决上述问题。

不管是传统的“云”还是现在所谓的cloud native，本质上是将传统软件开发和基础平台的gap通过新的技术手段给弥补起来，但对于本身的体量问题，比如inbound/outbound流量，架构只能解决更好的利用率问题，但如果利用率达到极限，还是需要通过外部扩展/公有云等方式解决。 因此对于问题1，现在的思路是通过无状态应用提升横向扩展水平；通过资源利用率的提升，节省一部分成本。 问题2，可以通过自动化运维手段配合CI/CD持续改善。 问题3，在组织内部，需要有专业的安全小组定义high level要求和纲要。在服务设计阶段，需要有安全层面需求和要求定义。服务运营阶段，需要有自动化的安全扫描工具和手工化的外部安全审计等方式确保目标不偏离。 问题4，规模效应的问题。建议区分场景，哪些数据可以从公有云走，再异步回主机厂；哪些不能走公有云。

Q：几种容器编排工具中Kubernetes，Swarm和Mesos，哪个较好，如何选择？国内有什么好的容器调度引擎？有推荐的定制化解决方案？

Kubernetes 现在成为事实上的标准，现在市场关注的焦点在于，谁能提供跟好的 Kubernetes 企业级支持，谁能帮助企业跟好的落地 Kubernetes 平台。 关于 Kubernetes 和 Mesos 的各方面的对比，可以参照下图：