秦淮河畔，我们聊了聊智能化时代的架构与运维

我们已全面进入了人工智能时代，人工智能时的切入点在哪里，哪里更容易爆发出人工智能的火花，是很多开发者在实践中苦恼的问题。与此同时，与人工智能时代随之而来的是各种软件系统、运维复杂度的提升和思维方式的多样化。近几年业界出现了面向服务的架构（SOA）、微服务以及无服务器架构等概念，运维方式也在向智能化运维全力迈进。

于是，11 月 18 日上周六 InfoQ 携手 AWS 就开启了对智能化时代架构与运维之道的探索。两位 AWS 解决方案架构师邓明轩、吴鹏程及英语流利说后端工程师韩冰，齐聚于南京江南莺飞技术空间，围绕人工智能、架构演进、容器与微服务等技术实践，揭示了其对于 AI 解决方案、微服务及 Serverless 架构、生产级 Kubernetes 平台打造和创新的理解和探寻。

基于 AWS 的人工智能技术探索与实践

Amazon.com 的推荐引擎由机器学习 (ML) 提供支持，运营中心内优化机器人拣选路线的路径也是一样。此外，其供应链、预测和容量规划信息也是由 ML 算法提供。Alexa、无人机计划、Prime Air，以及新零售体验中的计算机视觉技术 Amazon Go 也都一样，全部由自然语言理解和自动语音识别深度学习提供支持。因此，邓明轩在其演讲中重点阐述了 Amazon AI 的层级和架构。

AWS 将 AI 服务分成了四层，最顶层的其称为托管云服务，用邓的话来说即，“有了这类托管服务，你不需要关注技术底层的实践是什么，只要关注业务需求，需要用的时候调一个功能就可以实现你的诉求“。无论是 Amazon Polly 还是 Amazon Lex 等都属于这套托管服务。

再往下一层是托管机器学习平台，它涉及到二元分类和数值预测等。第三层是底层的基础架构，如 Apache MXNet、TensorFlow、Caffe 等深度学习框架和深度学习硬件措施，在这里用于调整你的深度学习结构、优化控制。

最底部层即 AI 云基础架构，包括熟知的 ECS 和 Lambda，除此之外还有 GPU 和 F1 的实例及具有跨设备的分布式运行能力的 P2。这一整套平台、框架及服务构成了 Amazon AI。

走向微服务和无服务器架构

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

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

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

新一代 “无服务器”架构模型

流利说如何在 AWS 上打造生产级 Kubernetes 平台

据英语流利说后端工程师韩冰的陈述，2014 年底到 2016 年 AWS 发展规模和架构都不复杂，但从 Terraform 启动 EC2 到初始化 Ansible 的过程当中会有很多问题，涉及到机器的启动及配置就导致了整个部署过程麻烦且费时，进而导致扩容难，扩容久等问题的产生。再加上不能动态伸缩，就导致流利说需要将机器一直保持在较大量级上，造成了资源一定程度上的浪费。

从 2016 年初到 2016 年底，流利说开始尝试用 Docker 的模式架构其应用。但当时微服务越来越多，面临的重要问题之一是开发团队无法自己部署服务到线上。所以 2016 年底到现在就改用通过一整套流程来增加其 CB。

流利说考虑使用 Kubernetes 涉及的重要原因是——开发人员不需要再花更多时间关注底层机器，一个 pod 需要多少 CPU、多少 memory，Kubernetes 可以帮助完成调度。那么在 AWS，特别是 AWS（中国）上部署 k8s，流利说使用的主要是 kops——k8s 官方推出的运维工具，但方便之余也伴随着一系列问题。

例如，k8s 如何跟公司内部工作流整合起来？我们的方案是选择 Gitlab，另外是 Spinnaker 这套开源方案。再例如，监控怎么样跟 k8s 做集成？我们的方案是使用 Prometheus。Prometheus 与 k8s 的整合，大概原理是通过 p8s 抓数据从而得到网络进出的数据，再借助 Grafana 看到监控数据并通过 AlertManager 进行报警。

除监控外，日志也是很重要的一方面，我们当时给自己定制的目标是能根据 pod 和 service 来查询并实时看到日志，而且服务能够很容易地接入，于是我们选择的方案是 fluentd。演讲之后，热情的现场观众也针对 Kubernetes 应用的高可用和灾备、k8s 调度等问题与韩冰老师做了进一步的探讨和交流，更多的解决方案也在这种深度的互动中得到了分享和归属。