apollo

CI与CD之Docker上安装Jenkins

巧了我就是萌 提交于 2020-11-23 05:43:08
一.CI,CD,Jenkins的介绍 CI:持续集成(Continuous integration,简称 CI),在传统的软件开发环境中,有集成,但是没有持续集成这种说法,长时间的分支与主干脱离,导致分支与主干可能存在较大偏差,在集成代码的时候可能需要花费数小时更久的时间来修复代码,以便最终将代码集成主干(俗称"集成地狱"或"集成灾难");而CI旨在鼓励团队成员进行频繁集成(例如每小时或至少每天一次 ) 来避免这种情况的出现,通过自动检测、拉取、构建和(在大多数情况下)进行单元测试的过程,来保障代码的质量可以进行下一步的使用,这也是持续集成的目的,CI是属于开发人员的自动化流程。 CD:持续交付(Continuous Delivery)和持续部署(Continuous Deployment),这里查阅了一些资料,并简单总结了一下:      1.持续交付意味着所有的变更都可以随时交付生产使用,强调的是一种可交付的能力   2.持续部署意味着所有被发现的release candidate 并且通过所有质量测试的变更都会被自动部署到生产环境中,强调的是一种方式 Jenkins:Jenkins是开源CI&CD软件领导者,并拥有众多插件来支持它用于持续、自动的构建/测试软件项目、监控外部任务的运行 二.在docker上安装Jenkins 选择jenkins的镜像文件

ESD-CAN安装调试笔记

孤者浪人 提交于 2020-11-06 06:27:58
方法一 编译带ESD-CAN的Apollo-RT-Kernel 该方法是将原生的Linux内核(linux-4.4.32)打上esdcan的补丁(esdcan_patch),然后使用apollo提供的build.sh 脚本编译成实时内核。下面具体介绍操作步骤。 下载apollo-kernel,命令如下: git clone https://github.com/ApolloAuto/apollo-kernel.git 内核文件准备工作 下载Linux内核 点击该链接即可下载: Linux Kernel 4.4.32 tar zxvf linux-4.4.32.tar.gz 将解压后目录下的所有文件copy到 apollo-kernel/linux路径下。你会发现在linux/drivers/路径中没有esdcan的目录。所有的内核驱动都是在其根目录drivers下的,esdcan驱动不是linux支持的,因此没有其源代码。 打esdcan的补丁 在 ~/apollo-kernel/linux/patches路径下,将文件esdcan.patch复制到linux目录中。 在linux目录下,执行如下命令进行打补丁操作: patch -p1 < esdcan.patch 此时查看./drivers/路径 ,发现esdcan目录已经存在。 根据你选用的ESD-CAN卡型号

金丝雀发布、滚动发布、蓝绿发布到底有什么差别?关键点是什么?

北战南征 提交于 2020-11-02 17:06:12
根据 2017 年的 DevOps 发展报告,高效能组织和低效能组织在软件交付的效率上有数量级上的差异。技术组织的软件交付能力是一种综合能力,涉及众多环节,其中发布是尤为重要的环节。 作为技术人员,大家可能听说过“滚动发布”和“蓝绿发布”等术语,但是很多人并不清楚这些术语背后的原理。本文试图总结当前主流的发布策略,每个的优劣,适用性,让开发人员特别是架构师对现代发布技术有一个更为清晰全面的认识,让大家能够根据自己的企业上下文,对发布策略做出正确的选型和实践。 一、单服务器组发布 先解释下单服务器组的概念,早先我们机器资源比较紧张,不像现在云计算和虚拟化(包括容器技术)这么发达,所以应用机器基本是预先静态分配好的(一般由运维负责分配),原来应用 A 住在这 n 台机器上,那么下次升级发布的应用 A 也住在这 n 台机器上,所以称为单服务器组发布方式。 1.1 蛮力发布 如下图所示,这种发布方式比较简单粗暴,有点像我们传统的软件升级方式,主要靠手工完成,先将老版本 V1 全部下掉,再将新版本发到机器上去。这种方式会引入服务中断(停机),在开发测试环境是可行的,但对于生产环境发布,其会直接影响用户的使用体验,这种方式一般是不建议的。 发布前 发布后 优势和适用场合 优势: 简单成本低 不足: 服务中断用户受影响,出了问题回退也慢 适用场合: 开发测试环境 非关键应用(用户影响面小)

Waymo首发最详自动驾驶报告,500年驾龄老司机如何炼成?

僤鯓⒐⒋嵵緔 提交于 2020-11-01 09:59:12
  作为自动驾驶领域的领跑者,Waymo 又开了一个先例。   美东时间 10 月 30 日, Waymo 首次公开披露了其在凤凰城运营自动驾驶汽车的里程和碰撞数据, 有成绩也有不足。    报告传送门 : https://waymo.com/safety   报告称,自 2009 年以来,Waymo 自动驾驶车辆已在现实道路上行驶了超过 2000 万英里,最新报告分析的这部分,则是 2019 年 1 月~2020 年 9 月期间的测试数据,期间共发生了 18 起真实撞车事故。   目前,很多在搞自动驾驶的公司可能都在努力创造一个“黑匣子”,对可衡量的指标都有严格限制,并且仅在最受控制的环境下向公众展示其技术领先性、跑了多少里程、拿了多少牌照,很少自曝短板。但这份报告开始直面问题,详细披露了自动驾驶汽车在现实生活中的情况。   自 2016 年 Waymo 从 Google 分离出来独立运营开始,常规操作都是通过新闻稿来传达其自动驾驶计划,但在新闻中很少揭示有关自动驾驶的实际细节,通常只披露少量阶段性数据。2020 年 10 月初,Waymo 已向更多公众开放了其完全无人驾驶的汽车出行服务,以前,只允许少数人参加。    此次进行详细报告,Waymo 表示其意图是建立公众对自动驾驶汽车技术的信任,但是这些研究也对其他竞争对手的技术细节披露提出挑战。    Waymo 安全负责人马修

