asp网站查看器,扬中贴吧,佛山刚刚发生的事,apache做网站简介#xff1a; 2020年云栖大会上#xff0c;好未来AI中台负责人刘东东#xff0c;分享了他对AI云原生的理解与好未来的AI中台实践#xff0c;本文为演讲内容整理。
AI时代的到来#xff0c;给企业的底层IT资源的丰富与敏捷提出了更大的挑战#xff0c;利用阿里云稳定、…简介 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服务天生适合微服务。每一个微服务其实本质上只做一件事情。比如OCROCR服务只做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是异步处理的组件。然后鉴权是通过Outh2RBAC的方法去做的实现了用户的登录包括接口的鉴权管理保证安全可靠。
链路追踪采用的是Skywalking通过这种APM的一个架构我们可以追踪每一个请求的情况便于定位和告警每一个请求。
最后日志系统是通过FilebeatES分布式收集整个集群的日志。 同时我们也开发了一些自己的服务比如说部署服务、Contral服务。主要是负责与K8S进行通信收集整个K8S集群里面服务的服务部署、K8S相关的硬件信息。
然后告警系统是通过PrometheusMonitor去做的可以收集硬件数据负责资源、业务等相关的告警。
数据服务是主要用于下载包括数据回流然后截取我们推理场景下的数据情况。
限流服务是限制每个客户的请求和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主要的功能有应用服务发现与注册、路由追踪、链路追踪以及健康检查。
今天我的演讲到此结束非常感谢各位的聆听。谢谢大家。
原文链接 本文为阿里云原创内容未经允许不得转载。
