简介： 2020 年云栖大会上，好将来 AI 中台负责人刘东东，分享了他对 AI 云原生的了解与好将来的 AI 中台实际，本文为演讲内容整顿。
AI 时代的到来，给企业的底层 IT 资源的丰盛与麻利提出了更大的挑战，利用阿里云稳固、弹性的 GPU 云服务器，当先的 GPU 容器化共享和隔离技术，以及 K8S 集群治理平台，好将来通过云原生架构实现了对资源的灵便调度，为其 AI 中台奠定了麻利而松软的技术底座。
在 2020 年云栖大会上，好将来 AI 中台负责人刘东东，分享了他对 AI 云原生的了解与好将来的 AI 中台实际，本文为演讲内容整顿。
大家好，我是好将来 AI 中台技术负责人刘东东。明天我给大家带来的演讲主题是《好将来 AI 云原生的浅谈》。我的分享次要分成四个局部：
第一，AI 服务对云原生的挑战。
第二，AI 与云原生的服务部署。
第三，AI 与云原生的服务治理。
最初想谈一谈，K8S 与 Spring Cloud 的有机联合。
1、AI 服务对云原生的挑战
首先，咱们来讲一讲 AI 服务对云原生的挑战。在云原生时代，AI 服务其中最大的一个特点就是，须要更大的算力反对，以及更弱小的一个服务的稳定性。
咱们的服务不单单只是原来的一个单体服务，当初曾经转入到一个集群服务。同时对性能的稳定性要求，曾经从 3 个 9，开始向 5 个 9 发动了挑战。
那么这些问题，曾经不再是原有的传统技术架构可能解决的。所以咱们须要一个新的技术架构。
这个新的技术架构是什么呢？就是云原生。
咱们来看一看，云原生对咱们带来的变动。云原生带来的最大变动，我总结为四个要点和两大方面。
四大要点别离是，DevOps、继续交付、微服务、容器的四个特点。两个方面则是服务部署和服务治理。当然，它还有 12 个因素的整体零碎总结。
明天重点来讲的是服务部署和服务治理。
在云原生浪潮下，咱们是如何解决服务部署和服务治理呢？
首先咱们通过 AI 与云原生的服务部署，即通过 K8S，加上一个资源的虚拟化，资源的池化等技术，解决了 AI 服务对各种硬件资源的数量级增长需要。
第二个，AI 服务与云原生的服务治理进行有机联合。通过服务治理的技术，包含服务发现、HPA、负载平衡等，解决 AI 服务对 5 个 9 的 SLA 的需要。
2、AI 服务的云原生部署
第一点谈一下是怎么把 AI 与云原生的服务部署联合起来的。
首先看一下，在 AI 时代下服务部署有哪些特点呢？
第一个就是硬件资源需要与费用增长的一个矛盾。AI 服务对于硬件的需要成数量级增长，然而硬件估算并没有成数量级增长。
第二，AI 服务对硬件的需要是多样化的。如，对高 GPU 的需要、高 CPU 的需要、高内存的需要，甚至还有局部混合的需要。
第三，AI 服务对资源的隔离是有需要的。每一个 AI 服务都可能独立应用这些资源，并且相互之间不会打搅。
第四，AI 服务可能对资源池化有要求。AI 服务不须要去感知机器的具体配置，一旦将所有的资源进行池化，即可升高资源碎片，晋升使用率。
最初一点，AI 服务对突发的资源是有申请的。因为流量是不可预知的，企业须要随时放弃，可能随时裁减资源池的能力。
咱们的解决方案是什么呢？
首先，咱们应用 Docker 的虚拟化技术，实现资源的隔离。
而后应用 GPU 共享技术，将 GPU、内存、CPU 等资源进行池化，而后将整个资源进行对立的治理。
最初，应用 K8S 的 resources，包含污点（taints）、容忍度（tolerations）等这些技术个性，实现服务的灵便配置。
另外，倡议大家要买一些高配置的机器，这些高配置的机器，次要是为了进一步升高碎片。
当然，还要实现对整个集群硬件的监控，充分利用 ECS 能够各种简单的工夫规定调度个性（下图的 cron 是一个基于工夫的作业调度工作），应答顶峰流量。
接下来，咱们更认真地看看好将来 AI 中台是如何解决这些 AI 部署问题的。
这个页面是咱们的一个 Node 的服务治理，通过这个业务，咱们是能够清晰看到每一个服务器下面的部署状况，包含资源应用状况、部署哪些 pod、哪些节点等等。
第二个实际上是 AI 中台的服务部署页面。咱们是能够通过压码文件，精准地管制每一个 pod 的内存、CPU、GPU 的应用。同时，通过污点等技术，让服务器的多样化部署失去满足。
依据咱们的比照试验，应用云原生的形式部署比照用户自行部署，老本大略节俭了 65%。而且，这样的劣势会随着 AI 集群的增长，在经济收益上和长期流量扩容上，将会受害更多。
3、AI 与云原生服务治理
接下来再讨论一下 AI 与云原生的服务治理。
简略介绍一下什么叫微服务？其实微服务，只是服务的一种架构格调，它实际上是将单个服务，作为一整套的小型服务开发，而后每一个应用程序都有本人过程去运行，并且通过轻量级的一些，比如说 HTTP、API 等进行通信。
这些服务，实际上是围绕着业务自身去构建的，能够通过自动化的部署等伎俩去集中管理。同时，通过不同的语言去编写，应用不同的存储资源。
总结起来微服务有哪些特点？
第一，微服务它足够小，甚至它只能做一件事件。
第二，微服务是无状态的。
第三，微服务相互之间是互相独立的，并且它们是面向接口的。
最初，微服务是高度自治的，每个人只对本人负责。
看到这些微服务的特点之后，再去想一想，AI 服务与微服务特点，咱们发现，AI 服务天生适宜微服务。每一个微服务，其实实质上只做一件事件。比方 OCR，OCR 服务，只做 OCR 服务；ASR，次要做 ASR 服务。
继而，每一个 AI 服务的申请都是独立的。举个简略例子，一个 OCR 申请和另外一个 OCR 申请，在实质上是没有什么关联的。
AI 服务对横向扩容是有天生奢求的。为什么？因为 AI 服务队资源的渴求十分大。于是，这种扩容就显得十分有必要性了。
AI 服务之间的依赖性也特地小。比如说像咱们的 OCR 服务，可能对 NLP 的服务，或者是对其它的 AI 服务，可能没有什么太大的要求。
所有的 AI 服务，都能够通过写申明式的 HTTP，甚至 API 的形式，提供 AI 能力。
进一步去看一下 AI 服务，会发现，并不能将所有的 AI 服务进行微服务化。于是，咱们做了什么事？
第一，须要将 AI 服务做成一个无状态的服务，这些无状态服务，都是有畜牲化、无状态、可抛弃，并且不采纳任何的一些磁盘或者内存的申请形式，去做一些存储性能。这样就能够让服务部署在任何的一个节点，任何一个中央。
当然，并不是所有的服务都能做到无状态。如果它有状态了怎么办呢？咱们会通过配置核心、日志核心、Redis、MQ，还有 SQL 等数据库，存储这些申请状态。同时，确保这些组件的高可靠性。
这个就是好将来 AI 中台 PaaS 的整体架构图。首先能够看一下最外层是服务接口层。最外层接口层是面向内部提供 AI 能力的。
平台层里最重要的层是服务网关，次要是负责一些动静路由、流量管制、负载平衡、鉴权等。再往下就是咱们的一些服务发现，注册核心，容错、配置管理、弹性伸缩等等一些性能。
再上面是业务层，这些业务层就是咱们所说的，一些 AI 的推理服务。
最上面就是阿里云给咱们提供的 K8S 集群。
也就是说整体的一个架构是，K8S 负责服务部署，SpringCloud 负责服务治理。
咱们是怎么通过技术手段来实现方才说的一个整体架构图？
首先是通过 Eureka 作为注册核心，实现分布式系统的服务发现与注册。通过配置核心 Apoll 来治理服务器的配置属性，并且反对动静更新。网关 Gateway，能够做到隔离内外层的成果。熔断 Hystrix，次要是分为分时熔断和数量熔断，而后爱护咱们的服务不被阻塞。
负载平衡加上 Fegin 操作，能够实现整体流量的负载平衡，并且将咱们的 Eureka 相干注册信息进行生产。生产总线 Kafka 是异步解决的组件。而后鉴权是通过 Outh2+RBAC 的办法去做的，实现了用户的登录包含接口的鉴权治理，保障安全可靠。
链路追踪，采纳的是 Skywalking，通过这种 APM 的一个架构，咱们能够追踪每一个申请的状况，便于定位和告警每一个申请。
最初日志零碎是通过 Filebeat+ES，分布式收集整个集群的日志。
同时咱们也开发了一些本人的服务，比如说部署服务、Contral 服务。次要是负责与 K8S 进行通信，收集整个 K8S 集群外面服务的服务部署、K8S 相干的硬件信息。
而后告警零碎是通过 Prometheus+Monitor 去做的，能够收集硬件数据，负责资源、业务等相干的告警。
数据服务是次要用于下载，包含数据回流，而后截取咱们推理场景下的数据状况。
限流服务是限度每个客户的申请和 QPS 相干性能。
HPA 实际上是最重要的一个局部。HPA 不单单只反对内存级别的，或 CPU 级别的 HPA，还反对一些 P99、QPS、GPU 等相干规定。
最初是统计服务，次要是用于统计相干调用量，比方申请等。
咱们通过一个对立的控制台，对 AI 开发者提供了一站式的解决方案，通过一个平台解决了全副的服务治理问题，晋升了运维的工作自动化，让原来须要几个人保护的一个 AI 服务的状况，变成了一个人可能做到保护十几个 AI 服务。
这个页面展现的就是服务路由、负载平衡、限流相干的配置页面。
这个页面展现的是咱们在接口级别的一些告警，以及部署级别的硬件告警。
这是日志检索，包含实时日志相干性能。
这个是手动伸缩和主动伸缩操作页面。其中主动伸缩包含 CPU、内存级别的 HPA，也包含基于相应响应时长制订 HPA、定时的 HPA。
4、K8S 与 Spring Cloud 的有机联合
最初来聊一下 K8S 与 SpringCloud 的有机联合。
能够看一下这两张图。左图是咱们 SpringCloud 数据中心到路由的图。左边是 K8S 的 service 到它的 pod 的图。
这两个图在结构上是十分靠近的。咱们是怎么做到呢？实际上是将咱们的 Application 与 K8S 的 service 进行绑定，也就是说最终注册到咱们 SpringCloud 外面 LB 的地址，实际上是把它转成了 K8S service 的地址。这样就能够将 K8S 与 SpringCloud 联合起来。这是路由级别汇合。有了这个汇合，就能达到最终的成果
SprigCloud 它是一个 Java 的技术语言站。而 AI 服务的语言是多样化的，有 C ++、Java，甚至有 PHP。
为了实现跨语言，咱们引入了 sidecar 技术，将 AI 服务与 sidecar 通过 RPC 去通信，就能够屏蔽语言的个性。
Sidecar 次要的性能有，应用服务发现与注册、路由追踪、链路追踪，以及健康检查。
明天我的演讲到此结束，非常感谢各位的凝听。谢谢大家。
原文链接
本文为阿里云原创内容，未经容许不得转载。