窥视 2018：AWS 在人工智能与微服务上的最佳实践

刚刚结束了拉斯维加斯的 2017re:Invent 大会，AWS 就于 12 月 16 日（上周六）带着其新的发布、新的理念携手 InfoQ 来到了西湖畔，布道基于人工智能、大数据、微服务、无服务器的架构实践与实现，与更多的杭州开发者探秘 20+ 项新服务、功能、硬件背后的架构基石。

回顾 2017 年，AWS 在各技术领域的创新可谓达到了「热火朝天」的境界。无论是身处于 AI 时代大潮的普通开发者群体，亦或是受制于架构飞速演进而无力取得突围的架构师们，都对奋力冒出头的架构新星们（如微服务、Serverless）如何演进、如何设计等充满了疑惑。同时伴随着 AI 的到来，架构和运维都受到了不同程度的挑战。带着对这些问题的解答，AWS 解决方案架构师陈琳涛、吴鹏程及杭州登虹科技运维负责人高峰开始了这场布道。

AI：虚幻的泡沫 or 真实的未来 ？（查看并下载讲师ppt ，提取码： x6v2）

现在这个时代大家都做人工智能，很多用户稍微把大数据梳理一下，紧接着就说推荐推模型怎么做、图像识别怎么做。所以在这个过程中，很多人会问有什么方法快速实现智能？增加用户体验的更加自动化的方式是什么？

那么，要构建一个智能应用，我们需要做什么事情？首先需在云上做训练，训练完之后把相应的数据部署，部署完之后做预测和预测，之后有相应的结果拉回来，这些数据反馈回去做相应的重新计算，重新用参数的调整，形成循序不断的过程。

众所周知，数据准备完成后还需做数据分析和数据训练、参数调优。然后模型的训练也同时需要评估与优化，这是机器学习的重要过程和阶段。

AWS 从底层推出计算、存储在内的基础服务，上层是托管的人工智能或机器学习的服务，中间层包括了一些框架平台，整个架构构成了用户可快速在 AWS 构建智能服务的基石。

今年， AWS 还推出了几项比较好的语言服务:

一是 Amazon Transcribe，全托管和不断训练的自动语音识别 (ASR) 服务，可接收音频并自动生成准确的文字记录。可让你把当前的输出语音实时翻译成文本记录下来。比如一个电话过来，可以用 Transcribe 做成文本，也可以用 Amazon Lex 分析。Transcribe 可以把语言记录下来，而 LEX，比如你有一个提示词之后可以用，这个可以以场景存下来。

二是 Amazon Translate，它属于全托管翻译服务，使用深度学习提供高质量、快速且价格合理的语言翻译服务。三是 Amazon Comprehend，它主要是全托管的自然语言处理 (NLP) 服务，使用深度学习智能发掘文本内容。

在今年的 re:Invent 大会上，AWS 还带来了一系列与人工智能相关的新平台、工具和服务。其中令人最为振奋的包括 Amazon Sagemaker 和 AWS DeepLens。Sagemaker 依然属于全托管服务，主要方便数据科学家和研发人员在智能应用的生产环境中快速轻松地构建基于机器学习的模型。

DeepLens是适合开发人员的深度学习摄像头：

• 完全可编程的视频摄像头
• 设备端优化的深度学习框架 Apache
• MXNet, Caffe, TensorFlow
• 教程，样例代码，示例，预制模型
• 和 Amazon Sagemaker 集成

陈琳涛总结说，AWS 有很多基础架构，例如 MXNet 提供了很方便的接入接口，同时对 GPU 水平扩展有增加。AWS 从 GPU 到现在的 P3 支持了 Volta 技术，再往上支持了 FPG 模式。FPG 特定场景下的速度比 GPU 快了近 10 倍。另外，AWS 也提供很多方便的深度学习框架，这个框架下面支持了 Linux 等方式。总的来说，AWS 是方便、易开发的平台，可以让用户方便地搜集数据、做数据存储、数据搜集和预先判断，也包括数据清洗。有了这些干净数据之后用户就可以很方便地构建 AI 应用。

查看陈琳涛演讲视频

如何走向微服务和无服务器架构 ？（查看并下载讲师ppt ，提取码： x6v2）

架构的关键是分而治之的哲学，切分是为了软件研发、运维方便，软件的目标是整体交付。之前在其他一些线下沙龙关于架构层的分享中，以如何切分居多、如何集成内容为话题的讨论较少。而吴鹏程就以单体、SOA 架构的最佳实践、微服务、无服务器架构部署的最佳实践等几个方向揭示计算架构的演进策略。

云上第一件关键的事情就是安全。安全之外，很多开发者还希望整个架构可以横向扩展，因为这样即可以实现自动扩展。更多的时候我们希望用 AWS 托管服务，托管服务就是 AWS 帮助维护架构的扩展性和可靠性。

技术继续往前发展，越来越多的开发者愿意只关心怎么部署合适的代码、业务逻辑怎么实现，不用再担心基础设施的具体情况，甚至服务发现、后期注册、扩展性、容量、性能监测等也可以尽可能的省去部署时间，所以在这个过程中就出现了 Serverless。同时，最早的单体架构是把业务逻辑组合，但演变到之后更多的是希望把业务和逻辑拆开从而实现业务的解耦，而这项技术走到极致就是微服务。实际上，微服务本质上可以理解为 Serverless 的衍生，Serverless 本质上是为微服务服务的。

