机器人也上云创业团队的阿里云实践心得.docx
- 文档编号:2177382
- 上传时间:2022-10-27
- 格式:DOCX
- 页数:10
- 大小:509.95KB
机器人也上云创业团队的阿里云实践心得.docx
《机器人也上云创业团队的阿里云实践心得.docx》由会员分享,可在线阅读,更多相关《机器人也上云创业团队的阿里云实践心得.docx(10页珍藏版)》请在冰豆网上搜索。
机器人也上云创业团队的阿里云实践心得
机器人也上云-创业团队的阿里云实践心得
———————————————————————————————— 作者:
————————————————————————————————日期:
ﻩ
机器人也上云-创业团队的阿里云实践心得
本文章来自于阿里云云栖社区
摘要:
机器人也上云想到机器人,相信很多人会联想到斯瓦辛格主演的《终结者》系列电影。
那部系列片里描绘了完全存在于云端的人工智能“SkyNet”。
从科幻小说,到科幻电影,到真正的科技实践中,云计算都是解决包括人工智能在内的机器人相关技术的关键和基础。
机器人也上云
想到机器人,相信很多人会联想到斯瓦辛格主演的《终结者》系列电影。
那部系列片里描绘了完全存在于云端的人工智能“SkyNet”。
从科幻小说,到科幻电影,到真正的科技实践中,云计算都是解决包括人工智能在内的机器人相关技术的关键和基础。
ﻫ我们是一个负责实施机器人Pepper本地化的创业小团队,我们选择阿里云全面部署我们的业务,成了自然而然的选择。
但是,究竟如何使用云计算,或者说怎么让“机器人上云”,我们还是做了不少工程思想和技术应用上的小革新的。
项目背景
我们是一个标准意义上的创业团队。
人员不富裕,项目很紧急等等凡是创业团队会遇到的问题,我们都有遇到。
选择云计算在某种意义上,是快速搭建业务,技术性回避创业团队人员匮乏劣势的一个最佳选择。
事实上,我们至今为止,整个平台开发团队(负责所有云上业务的团队)还是一个10人以下规模的小团队。
而我们需要面对的项目,包括短期内搭建多环境架构的研发体系、建立基本业务平台、内部运营平台、基础数据平台、海外AWS Base的服务平台的整体迁移等十数个大小项目。
在这些项目中,最能体现使用阿里云计算所带来的效率最大化、可用性最优的项目是多环境网络架构和AWS服务整体迁移两项。
本文将侧重介绍这两方面相关内容。
网络架构
俗话说,麻雀虽小五脏俱全。
如果需要以工程化的要求来进行团队合作开发,一些标准的工程环境是必不可少的。
众所周知,一般的在线工程环境包括:
测试环境(QA)、预发布环境(Staging)、生产环境(Production)三大部分。
我们在阿里云上完整构建了上述环境,下面是整体网络的一个概览图:
ﻫ
1.测试环境:
测试环境是一个独立的VPC,拥有独立的配属于测试环境的一级域名(只做VPC内解析,不做公网解析)、内网 DNS、中间件和阿里云基础服务。
为了测试环境的安全和日常使用的便利,我们通过OpenVPN打通测试环境和办公网络,后续视业务房展会考虑专线接入。
2.预发布环境:
预发布环境和线上环境同属于一个VPC,公用同一套阿里云基础服务,但是DNS、配置中心和中间件是独立的。
预发布环境的域名和线上保持一致,测试验证的时候需要手动绑定(或者使用),这样做是为了尽量保持预发布环境和生产环境的高度一致。
3.生产环境:
在生产环境中,我们除了使用了包括负载均衡、容器服务、RDS等大量的阿里云基础服务之外,还基于云监控和ELK 构建了我们的监控系统,详见监控方案章节。
4.API网关:
由于我们整体使用了前后端分离的架构,在我们的网络架构里还有一个特点是基于 Zuul搭建了一套API网关。
定义了统一的前后端交互协议,包括采用JWT 协议来鉴权,以 RESTful风格作为接口标准等等。
Docker容器服务实践
近年来 Docker 已然成为了DevOps圈里的大热门。
作为一个自认为追求效率的小而美的团队,响应热点显然不是我们的目的,真正帮助到团队、能够提升生产效率,才是我们选择这一技术的根本原因。
为什么选择 Docker
1.契机
在为我们的项目做技术选型的时候,适逢阿里云容器服务上线,我们发现阿里云的容器服务支持Docker Compose,提供了完整的配置和容器部署托管方案,同时还提供了镜像加速、镜像仓库等功能方便中国用户使用的利器并且兼容标准的DockerAPI。
2.成本
这里说的不是虚拟化节约的服务器成本,而是采用了Docker容器环境,使得团队成员间、各环境间,协调开发资源、环境时节省了大量的时间成本。
选择 Docker非常重要的一点就是它改变了传统基于代码包的部署方式,而是可以基于完整的OS镜像进行部署。
在以往的从业经验中,遇到过非常多因为系统配置不一致、软件版本不一致、代码包不一致导致的Bug 甚至严重的线上故障,而通过使用 Docker镜像部署的方式,使得我们的测试、预发布、生产环境的代码保持高度一致,大大减少环境配置差异所带来的线上故障。
3.架构
容器化的部署架构,可以使项目更多的采用“微服务”理念的独立服务来实现各个功能。
我们采用前后端分离的架构体系,服务端使用Spring Cloud 构建各种微服务,通过API网关暴露给机器人、Web站点前端和移动客户端。
4.集成
在创业团队只有一个运维人员、一个测试人员的前提下,如何快速、高质量的持续交付产品是一个挑战,而Docker有效地帮助解决了这个问题。
(后文相关章节详述)
5.弹性
对于创新项目来说,业务的增长有非常多的不确定性,业务推广期的访问峰值和调整期的谷值对于服务器压力的不同需求是需要考虑的现实问题。
Docker可以使服务具备快速扩容或缩容的能力,以应对这类弹性需求。
部署机制 && 持续集成
Docker 在我们的部署机制里,是由始至终的一贯角色。
我们利用阿里云的Docker镜像的私有化托管服务来统一存储我们定制的镜像。
在开发环境,我们使用官方的PC端Docker应用来部署调试服务;在云端三大环境,我们直接 pull 寄存于托管服务的镜像,在阿里云的容器服务中直接启动镜像。
而操作线上的镜像创建、集成、打包、测试等一系列动作的工作,我们交给自己的 Jenkins服务来实现。
即使配置好的Jenkins和阿里云提供的容器服务配合,已经大大简化了工作。
但是Docker的使用依然不是一下子就对所有开发人员那么友好的。
因为虽然 Docker好处很多,但其发展到今天,已经形成了相对复杂的使用、配置、部署的体系,本身还是有一定的学习成本的。
为了进一步降低开发人员学习Docker的难度,我们定义了一条应用规范和一些标准Dockerfile模板。
大多数情况下开发人员只需要将Dockerfile 放到项目中的指定文件路径即能顺利使用这个容器服务了。
全栈Docker
我们有一个为了部署纯前端小程序的标准 Dockerfile模板,根据这个模板可以轻松建立一个 nginx的定制化docker镜像。
我们将前端代码打包输出至项目的 dist 目录,将该目录置入镜像中,通过必要的nginx conf文件的配置,我们就可以轻松获得一个前端部署的标准容器。
由此,我们将前端工程师的工作和其他所有工程师一样全部纳入同一个Docker化的工程体系中,从而实现了“全栈”Docker 的目标。
Docker环境下的日志查看
在实践中我们未将Docker 容器直接暴露给开发人员,那么如何做日志查看呢?
∙针对测试环境和预发环境,我们提供了一个脚本可以方便的使用 dockerlogs 查询日志。
∙在线上环境,我们将日志接入了SLS并使用正则表达式解析日志,开发人员则可以通过SLS 控制台查看线上日志。
Docker环境下的微服务
我们的微服务使用的是 SpringCloud 中的Netflix相关组件,注册中心使用的是EurekaServer。
ﻫ为什么不用阿里开源的Dubbo+Zookeeper方案?
是因为我们的系统里有不少异构系统,RESTfulAPI的暴露方式方便各种语言接入。
而Dubbo 没有完整的网关和流控的解决方案,所以从快速的搭建业务系统的角度我们选择了Spring Cloud。
ﻫ我们参考了阿里云社区的这篇文章(点击查看详情原文链接:
),但依然在实践中解决了遇到的不少问题,比如以下这些:
∙由于Docker容器每次重新部署,容器IP都可能变化,因此对于客户端配置EurekaServer的地址带来了一些麻烦。
我们一开始将EurekaServer也通过容器服务暴露自定义域名访问,但是经常会遇到超时问题。
我们的解决方案是将 EurekaServer通过constraint 固定到具体的节点上,并向节点暴露端口,client 直接配置节点 IP。
∙容器IP变更带来的另一个问题是由于 EurekaServer的缓存(保护)机制,在每次容器IP变更的会存在脏链接,因此我们为EurekaServer 增加了如下配置:
eureka.server.enable-self-preservation=false//关闭自主保护
eureka.server.eviction-interval-timer-in-ms=4000//缩短清理间隔到4秒
eureka.client.healthcheck.enabled=true//开启健康检查
∙在研发阶段我们有本地调用测试环境服务的需求,由于注册到Eureka Server的IP 是Docker容器的IP,本地无法直接调用。
为了解决这个问题我们把注册到EurekaServer 的地址改为了自定义的内网域名,并将此域名在容器服务中配置暴露。
本地通过容器服务的域名代理来请求SpringCloud服务,从而解决了这个问题。
监控方案
目前的我们通过阿里云 云监控平台 搭建自己的监控报警系统。
ﻫ
对于不同的业务需求,我们将监控报警系统分为以下4类:
1.基础资源监控
我们在主机上安装云监控平台的监控插件,插件会自动向监控平台上报数据。
而云监控平台会对数据进行分析处理,形成可视化图表,当主机一些主要指标异常时,云监控平台会根据事先的设定,向相关人员报警。
一般会以主机为单位收集以下方面的数据:
名称
监控详情
报警阀值
磁盘使用率
磁盘使用率
连续3次5分钟硬盘使用率>80%
Disk_inode
磁盘inode使用率
连续3次5分钟磁盘inode使用率>80%
CPU
CPU使用率
连续3次 5分钟CPU使用率> 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
OSS资源出站总流量
连续3次1小时流量>10Mb
CDN
CDN出入站流量
连续3次5分钟出站流量> 100Mbyte
DB_连接使用
RDS实例连接数占比
连续1次 5分钟内最大连接占比>60%
CS_CPU
容器维度CPU使用率
连续3次5分钟容器CPU使用率>=60%
CS_MEM
容器维度MEM使用率
连续3次5分钟容器MEM使用率 >=60%
2.节点监控( API监控)
云监控平台提供了API接口,以满足我们自定义的数据收集。
相关SDK的详细文档可以查看阿里云官方的相关介绍(点击查看详情原文链接:
)。
我们的运维工程师负责编写相关的数据上报脚本,如下图:
ﻫ
3.站点监控
站点监控主要是指站点的健康情况的监控。
技术上类似于黑盒测试,通过模拟真实的用户访问请求(利用curl)来实现HTTP请求的监控。
目前以杭州,青岛,北京三地的机房节点来模拟不同地域的访问,以监控服务的健康情况。
我们通过
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 机器人 也上云 创业 团队 阿里 实践 心得
![提示](https://static.bdocx.com/images/bang_tan.gif)