2019云计算开源产业大会丨邹俊:Pivotal基于开源无服务器(FaaS)的解决方案

2019年7月3日15:26:00 发表评论 14 浏览

邹俊:大家好,今天我想从这样几个方面来讲,就是Serverless适用场景、PFS的特点、Pivotal的主要方向。

2019云计算开源产业大会丨邹俊:Pivotal基于开源无服务器(FaaS)的解决方案

目前银行、金融、券商都有很多批处理的业务,应用的微服务改造和数据服务,因为现在希望把DB做成一种服务,有些传统的应用都有负载,这些应用需要在传统架构和现有云的架构当中运行起来。

基于云的架构,Pivotal有一个完整解决方案,就是可以在任意云平台上运行我们的负载。针对PaaS平台或者容器平台,我们有自己的PS。为什么今天很多厂商已经做了容器云,但还要做Serverless?有了Container以后,我们从代码测试以后需要查找可用的主机安装配置,需要检索相关的软件包、配置服务,还有就是前端需要加载防火墙的策略,包括整个应用服务监控等等。实际上有了容器平台或者PaaS平台,也就是中间件的服务,只是简单的应用配置就可以。

为什么需要PFS?PFS可以给我们带来什么?因为PaaS平台当中还是需要核心中间件,需要做URL映射,服务和服务之间关系的耦合度依然存在,也需要做好身份验证的逻辑。重要数据可以放在消息队列或者数据库,所以总的来说还是需要关心缓存的逻辑,也需要进行显示的消息处理,也就是微服务之间要做消息传递的话不做同步事件,需要通过Karta进行消息处理。

我们现在没有Server,没有7×24小时服务器,实际上目前我们的应用无论是跑在容器还是虚拟机都是7×24小时,这样付费就是按照使用,实际上就是7×24小时付费,无论是还是私有云,只不过私有云的计算成本是按照时间来算的。今天我们讲的微服务其实是SOA的一种演进,基于事件驱动的场景其实是非常普遍的,很多时候我们发起一个请求或者IoT网关,这样就是一个Event-driven的场景。

PFS都有什么?我们是基于Riff的项目,可以运行在多元平台,也就是说需要做成一个统一的标准,后面会讲底层基于KPS,所以完全是一个开源的标准。基于Riff的好处就在于运维、监控、调试、性能这些东西其实都是很大的问题,Service Mesh当中性能是不够好的,容器成千上万拉起的时候会有性能瓶颈问题,后面会讲1.1的版本有些新的解决办法。能够快速响应不同试点,因为很多试点是代码进去以后能够自动触发一个事件来做构建,这种可以用在Serverless场景。基于Message可以触发IoT或者流处理的操作,截止到今天所有负载几乎都已经容器化了,完全基于KPS来做,然后在此以上做服务试点。

我们的应用推到容器里面其实需要预先做成容器,未来的方向就是需要Source Image,也就是说我们提交的是源代码,依赖于Java虚拟机需要跑到哪个服务器,这些东西可以做到BuildPack,然后把源代码提交上去,通过这种方式直接构建,解决源代码到容器的操作,定义各种各样的消息总线,事件源也可以多种多样,这样可以适用于很多场景来做Serverless。再就是可插拔的Invoker,可以提供很多事件支持。多语言的高度弹性伸缩,也就是我们服务试点当中Stream只能去做Java,我们可以完全屏蔽语言差异性,工作负载可以快速拉起来也有一整套机制。

我们来看PFS的应用场景,主要是三个部分:首先是Web Events,比如一些Web配置,包括代码相应的操作,发布问题的时候客服反馈消息,完全基于事件驱动,不需要长期跑在应用服务里面。Events-based Integration需要去做一些文件处理,比如基于图像或者视频,安全扫描就是定期的,或者一些复杂的事件处理需要串起来去做流程,包括监控、告警等等,其实都是非常适合这种场景。Streaming Processing就是有些IoT日志的处理,未来会有越来越多的场景随着应用改造,能够把单体应用进行拆分,某些服务非常适合Serverless场景。

Knative是2018年的Google开源框架,不同角色做了什么事情?使用者的角度接触的是Istio,需要对哪些核心模型进行改造,需要管理和部署Instance,里面定义很多相应的事件源,怎样快速地维护和部署。Service Mesh比较火的就是Istio,微服务拆分以后形成一个一个网格,因为服务和服务之间需要调用,比如怎么去注册、发现,某个服务性能下降以后怎么降级,还有怎么去做交易的分布式追踪设计,其实这些都是需要在微服务里面做的,这张图就很形象,看似一张大网,所以叫做服务网格。

服务网格当中Istio都做了什么?相比先前的注入式,需要在代码当中添加注解,然后把Stream Cloud代码放入其中,Istio完全不是这样,就是去做网络流量处理,所有服务和服务之间的发现、注册、限流操作都是由数据层面进行交互。控制层面就是要把配置信息下发,微服务的监控信息、遥测数据应该怎么拿到。服务A和服务B需要一个Processing,怎么把配置信息下发,然后去做一些Policy Check,遥测数据获取,TIS证书怎么下发。现在一个更好的办法就是每个微服务放在一个NetSpace里面,这样有大量微服务的话可以保证多元流量的开销,也会有Istio全局Space,进行服务和服务之间的物流,今天的Istio还是在快速发展的过程当中。

什么是Knative?Istio之上专门去做Serverless,比如Open Waste至少不是基于KFS来做,本身可以支持多云,因为KFS本身屏蔽底层,无论是阿里、腾讯还是AWS以及其它的云厂商,使用Istio来做网络连接和物流,都有哪些消息事件进来。Build就是从源代码变成可运行的容器怎样来做,我们是用BuildPack来做,然后可以支持可扩展可插拔的多语言支持,也可以很好地集成到CICD环境当中,也可以在构建的过程当中提供持久化,最大的好处就是做了很多Build模板,不需要重新再造文字,具体采用什么标准还在慢慢形成当中。

什么是Serving?就是怎样快速地把应用容器从零扩展到N,然后从N降低到零,然后就是怎么去做版本控制,我们的应用有多个版本,包括怎样去做流量控制和监控,其实Istio可以去做这种流动。

什么是Eventing?因为消息队列当中做消息的发布和应用,其实就是去做一个抽象,消息的生产者和消费者是完全独立的,可插拔的消息总线现在支持的也越来越多了,包括DataBase Service都可以作为事件云。

有了Knative以后,怎样快速地把集群部署起来?怎样通过客户端快速创建函数?怎样通过模板构建基于Build的容器?怎样采用大量Invoker?基于Streaming的消息怎么简化定义,这些都是Riff来做,也是我们公司的产品,可以在任何版本部署Knative,无论是公有云还是私有云。

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: