机器人也上云创业团队的阿里云实践心得.docx

机器人也上云创业团队的阿里云实践心得.docx

《机器人也上云创业团队的阿里云实践心得.docx》由会员分享，可在线阅读，更多相关《机器人也上云创业团队的阿里云实践心得.docx（12页珍藏版）》请在冰豆网上搜索。

机器人也上云创业团队的阿里云实践心得

机器人也上云-创业团队的阿里云实践心得

本文章来自于阿里云云栖社区

摘要：

 机器人也上云想到机器人，相信很多人会联想到斯瓦辛格主演的《终结者》系列电影。

那部系列片里描绘了完全存在于云端的人工智能“SkyNet”。

从科幻小说，到科幻电影，到真正的科技实践中，云计算都是解决包括人工智能在内的机器人相关技术的关键和基础。

机器人也上云

想到机器人，相信很多人会联想到斯瓦辛格主演的《终结者》系列电影。

那部系列片里描绘了完全存在于云端的人工智能“SkyNet”。

从科幻小说，到科幻电影，到真正的科技实践中，云计算都是解决包括人工智能在内的机器人相关技术的关键和基础。

我们是一个负责实施机器人Pepper本地化的创业小团队，我们选择阿里云全面部署我们的业务，成了自然而然的选择。

但是，究竟如何使用云计算，或者说怎么让“机器人上云”，我们还是做了不少工程思想和技术应用上的小革新的。

项目背景

我们是一个标准意义上的创业团队。

人员不富裕，项目很紧急等等凡是创业团队会遇到的问题，我们都有遇到。

选择云计算在某种意义上，是快速搭建业务，技术性回避创业团队人员匮乏劣势的一个最佳选择。

事实上，我们至今为止，整个平台开发团队（负责所有云上业务的团队）还是一个10人以下规模的小团队。

而我们需要面对的项目，包括短期内搭建多环境架构的研发体系、建立基本业务平台、内部运营平台、基础数据平台、海外AWSBase的服务平台的整体迁移等十数个大小项目。

在这些项目中，最能体现使用阿里云计算所带来的效率最大化、可用性最优的项目是多环境网络架构和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.契机

在为我们的项目做技术选型的时候，适逢阿里云容器服务上线，我们发现阿里云的容器服务支持DockerCompose，提供了完整的配置和容器部署托管方案，同时还提供了镜像加速、镜像仓库等功能方便中国用户使用的利器并且兼容标准的DockerAPI。

2.成本

这里说的不是虚拟化节约的服务器成本，而是采用了Docker容器环境，使得团队成员间、各环境间，协调开发资源、环境时节省了大量的时间成本。

选择Docker非常重要的一点就是它改变了传统基于代码包的部署方式，而是可以基于完整的OS镜像进行部署。

在以往的从业经验中，遇到过非常多因为系统配置不一致、软件版本不一致、代码包不一致导致的Bug甚至严重的线上故障，而通过使用Docker镜像部署的方式，使得我们的测试、预发布、生产环境的代码保持高度一致，大大减少环境配置差异所带来的线上故障。

3.架构

容器化的部署架构，可以使项目更多的采用“微服务”理念的独立服务来实现各个功能。

我们采用前后端分离的架构体系，服务端使用SpringCloud构建各种微服务，通过API网关暴露给机器人、Web站点前端和移动客户端。

4.集成

在创业团队只有一个运维人员、一个测试人员的前提下，如何快速、高质量的持续交付产品是一个挑战，而Docker有效地帮助解决了这个问题。

（后文相关章节详述）

5.弹性

对于创新项目来说，业务的增长有非常多的不确定性，业务推广期的访问峰值和调整期的谷值对于服务器压力的不同需求是需要考虑的现实问题。

Docker可以使服务具备快速扩容或缩容的能力，以应对这类弹性需求。

部署机制&&持续集成

Docker在我们的部署机制里，是由始至终的一贯角色。

我们利用阿里云的Docker镜像的私有化托管服务来统一存储我们定制的镜像。

在开发环境，我们使用官方的PC端Docker应用来部署调试服务；在云端三大环境，我们直接 pull 寄存于托管服务的镜像，在阿里云的容器服务中直接启动镜像。

而操作线上的镜像创建、集成、打包、测试等一系列动作的工作，我们交给自己的Jenkins服务来实现。

即使配置好的Jenkins和阿里云提供的容器服务配合，已经大大简化了工作。

但是Docker的使用依然不是一下子就对所有开发人员那么友好的。

因为虽然Docker好处很多，但其发展到今天，已经形成了相对复杂的使用、配置、部署的体系，本身还是有一定的学习成本的。