无服务器架构有很多的服务实现，核心包括 Lambda 和 S3，以及 SQS 和 SNS。比如部分大数据的服务在后端已有服务器运行，而当你运行时，GPU、内存多少或者是怎样的操作环境都不是服务器所要关心的。这，就是无服务器架构的核心理念。

AWS Lambda 是事件驱动的函数。在 Serverless 中，AWS Lambda 能以大规模并行方式执行代码，以响应事件。

触发 Lambda 的事件大概有三种类型——一是数据状态变化，二是请求端点变化，此外还有资源状态变化。关于 Lamdba 的注意事项和最佳实践，首先 Lamdba 不会交互，也不会自己存任何的数据。这个时候如果需要获取数据、状态和信息即需要访问数据库或者访问 S3。同时，Lamdba 跟 Lamdba 之间的交互也需要像数据库或一些目录去访问。所以这时 Lamdba 是无状态的才可以做横向扩展。

同时，吴鹏程还介绍了 Lambda 使用上的注意事项和最佳实践。首先，在快速启动上，1、要注意初始化 AWS 客户端连接或者数据库连接的时候的变量 scope，尽可能的复用连接；2、利用 CloudWatch Events 来做预热；3、ENIs for VPC 将会在 Code Start 时候被加载。此外，Lambda 使用的一大利处是可以自定义 CloudWatch 指标，每一个 Post 不超过 40KB，数据可以自由调整，如果数据量非常大，还可以使用 Kinesis 来聚合日志。

此外，Lambda 还有一个绝配的东西，就是 API Gateway。它是一个全托管、可拓展的 RESTful API 网关服务。自带抗 DDoS 攻击，包括伪造请求 (7 层) 和 SYN 攻击 (3 层)。能为所有 API 调用提供缓存层 (caching layer)，并自动使用 Swagger 模式做 API 接口管理。

吴鹏程总结说，微服务催生的无服务器架构能够使开发者只关注代码和业务，推动快速业务创新和迭代。而 AWS 利用众多 Serverless 的托管服务以及 Lambda、API Gateway 等实现整体无服务器架构，避免花费大量精力维护系统的安全、可靠、弹性，并能降低成本。

查看吴鹏程演讲视频

云端的智能化运维探索与实践 （查看并下载讲师ppt ，提取码： x6v2）

登虹科技在实际应用落地中面临的第一个需求即 Auto Scaling。家用摄像头的计算工作量会在不同的时间段出现较大的差异，所以在运维人的期望中，是实现无人值守、增量部署、安全更新、减少包袱四点。

做人脸识别图形和图象算法需要自己训练出来模型特征并实现实时更新，另外就是本地的应用服务也有较多更新。但代码时间跑久以后会导致代码对环境有较大依赖，很多编码设置不能一直更新和增量。

所以登虹科技采用的解决方案是 Chef-Solo And Knife。Chef-Solo 模式，即 Chef 的 standalone 模式，没有专门的 Chef-server，Chef-Solo 作为一个后台服务一样运行在所管理的服务器上，通过 cookbook 来控制本机的配置管理。高峰解释说，当拿到基础操作系统进项，后续所有的操作放在 Chef-Solo cookbook 里面，再放到 S3 上，这样进项起来的时候会自动下载 cookbook，把服务相关的拉进来，同时把服务器挂载在 ELB 后。

同时，高峰团队还用到了 Prometheus 来解决微服务发现的问题。平台打包以后就可以动态迁移到其他平台上，但在其他平台上不可能有相应的一套云体系平台做监控，所以要对自己的服务发现做一些评估，同时要能搜集到相应监控业务数据。

AWS 提供了一个功能可以让用户自己做服务注册发现，通过 SDK 获得某个模块相应的 Lest 和相应数据。Prometheus 自身的一部分功能就是调用 AWS 接口显示在列表里，这样 cookbook 就属于日志性东西，尤其是在容器使用较多和用高进项较多的场景下。

高峰说，虽然登虹现在大多都是做微服务，但总会有浪涌现象，而浪涌现象又导致连锁现象。这时候要做第一个事情就是报警汇聚。登虹使用的工具之一是 Pagerduty。Pagerduty 面临的第一个问题是对同类报警，第二个是对平台打包。同时，在使用多个微服务模块时，很多服务调度会遇到不同问题，包括每个模块对应权限在 AWS 遇到的问题也不尽相同。

在完成了包括打包、运维相关长期摸索之后，登虹平台发展到较为稳定的程度。在扩容跟建设方面，自动化工具被其内部大量推广使用。发布与部署可实现类似「金丝雀模式」，一小部分服务器被升级到一个新版本或者新配置，随后保持一定的孵化期。如果没有任何未预料的问题发生，发布流程就会继续，其他的软件服务器也会被逐渐升级到新版本。如果发生了问题，这个单独修改过的软件服务器可以很快被还原到已知的正常状态下。

查看高峰演讲视频