《2022年机器人也上云-创业团队的阿里云实践心得 .docx》由会员分享，可在线阅读，更多相关《2022年机器人也上云-创业团队的阿里云实践心得 .docx（40页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、精选学习资料 - - - - - - - - - 机器人也上云 -创业团队的阿里云实践心得本文章来自于阿里云云栖社区摘要： 机器人也上云 想到机器人,信任许多人会联想到斯瓦辛格主演的终结 者系列电影；那部系列片里描画了完全存在于云端的人工智能“ SkyNet”；从科 幻小说,到科幻电影, 到真正的科技实践中, 云运算都是解决包括人工智能在内 的机器人相关技术的关键和基础；机器人也上云想到机器人,信任许多人会联想到斯瓦辛格主演的终结者系列电影；那部系列片里描画了完全存在于云端的人工智能“ SkyNet”；从科幻小说,到科幻电影,到真正的科技实践中, 云运算都是解决包括人工智能在内的机器人相关技术
2、的关 键和基础；我们是一个负责实施机器人Pepper 本地化的创业小团队,我们挑选阿里云全面部署我们的业务,成了自然而然的挑选；但是,到底如何使用云运算,或者说 怎么让 “机器人上云 ”,我们仍是做了不少工程思想和技术应用上的小革新的；项目背景我们是一个标准意义上的创业团队；人员不富有, 项目很紧急等等但凡创业团队会遇到的问题,我们都有遇到；挑选云运算在某种意义上,是快速搭建业务,技术性回避创业团队人员匮乏劣势的一个最正确挑选；事实上, 我们至今为止, 整个平台开发团队负责全部云上业务的团队 仍是一个 10 人以下规模的小团队；而我们需要面对的项目, 包括短期内搭建多环境架构的研发体系、建立基
3、本业务平台、内部运营平台、基础数据平台、海外 等十数个大小项目；AWS Base 的服务平台的整体迁移名师归纳总结 - - - - - - -第 1 页,共 21 页精选学习资料 - - - - - - - - - 在这些项目中, 最能表达使用阿里云运算所带来的效率最大化、可用性最优的项目是多环境网络架构和 关内容；网络架构AWS 服务整体迁移两项；本文将侧重介绍这两方面相俗语说,麻雀虽小五脏俱全； 假如需要以工程化的要求来进行团队合作开发,一些标准的工程环境是必不行少的；众所周知, 一般的在线工程环境包括： 测试环境 QA、预发布环境 Staging 、生产环境 Production 三大部
4、分；我们名师归纳总结 - - - - - - -第 2 页,共 21 页精选学习资料 - - - - - - - - - 在阿里云上完整构建了上述环境,下面是整体网络的一个概览图：1. 测试环境：测试环境是一个独立的VPC ,拥有独立的配属于测试环境的一级域名只做VPC 内解析,不做公网解析、内网 DNS、中间件和阿里云基础服务；为了测试环境的安全和日常使用的便利,我们通过 办公网络,后续视业务房展会考虑专线接入；OpenVPN 打通测试环境和名师归纳总结 - - - - - - -第 3 页,共 21 页精选学习资料 - - - - - - - - - 2. 预发布环境：预发布环境和线上环境
5、同属于一个VPC,公用同一套阿里云基础服务,但是DNS 、配置中心和中间件是独立的；预发布环境的域名和线上保持一样,测试验证的时候需要手动绑定 环境的高度一样；3. 生产环境：或者使用 ,这样做是为了尽量保持预发布环境和生产在生产环境中,我们除了使用了包括负载均衡、容器服务、RDS 等大量的阿里云基础服务之外, 仍基于云监控和 章节；4. API 网关：ELK 构建了我们的监控系统, 详见监控方案由于我们整体使用了前后端别离的架构,在我们的网络架构里仍有一个特点是基于 Zuul 搭建了一套 API 网关；定义了统一的前后端交互协议,包括采纳 JWT 协议来鉴权,以 RESTful 风格作为接口
6、标准等等；Docker 容器服务实践近年来 Docker 已然成为了DevOps 圈里的大热门； 作为一个自认为追求效率的小而美的团队, 响应热点明显不是我们的目的,真正帮忙到团队、 能够提升生产效率,才是我们挑选这一技术的根本缘由；为什么挑选 Docker 1. 契机在为我们的项目做技术选型的时候,适逢阿里云容器服务上线, 我们发觉阿里云的容器服务支持 Docker Compose ,供应了完整的配置和容器部署托管方案,同时仍供应了镜像加速、 镜像仓库等功能便利中国用户使用的利器并且兼容标准的 Docker API ；2. 成本名师归纳总结 - - - - - - -第 4 页,共 21 页
7、精选学习资料 - - - - - - - - - 这里说的不是虚拟化节约的服务器成本,而是采纳了Docker 容器环境,使得团队成员间、各环境间,和谐开发资源、环境季节约了大量的时间成本；挑选 Docker 特别重要的一点就是它转变了传统基于代码包的部署方式,而是可以基 于完整的 OS 镜像进行部署；在以往的从业体会中,遇到过特别多由于系统配置不一样、软件版本不一样、代码包不一样导致的Bug 甚至严峻的线上故障,而通过使用 Docker 镜像部署的方式,使得我们的测试、预发布、生产环境的代码保持高度一样,大大削减环境配置差异所带来的线上故障；3. 架构容器化的部署架构,可以使项目更多的采纳“微
8、服务 ”理念的独立服务来实现各个功能；我们采纳前后端别离的架构体系,服务端使用 Spring Cloud 构建各种微服务,通过 API 网关暴露给机器人、 Web 站点前端和移动客户端；4. 集成在创业团队只有一个运维人员、一个测试人员的前提下, 如何快速、 高质量的持续交付产品是一个挑战,而 Docker 有效地帮忙解决了这个问题； 后文相关章节详述5. 弹性对于创新项目来说, 业务的增长有特别多的不确定性,业务推广期的拜访峰值和调整期的谷值对于服务器压力的不同需求是需要考虑的现实问题；Docker 可以使服务具备快速扩容或缩容的才能,以应对这类弹性需求；部署机制 & 连续集成Docker
9、在我们的部署机制里,是由始至终的一贯角色；我们利用阿里云的Docker 镜像的私有化托管服务来统一储备我们定制的镜像；在开发环境,我们名师归纳总结 使用官方的PC 端 Docker 应用来部署调试服务；在云端三大环境,我们直第 5 页,共 21 页接 pull寄存于托管服务的镜像,在阿里云的容器服务中直接启动镜像；而操作- - - - - - -精选学习资料 - - - - - - - - - 线上的镜像创建、集成、打包、测试等一系列动作的工作,我们交给自己的Jenkins 服务来实现；即使配置好的 Jenkins 和阿里云供应的容器服务协作,已经大大简化了工作；但是 Docker 的使用依旧
10、不是一下子就对全部开发人员那么友好的；由于虽然Docker 好处许多,但其进展到今日,已经形成了相对复杂的使用、配置、部署 的体系,本身仍是有肯定的学习成本的；为了进一步降低开发人员学习 Docker 的难度,我们定义了一条应用标准和一些标准Dockerfile 模板；大多数情形下开发人员只需要将 Dockerfile 放到项目中的指定文件路径即能顺当使用这个容器服务了；全栈 Docker 我们有一个为了部署纯前端小程序的标准Dockerfile 模板,依据这个模板可以轻松建立一个 nginx 的定制化 docker 镜像；我们将前端代码打包输出至项目的 dist 目录,将该目录置入镜像中,通
11、过必要的 nginx conf 文件的配置,我们就可以轻松获得一个前端部署的标准容器；由此,我们将前端工程师的工作和其他全部工程师一样全部纳入同一个Docker 化的工程体系中,从而实现了“全栈” Docker 的目标；Docker 环境下的日志查看在实践中我们未将 Docker 容器直接暴露给开发人员,那么如何做日志查看呢？.针对测试环境和预发环境, 我们供应了一个脚本可以便利的使用docker logs查询日志；.在线上环境, 我们将日志接入了SLS 并使用正就表达式解析日志,开发人员就可以通过SLS 掌握台查看线上日志；Docker 环境下的微服务名师归纳总结 - - - - - - -
12、第 6 页,共 21 页精选学习资料 - - - - - - - - - 我们的微服务使用的是 是 Eureka Server ；Spring Cloud 中的 Netflix 相关组件,注册中心使用的为什么不用阿里开源的Dubbo+Zookeeper 方案？是由于我们的系统里有不少异构系统, RESTful API 的暴露方式便利各种语言接入；而 Dubbo 没有完整的网关和流控的解决方案,所以从快速的搭建业务系统的角度我们挑选了 Spring Cloud ；我们参考了阿里云社区的这篇文章点击查看详情 原文链接：,但依然在实践中解决了遇到的不少问题,比方以下这些：.由于 Docker 容器每
13、次重新部署,容器IP 都可能变化,因此对于客户端配置Eureka Server 的地址带来了一些麻烦；我们一开头将Eureka Server 也通过容器服务暴露自定义域名拜访, 但是常常会遇到超时问题； 我们的解决方案是将Eureka Server 通过 constraint 固定到详细的节点上, 并向节点暴露端口, client 直接配置节点 IP；. 容器 IP 变更带来的另一个问题是由于 Eureka Server 的缓存爱护机制,在每次容器 IP 变更的会存在脏链接,因此我们为 Eureka Server 增加了如下 配置：-self-preservation=false / 关闭自主
14、爱护-interval-timer-in-ms=4000 / 缩短清理间隔到 4 秒.=true / 开启健康检查Eureka Server 在研发阶段我们有本地调用测试环境服务的需求,由于注册到的 IP 是 Docker 容器的 IP,本地无法直接调用；为明白决这个问题我们把注册到 Eureka Server 的地址改为了自定义的内网域名,并将此域名在容器服务中配置暴露；本地通过容器服务的域名代理来恳求 决了这个问题；监控方案Spring Cloud 服务,从而解名师归纳总结 - - - - - - -第 7 页,共 21 页精选学习资料 - - - - - - - - - 目前的我们通过阿
15、里云云监控平台 搭建自己的监控报警系统；对于不同的业务需求,我们将监控报警系统分为以下 4 类：1. 基础资源监控我们在主机上安装云监控平台的监控插件,插件会自动向监控平台上报数据；而云监控平台会对数据进行分析处理,时,云监控平台会依据事先的设定,以下方面的数据：形成可视化图表, 当主机一些主要指标反常 向相关人员报警； 一般会以主机为单位收集名称监控详情报警阀值磁盘使用率磁盘使用率连续 3 次 5 分钟硬盘使用率 80% Disk_inode 磁盘 inode 使用率连续 3 次 5 分钟磁盘 inode 使用率 80% 名师归纳总结 CPU CPU使用率连续 3 次 5 分钟 CPU使用率
16、 第 8 页,共 21 页- - - - - - -精选学习资料 - - - - - - - - - 名称监控详情报警阀值60% MEM 内存使用率连续 3 次 5 分钟内存使用率 80% Total_processes 进程总数监控连续 3 次 5 分钟总进程数 500 Total_TCP 活动 TCP连接总数连续 3 次 5 分钟总进程数 300 CPU负载 5m 系统 upload,5 分值连续 3 次 5 分钟 upload 8 OSS_Inet/OSS_Onet 平均值连续 3 次 1 小时流量 10Mb OSS资源出站总流量CDN CDN出入站流量连续 3 次 5 分钟出站流量 1
17、00Mbyte DB_连接使用RDS实例连接数占比连续 1 次 5 分钟内最大连接占比 60% CS_CPU 容器维度 CPU使用率连续 3 次 5 分钟容器 CPU使用率 = 60% CS_MEM 容器维度 MEM使用率连续 3 次 5 分钟容器 MEM使用率 = 60% 名师归纳总结 2. 节点监控API 监控SDK 的详第 9 页,共 21 页云监控平台供应了API 接口,以满意我们自定义的数据收集；相关细文档可以查看阿里云官方的相关介绍点击查看详情 原文链接：；- - - - - - -精选学习资料 - - - - - - - - - 我们的运维工程师负责编写相关的数据上报脚本,如以下
18、图：名师归纳总结 - - - - - - -第 10 页,共 21 页精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 11 页,共 21 页精选学习资料 - - - - - - - - - 3. 站点监控站点监控主要是指站点的健康情形的监控；实的用户拜访恳求 利用 curl来实现技术上类似于黑盒测试, 通过模拟真 恳求的监控； 目前以杭州, 青岛,北京三地的机房节点来模拟不同地域的拜访,以监控服务的健康情形；我们通过添加统一的 Request Header User-Agent: Alimonitor , 以区分正常的用户行为；一般间隔 5 分钟发
19、送一次该恳求； 恳求主要使用 GET ,POST ,HEAD 三重常用的 Method ；通过对返回的 Status Code 和页面内容的校验,我们可以监控到站点不同的健康状态；名师归纳总结 - - - - - - -第 12 页,共 21 页精选学习资料 - - - - - - - - - 另外我们仍模拟了端到端的响应, 同样可以实现对各地到中心服务器的响应推迟的监控；名师归纳总结 - - - - - - -第 13 页,共 21 页精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 14 页,共 21 页精选学习资料 - - - - - - -
20、- - 4. 应用监控我们利用 Elasticsearch 平台进行数据收集,并使用 Kibana 展现数据或生成报表,仍可以通过 elastalert 触发报警；详细实现方面,我们是由logstash 收集来自全部前端代理的日志名师归纳总结 nginx_access_log ,并以grok process 的方式入库到Elasticsearch ,之第 15 页,共 21 页- - - - - - -精选学习资料 - - - - - - - - - 后再由 Kibana 来制作监控的PV 图表,服务器报警图表等可视化数据图表；名师归纳总结 - - - - - - -第 16 页,共 21 页
21、精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 17 页,共 21 页精选学习资料 - - - - - - - - - 而在处理入库的日志时,我们会依据Telegram 通道的报警；Rule Types 进行 elastalert 的邮件名师归纳总结 - - - - - - -第 18 页,共 21 页精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 19 页,共 21 页精选学习资料 - - - - - - - - - Pepper Cloud 从 AWS 到阿里云Pepper Cloud 是指 Pep
22、per 法国的技术团队为Pepper 供应的云端服务,在欧美和日本市场上主要部署在AWS 环境里；在中国,明显我们期望将Pepper Cloud 迁移到阿里云的集群上,以便为中国用户供应更好的服务；整个迁移是在充分评估测试和阿里云的大力支持下完成的,段：1. 评估阶段：主要分为以下几个阶我们排列了海外Pepper Cloud 使用的全部AWS 服务,逐个比照之后,我们发觉,阿里云基本可以掩盖全部服务；2. 验证阶段：我们通过一个 POC原型验证项目,对技术可行性做了验证；提出了从基础设施组件和中间件层面做抽象, 兼容两种云环境, 依据不同的环境参数挑选使用哪个云服务的解决方案；3. 研发阶段：
23、法国技术团队得益于阿里云新近推出的欧洲集群,的测试环境和预发布环境；4. 部署阶段：快速便利地构建了欧洲集群上在阿里云欧洲集群上的服务,我们先完成了功能测试和 API 自动化测试；由于欧洲集群仍暂不支持复制镜像, 所以我们挑选将欧洲的 国的预发布环境中导入；5. 发布阶段：ECS 镜像导出后, 在中在国内的技术团队完成最终的预发布验证后,Pepper Cloud 中国版便轻松上线发布了；只是第一步名师归纳总结 - - - - - - -第 20 页,共 21 页精选学习资料 - - - - - - - - - 至此完成的 AWS 迁移工作使得我们这个团队有了一个阶段性的里程碑,但让机器人上云仍有许多详细工作要做,各个项目更有不少迭代需要推动；不过,基本上,我们利用了今日阿里云供应的种种便利服务,已经为我们自己找到了高效的基建保证,为今后 Pepper 在中国长期开展业务,乃至我们团队整个机器人业务供应了最初的坚实的基础名师归纳总结 - - - - - - -第 21 页,共 21 页