为了进一步降低开发人员学习Docker的难度，我们定义了一条应用规范和一些标准Dockerfile模板。

大多数情况下开发人员只需要将Dockerfile放到项目中的指定文件路径即能顺利使用这个容器服务了。

全栈Docker

我们有一个为了部署纯前端小程序的标准Dockerfile模板，根据这个模板可以轻松建立一个nginx的定制化docker镜像。

我们将前端代码打包输出至项目的 dist 目录，将该目录置入镜像中，通过必要的nginxconf文件的配置，我们就可以轻松获得一个前端部署的标准容器。

由此，我们将前端工程师的工作和其他所有工程师一样全部纳入同一个Docker化的工程体系中，从而实现了“全栈”Docker的目标。

Docker环境下的日志查看

在实践中我们未将Docker容器直接暴露给开发人员，那么如何做日志查看呢？

∙针对测试环境和预发环境，我们提供了一个脚本可以方便的使用 dockerlogs 查询日志。

∙在线上环境，我们将日志接入了SLS并使用正则表达式解析日志，开发人员则可以通过SLS控制台查看线上日志。

Docker环境下的微服务

我们的微服务使用的是SpringCloud中的Netflix相关组件，注册中心使用的是EurekaServer。

为什么不用阿里开源的Dubbo+Zookeeper方案？

是因为我们的系统里有不少异构系统，RESTfulAPI的暴露方式方便各种语言接入。

而Dubbo没有完整的网关和流控的解决方案，所以从快速的搭建业务系统的角度我们选择了SpringCloud。

我们参考了阿里云社区的这篇文章（点击查看详情原文链接：

∙由于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//开启健康检查

∙在研发阶段我们有本地调用测试环境服务的需求，由于注册到EurekaServer的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请求的监控。

目前以杭州，青岛，北京三地的机房节点来模拟不同地域的访问，以监控服务的健康情况。

我们通过添加统一的HTTPRequestHeader User-Agent:

Alimonitor,以区分正常的用户行为。

一般间隔5分钟发送一次该请求。

请求主要使用GET，POST，HEAD三重常用的HTTPMethod。

通过对返回的HTTPStatusCode和页面内容的校验，我们可以监控到站点不同的健康状态。

另外我们还模拟了端到端的响应，同样可以实现对各地到中心服务器的响应延迟的监控。

4.应用监控

我们利用Elasticsearch平台进行数据收集，并使用Kibana展示数据或生成报表，还可以通过elastalert触发报警。

具体实现方面，我们是由logstash收集来自所有前端代理的日志（nginx_access_log），并以grokprocess的方式入库到Elasticsearch，之后再由Kibana来制作监控的PV图表，服务器报警图表等可视化数据图表。

而在处理入库的日志时，我们会根据RuleTypes进行elastalert的邮件（Telegram）通道的报警。

PepperCloud从AWS到阿里云

PepperCloud是指Pepper法国的技术团队为Pepper提供的云端服务，在欧美和日本市场上主要部署在AWS环境里。

在中国，显然我们希望将PepperCloud迁移到阿里云的集群上，以便为中国用户提供更好的服务。

整个迁移是在充分评估测试和阿里云的大力支持下完成的，主要分为以下几个阶段：

1.评估阶段：

我们罗列了海外PepperCloud使用的全部AWS服务，逐个对比之后，我们发现，阿里云基本可以覆盖所有服务。

2.验证阶段：

我们通过一个POC（原型验证）项目，对技术可行性做了验证。

提出了从基础设施组件和中间件层面做抽象，兼容两种云环境，根据不同的环境参数选择使用哪个云服务的解决方案。

3.研发阶段：

法国技术团队得益于阿里云新近推出的欧洲集群，快速便捷地构建了欧洲集群上的测试环境和预发布环境。

4.部署阶段：

在阿里云欧洲集群上的服务，我们先完成了功能测试和API自动化测试。

由于欧洲集群还暂不支持复制镜像，所以我们选择将欧洲的ECS镜像导出后，在中国的预发布环境中导入。

5.发布阶段：

在国内的技术团队完成最后的预发布验证后，PepperCloud中国版便轻松上线发布了。

只是第一步

至此完成的AWS迁移工作使得我们这个团队有了一个阶段性的里程碑，但让机器人上云还有很多具体工作要做，各个项目更有不少迭代需要推进。

不过，基本上，我们利用了今天阿里云提供的种种便捷服务，已经为我们自己找到了高效的基建保障，为今后Pepper在中国长期开展业务，乃至我们团队整个机器人业务提供了最初的坚实的基础