自动驾驶汽车硬件系统概述

筅森魡賤 提交于 2020-10-31 06:22:44
如果说人工智能技术将是自动驾驶汽车的大脑,那么硬件系统就是它的神经与四肢。从自动驾驶汽车周边环境信息的采集、传导、处理、反应再到各种复杂情景的解析,硬件系统的构造与升级对于自动驾驶汽车至关重要。 自动驾驶汽车硬件系统概述 今天,我将从五个方面为大家做自动驾驶汽车硬件系统概述的内容分享,希望大家可以通过我的分享,对硬件系统的基础有个全面的了解: 一、自动驾驶系统的硬件架构 二、自动驾驶的传感器 三、自动驾驶传感器的产品定义 四、自动驾驶的大脑 五、自动驾驶汽车的线控系统 1 自动驾驶系统的硬件架构 就整体而言,汽车是个全社会化管理的产品,其固有的行业特点是相对保守的。在人工智能的大潮下,面对造车新势力和消费者需求变化的冲击,传统汽车行业渐进式的创新方法已经面临巨大的挑战。急需改变传统的架构和方法不断创新。自动驾驶整体的硬件架构不光要考虑系统本身也要考虑人的因素。 自动驾驶系统主要包含三个部分: 感知、决策、控制 。 从整个硬件的架构上也要充分考虑系统感知、决策、控制的功能要求。整体设计和生产上要符合相关车规级标准,如ISO26262、AECQ-100、TS16949等相关认证和标准。目前L1、L2、ADAS系统的硬件架构体系和供应链相对完善符合车规级要求。 感知层: 依赖大量传感器的数据,分为 车辆运动、环境感知、驾驶员检测 三大类。 车辆运动传感器 :

简单易用的微服务聚合网关首选:Fizz Gateway安装教程

最后都变了- 提交于 2020-10-30 17:04:23
Fizz 网关简介 Fizz Gateway 是一个基于 Java开发的微服务网关,能够实现热服务编排、自动授权选择、线上服务脚本编码、在线测试、高性能路由、API审核管理等目的,拥有强大的自定义插件系统可以自行扩展,并且提供友好的图形化配置界面,能够快速帮助企业进行API服务治理、减少中间层胶水代码以及降低编码投入、提高 API 服务的稳定性和安全性。 整体架构 Fizz网关的核心处理流程如上图, 收到客户端的请求后会经过一系列内置或自定义的过滤器,接着网关会自动判断当前请求的接口是否是服务编排接口,如果是服务编排接口就根据配置文件创建一个pipeline,在服务编排的pipeline里可以实现接口的串联或并联调用,可以对输入和输出的内容做数据转换,字段映射,脚本处理等操作;如果不是服务编排接口则直接反向代理到后端服务,最后把响应结果返回给客户端。 主要功能特性 - 集群管理:Fizz网关节点是无状态的,配置信息自动同步,支持节点水平拓展和多集群部署。 - 服务编排:支持热服务编排能力,支持前后端编码,随时随地更新API。 - 负载均衡:支持round-robin负载均衡。 - 服务发现:支持从Eureka注册中心发现后端服务器。 - 配置中心:支持接入apollo配置中心。 - HTTP反向代理:隐藏真实后端服务,支持 Rest API反向代理。 - 访问策略

第十三篇 : SpringBoot 整合 apollo

只愿长相守 提交于 2020-10-28 03:53:39
简介 Apollo(阿波罗)是携程框架部门研发的分布式配置中心,能够集中化管理应用不同环境、不同集群的配置,配置修改后能够实时推送到应用端,并且具备规范的权限、流程治理等特性,适用于微服务配置管理场景。 Apollo和Spring Cloud Config对比 通过对比,可以看出,生成环境中 Apollo 相比 Spring Cloud Config 更具有优势一些。 安装 Apollo 配置中心 搭建教程 参照 https://github.com/ctripcorp/apollo/wiki/Quick-Start 搭建 Apollo 配置中心,文档写的很清楚,这里就赘述了。 查看样例配置 搭建完成并启动后,访问 http://localhost:8070 ,界面如下。 输入用户名 apollo,密码 admin 后登录后,点击SampleApp进入配置界面。 与 Spring Boot 整合使用 创建一个springboot项目,主要代码如下。 pom.xml 添加 Apollo 客户端的依赖,为了编码方便引入commons-lang3。 < dependency > < groupId > com.ctrip.framework.apollo </ groupId > < artifactId > apollo-client </ artifactId > < version