域名频道资讯站邹俊：大家好，今天我想从这样几个方面来讲，就是Serverless适用场景、PFS的特点、Pivotal的主要方向。
目前银行、金融、券商都有很多批处理的业务，应用的微服务改造和数据服务，因为现在希望把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，无论是公有云还是私有云。
