这是本节的多页打印视图。 点击此处打印.

返回本页常规视图.

Serverless项目

serverless项目

1 - 概述

serverless项目概述

Functions-as-a-Service (FaaS)

将逻辑编写为响应各种事件的小块代码。

  • AWS Lambda
  • Azure Functions
  • 基于Apache OpenWhisk的IBM Cloud Functions
  • Google Cloud Functions
  • 华为Function Stage 和 Function Graph
  • Kubeless
  • iron.io
  • funktion
  • fission
  • nuclio

时间线

  • 虽然按需或“花多少用多少”模式的概念可追溯到2006年和一个名为Zimki的平台
  • serverless一词的第一次使用是2012年来自Iron.io的IronWorker产品 ，一个基于容器的分布式按需工作平台。

从那以后，公共云和私有云都出现了更多serverless实现:

在云服务厂商之外，开源社区也涌现出很多优秀的Serverless框架，比如

2 - AWS Lambda项目

AWS Lambda项目

2.1 - Lambda Layers

Lambda Layers

背景

AWS 在2018年11月推出两个新功能，声称将使无服务器开发变得更加容易：

  • Lambda Layers：用于集中管理跨功能共享的代码和数据
  • Lambda Runtime API，一个使用任何编程语言或特定语言版本的简单接口，用于开发函数，将 AWS Lambda 从 JavaScript 扩展到其他编程语言

这两个功能可以一起使用：Runtime可以作为Layer共享，以便开发人员可以在创建Lambda函数时选择它们并使用自己喜欢的编程语言。

Lambda Layers

Lambda Layers介绍

构建serverless应用程序时，通常会在Lambda函数之间共享代码。可以是由多个函数使用的自定义的代码，或者是用来简化业务逻辑实现的标准库。

以前，必须将此共享代码与所有使用它的函数一起打包和部署：

现在，您可以将常用组件放在ZIP文件中并将其作为Lambda Layer上传。您的函数代码不需要更改，并且可以像通常那样引用Layer中的库:

Layer可以帮助在函数间更方便的共享代码：Upload layer once，reference within any function！

而Layer可以包含任意内容，包括：依赖，数据，配置文件，实用工具等。

Layer的优点

使用Layer可以使部署包保持较小，从而使开发更容易。可以避免在函数代码安装和打包依赖时可能发生的错误。对于Node.js，Python和Ruby函数，在Lambda控制台中开发函数代码，可以将部署包保持在3 MB以下。

  • 实现关注点分离：分离业务逻辑和依赖
  • 使函数代码更小，更专注于想要构建的内容
  • 加快部署速度，因为必须打包和上载的代码更少了，并且可以重用依赖

Layer的使用方式

在函数的配置中，最多可以引用五个Layer，其中一个Layer可以选择是runtime。调用该函数时，将按照您提供的顺序在 /opt 中安装Layer。顺序很重要，因为Layer都是在同一路径下提取的，因此每个Layer都可能覆盖前一个Layer。这个方式可用于自定义环境。例如，第一个Layer可以是runtime，第二个Layer可以添加所需库的特定版本。

Layer可以在AWS账户内使用，在账户之间共享，也可以与开发人员社区公开共享。

使用Runtime和Layer无需额外费用。

使用方式：

$ aws lambda update-function-configuration --function-name my-function \
--layers arn:aws:lambda:us-east-2:123456789012:layer:my-layer:3 \
arn:aws:lambda:us-east-2:210987654321:layer:their-layer:2
{
    "FunctionName": "test-layers",
    "FunctionArn": "arn:aws:lambda:us-east-2:123456789012:function:my-function",
    "Runtime": "nodejs8.10",
    "Role": "arn:aws:iam::123456789012:role/service-role/lambda-role",
    "Handler": "index.handler",
    "CodeSize": 402,
    "Description": "",
    "Timeout": 5,
    "MemorySize": 128,
    "LastModified": "2018-11-14T22:47:04.542+0000",
    "CodeSha256": "kDHAEY62Ni3OovMwVO8tNvgbRoRa6IOOKqShm7bSWF4=",
    "Version": "$LATEST",
    "TracingConfig": {
        "Mode": "Active"
    },
    "RevisionId": "81cc64f5-5772-449a-b63e-12330476bcc4",
    "Layers": [
        {
            "Arn": "arn:aws:lambda:us-east-2:123456789012:layer:my-layer:3",
            "CodeSize": 169
        },
        {
            "Arn": "arn:aws:lambda:us-east-2:210987654321:layer:their-layer:2",
            "CodeSize": 169
        }
    ]
}

详见官方文档：

https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html

注意：必须通过提供Layer版本的完整ARN来指定要使用的每个图层的版本。

可以对Layer进行版本控制以管理多个更新，每个版本都是不可变的。删除版本或版本的使用权限被撤销时，之前使用它的函数将继续有效，但您将无法创建新的函数。

对Layer的使用权限管理

Layer的来源可以有多种：

  • 来自单个AWS账号
  • 在多个账号之间共享使用
  • 公开发布，社区共享，如AWS提供的Python类库Numpy和SciPy

可以通过设置Policy对Layer的使用进行权限管理，包括对Layer自身的管理。

下面的例子授权用户可以对名字以 test- 开头的Layer进行版本的Publish/Get/Detele操作：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublishLayers",
            "Effect": "Allow",
            "Action": [
                "lambda:PublishLayerVersion"
            ],
            "Resource": "arn:aws:lambda:*:*:layer:test-*"
        },
        {
            "Sid": "ManageLayerVersions",
            "Effect": "Allow",
            "Action": [
                "lambda:GetLayerVersion",
                "lambda:DeleteLayerVersion"
            ],
            "Resource": "arn:aws:lambda:*:*:layer:test-*:*"
        }
    ]
}

下面的Policy通过在函数的 create 和 updateFunctionConfiguration 操作中加入条件，限制为只能使用来自 account 123456789012 的Layer：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ConfigureFunctions",
            "Effect": "Allow",
            "Action": [
                "lambda:CreateFunction",
                "lambda:UpdateFunctionConfiguration"
            ],
            "Resource": "*",
            "Condition": {
                "ForAllValues:StringLike": {
                    "lambda:Layer": [
                        "arn:aws:lambda:*:123456789012:layer:*:*"
                    ]
                }
            }
        }
    ]
}

详情见：https://docs.aws.amazon.com/lambda/latest/dg/access-control-identity-based.html#permissions-user-layer

Lambda Runtime

Lambda Runtime介绍

虽然AWS Lambda目前已经支持多种语言和版本，但是还有非常多的语言或者语言版本不被支持，为此AWS推出了Lambda Runtime来实现自定义Runtime。

理论上，任何可以兼容Linux的语言都可以通过开发对应的 Lambda 自定义 Runtime 的方式来提供。

Lambda Runtime是一个程序，当调用 Lambda 函数时，Runtime将运行该函数的handler方法。可以采用可执行文件（名为 bootstrap）的形式将Runtime包含在函数的部署包中。

Runtime负责运行函数的初始代码、从环境变量读取handler名称以及从 Lambda runtime API 中读取调用事件。Runtime会将事件数据传递到函数hanldler，并将来自handler的响应发回 Lambda。

Lambda Runtime Bootstrap

Runtime Bootstrap 是一个Linux兼容的可执行文件，在 Runtime HTTP API 和 要执行的函数之间扮演桥梁的角色，如下图所示：

Bootstrap需要负责 response/error 的处理，context 的创建和函数的执行。

Lambda Runtime的使用

可以在创建或更新函数时选择自定义runtime，自定义 Runtime 以 Lamdba Layer 的形式发布，所以通常函数的第一个Layer 往往是 runtime。

自定义runtime在标准 Lambda 执行环境中运行。它可以是 Shell 脚本（采用包含在 Amazon Linux 中的语言），也可以是在 Amazon Linux 中编译的二进制可执行文件。

要使用自定义runtime，需要将函数的运行时设置为 provided。而自定义runtime可包含在函数的部署包中，或包含在Layer中。Lamdba 将先在部署包中寻找 bootstrap 文件，如果没有找到，则在函数的Layer中寻找。

开发Lambda Runtime

可以采用任何编程语言实现 AWS Lambda Runtime，AWS目前推荐的方式是通过Lambda Runtime来为 Lambda 提供新语言或者新语言版本的支持。

AWS 表示：Runtime API是我们在Lambda中支持新语言的未来。

已提供的Layer和Runtime API

https://github.com/mthenw/awesome-layers

Awesome Layers 项目收集了目前可用的 Lambda Layers，按种类分为语言运行时(Java,Node,Rust,ballerina),工具(OCR,Format Convert),监控(Datadog,Epsagon Node,iopipe),安全(Protego,PureSec,Twistlock)。

总结

  • 关注点分离

    Lambda Layers 可以分离依赖和业务逻辑之间的关注点，让函数代码更加集中在业务逻辑

  • 加快部署

    因为依赖可以重用，部署包的大小可以大为缩减，减少空间占用和网络传输

  • 标准化

    Layer提供的功能和原来的类库等方式并无不同，但是在Layer的帮助下可以实现更好的依赖/组件标准化。包括以 Runtime API 形式出现的编程语言支持。

  • 提供容器/镜像外的另一个解决方案

    在不使用容器和镜像的情况下，Lambda Runtime API 和 Lambda Layers 之间的组合也可以实现容器和镜像的部分功能。

  • 可以配合容器使用

    即使有容器的支持，也可以结合使用 Layer 和 容器：可以根据实际需要选择是将依赖打包到镜像，还是使用标准 Layer。

参考资料

介绍文章：

Slides：

视频：

教程：

2.2 - Lambda资料收集

AWS Lambda项目资料收集

官方资料

官方文档

社区资料

学习资料

2016年

视频资料

3 - AWS Event Bridge

AWS Event Bridge项目

4 - 微软Azure Functions项目

微软Azure Functions项目

4.1 - Azure Functions

微软Azure Functions项目

Azure Functions 是一种事件驱动型计算体验，通过它可执行采用所选编程语言编写的代码，而不必担心服务器的问题。得益于按需扩展，绝不为闲置容量付费。

介绍

无服务器计算的介绍

暂时不考虑基础结构，更快地生成应用

无服务器计算的承诺

如果可以将所有时间都花在生成和部署强大应用上，而无需花时间管理服务器，这会有什么不同？由于为你托管了需要运行并缩放应用的基础结构，无服务器计算可做到这一点。将精力集中在业务上。将资源从基础结构管理重定向到创新，使应用更快上市。

什么是无服务器计算？

无服务器计算是服务器、基础结构和操作系统的抽象化。生成无服务器应用时，不需要预配和管理任何服务器，这样便可将注意力从基础结构问题上移开。无服务器计算由云中准实时发生的对事件和触发器的反应驱动。作为完全托管服务，服务器管理和容量规划对开发人员来说不可见，且仅基于消耗的资源或代码运行的实际时间计费。

为什么生成无服务器应用？

  • 从完全托管的服务获益

    减轻团队管理服务器的负担。通过利用完全托管的服务，专注于商业逻辑并避免繁重的管理任务。通过无服务器体系结构，只需部署代码，它随即就会以高可用性运行。

  • 灵活缩放

    无服务器计算从零扩展到瞬间（几秒钟内）处理数万个并发函数，可匹配任何工作负载，而无需进行缩放配置 - 它对事件和触发器做出准实时反应。

  • 只为使用的资源付费

    通过无服务器体系结构，只需为代码运行的时间付费。无服务器计算由事件驱动，一旦由事件触发资源后即会分配这些资源。仅通过次秒级计费方式，对执行代码所用的时间和资源收费。

备注：上面三个是serverless目前的主要卖点，大家的考虑和出发点都差不多，尤其是后面两个。

资料

核心概念

https://serverless.com/framework/docs/providers/azure/guide/intro/

无服务器框架可帮助您使用Azure功能开发和部署无服务器应用程序。 它是一个CLI，提供开箱即用的结构，自动化和最佳实践，使您可以专注于构建由 Functions 和 Events 组成的复杂，事件驱动，无服务器架构。

无服务器框架与其他应用程序框架不同，因为：

  • 将代码作为基础设施来管理
  • 支持多种语言（Node.js，Python，Java等）

以下是Framework的主要概念以及它们与Azure Functions的关系……

Functions

Function是Azure Function。它是一个独立的部署单元，就像微服务一样。它只是部署在云中的代码，通常用于执行单个作业，例如：

  • 将用户保存到数据库
  • 处理数据库中的文件
  • 执行计划任务

您可以在代码中执行多个作业，但我们不建议您在没有充分理由的情况下执行此操作。关注点分离是最好的，框架旨在帮助您轻松开发和部署Function，以及管理大量Function。

Events

触发Azure Function执行的任何内容都被框架视为Event。 Event是Azure功能上的平台Event，例如：

  • HTTP触发器（例如，用于REST API）
  • 预定计时器（例如，每5分钟运行一次）
  • 服务总线队列触发器（例如来自另一个Function的工作项）
  • 物联网/事件中心消息（例如，来自设备或服务的消息）
  • Webhook触发（例如，Github项目更新）
  • 和更多…

在无服务器框架中为Azure Function定义事件时，框架将自动将其转换为该事件所需的绑定，并配置Function以侦听它。

Services

Service是框架的组织单位。 您可以将其视为项目文件，但您可以为单个应用程序提供多个服务。 您可以在一个名为serverless.yml（或serverless.json或serverless.js）的文件中定义您的Function，触发它们的Event以及Function使用的资源。 它看起来像这样：

# serverless.yml

service: users

functions: # Your "Functions"
  usersCreate:
    events: # The "Events" that trigger this function
      - http: true
        x-azure-settings:
          name: req
          methods:
           - post
          route: /users/create
  usersDelete:
    events:
      - http: true
        x-azure-settings:
          name: req
          methods:
           - delete
          route: /users/delete

通过运行无服务器部署与Framework一起部署时，serverless.yml中的所有内容都会立即部署。

Plugins

您可以使用插件覆盖或扩展Framework的功能。 每个serverless.yml都可以包含一个plugins： 属性，可以有多个插件。

# serverless.yml

plugins:
  - serverless-plugin-identifier
  - serverless-another-plugin

插件是自定义JavaScript代码，用于在无服务器框架内创建新的或扩展现有命令。 无服务器框架只是核心中提供的一组插件。 如果您或您的组织有特定的工作流程，请安装预先编写的插件或编写插件以根据您的需要自定义框架。 外部插件的编写方式与核心插件完全相同。

mapping and routing events from multiple event sources to multiple target systems.

5 - Riff项目

Riff项目

5.1 - 安装riff

安装riff

安装CLI

Linux

在ubuntu16.04上安装：

sudo wget -q -O - https://raw.githubusercontent.com/starkandwayne/homebrew-cf/master/public.key | apt-key add -
sudo echo "deb http://apt.starkandwayne.com stable main" | tee /etc/apt/sources.list.d/starkandwayne.list
sudo apt-get update
sudo apt-get install riff

也可以直接下载安装，下载地址： https://github.com/projectriff/riff/releases

curl -Lo riff-linux-amd64.tgz https://github.com/projectriff/riff/releases/download/v0.1.1/riff-linux-amd64.tgz
tar xvzf riff-linux-amd64.tgz
sudo mv riff /usr/local/bin/

5.2 - Riff概述

Riff项目

riff logo

介绍

riff的介绍，看到一下几个说法：

  • riff is for functions
  • riff is a CLI for functions on Knative
  • riff项目建立在Knative项目的build，serving和eventing特征之上。

在riff的首页，看到三个描述：

  1. Functions are packaged as containers/ Function以容器方式打包
  2. Sidecars connect functions with event brokers / sidecar用event broker连接function
  3. Functions scale with events / Function随事件扩展

riff的网站：

资料

演讲资料

6 - Google Cloud Run产品

Google Cloud Run产品

6.1 - Cloudrun官方介绍

cloudrun官方介绍

Cloud Run介绍

备注：来自 cloudrun官方网站首页 的介绍，虽然有广告味道，不过还是能得到一些信息的。

首先是 Cloud Run 的简短介绍：

Run stateless HTTP containers on a fully managed environment or in your own GKE cluster.

在完全托管的环境或者自己的GKE集群中运行serverless HTTP容器。

介绍内容

  • 将serverless带入容器

    Cloud Run是一个托管计算平台，使您可以运行通过HTTP请求可调用的无状态容器。Cloud Run是serverless的：它抽象出所有基础设置管理，因此您可以专注于最重要的事情 - 构建出色的应用。它由 Knative构建，允许您选择运行容器的方式：使用Cloud Run的完全托管，或者在GKE上使用Cloud Run运行的Google Kubernetes Engine集群。

  • 容器在几秒钟内生产

    许多serverless平台有对语言，库的支持限制，甚至限制编码方式。通过允许轻松部署监听HTTP请求的任意serverless容器，Cloud Run使您能够以自己的方式编写代码。容器提供工作负载的灵活性和可移植性。使用Cloud Run，可以使用喜欢的依赖项和工具，以喜欢的语言构建出色的应用程序，并在几秒钟内完成部署。

  • 原生serverless

    Cloud Run使您可以运行serverless HTTP工作负载，而不必操心服务器。它抽象出所有基础设施管理，例如配置和管理服务器，因此您只关注编写代码。根据流量，它几乎可以立即自动从零开始向上和向下扩展，因此您无需担心规模配置。Cloud Run还仅针对使用的资源（计算到最接近的100毫秒）收费，因此您永远不必为超额配置的资源付费。

  • 一致体验

    将具有开发人员一致体验的serverless容器部署到完全托管的环境或您自己的GKE集群。Knative是一种基于Kubernetes的开放API和运行时环境，可以让您自由地在不同的环境和平台上移动工作负载：GCP完全托管，GKE，或Knative运行的任何地方。

点评：cloud run的介绍，强调的重点是"Container on serverless"，而不是以往的 “Function on Serverless”。cloud run 支持的是基于容器的工作负载，因此适用范围远远大于传统的FaaS。其次强调的是一致性的体验，在不同平台的可移植性，含蓄的表达了不会出现供应商和平台Lock-In。

特性

  • 开发简单

    简单的命令行和用户界面，可以快速部署和管理服务

  • 快速自动缩放

    Cloud Run会根据流量自动从零向上或向下扩展到N. 在GKE上运行时，自动扩展限制在GKE集群的容量范围内。

  • 托管式

    无需管理基础设施：一旦部署，Cloud Run将管理您的服务，以便您可以安然入睡。

  • 任何语言/库/二进制文件

    使用您选择的编程语言，任何语言或操作系统库，甚至自带二进制文件。

  • 利用容器工作流程和标准

    容器已成为打包和部署代码及其依赖项的标准。Cloud Run与容器生态系统配对很好：Cloud Build，Container Registry，Docker。

  • 冗余

    Cloud Run服务是区域性的，可跨多个区域自动复制

  • 集成的日志和监控

    与Stackdriver监控，日志和错误报告的集成，开箱即用，确保应用的健康。

  • 建立在Knative上

    Cloud Run构建于Knative开源项目之上，可实现工作负载的跨平台可移植性。

  • 自定义域名

    将您的服务映射到您自己的域名。

点评：和其他serverless托管服务相比，亮点主要还是对容器的支持带来的负载适用范围广泛。

选择适合的平台

Cloud Run使您可以灵活地在Google Cloud或Google Kubernetes Engine上运行服务。如果您已经在使用GKE，则Cloud Run可以部署到您的群集中，允许访问自定义计算机类型，额外的网络和GPU支持，以扩展Cloud Run服务的运行方式。最棒的是您可以稍后轻松改变主意，从Cloud Run切换到在GKE上的Cloud Run，反之亦然，而无需重新实现您的服务。

Cloud Run GKE上的Cloud Run
价钱 按使用付费（见下文）。 作为Kubernetes Engine的一部分提供。定价将在GA之前确定。
机器类型 每个实例一个vCPU，可以更改内存 GKE上的标准或自定义机器类型，包括GPU。
身份和政策 管理允许调用服务的身份（或允许未经身份验证的调用）。 将服务发布到Internet或仅将其提供给群集或VPC网络。
联网 无法访问VPC /计算引擎网络。服务不是Istio服务网格的一部分。 访问VPC /计算引擎网络。服务参与Istio服务网格。
网址 自动提供URL和SSL证书 自定义域仅包含手动SSL证书。

点评：cloud run是完全托管的版本，因此可以按照使用付费，可以提供各种集成，甚至，实际托管的knative实现很有可能和开源的 knative 不同。而GKE上的Cloud Run就没有这个自由度了，应该是用开源版本的 knative。

价钱

  • Cloud Run

    仅为使用的资源收取费用，计费到最近的100毫秒。

  • Cloud Run on GKE pricing

    GKE上的Cloud Run是Google Kubernetes Engine集群的附加组件。Cloud Run on GKE部署的工作量包含在您的GKE定价中。GRE上Cloud Run的最终定价将在GA之前确定。Google Kubernetes Engine的价格基于群集的预配资源。

Cloud Run计费模型

Cloud Run 的计费模型也颇具创新性：它不像 Fargate 那样完全按请求数目计费，而是将所有并发的请求算在一个计费单位内，这有望大大减低用户需要支付的成本。

https://cloud.google.com/run/pricing

Cloud Run仅针对您使用的资源收取费用，四舍五入到最接近的100毫秒。请注意，每个资源都有免费配额。总Cloud Run帐单将是定价表中资源的总和。

免费配额每月重置; 您只需支付超过免费配额的使用费。

可计费时间

对于给定的容器实例，可计费时间发生时

  • 容器实例正在启动
  • 容器实例正在处理至少一个请求

只有在容器实例上请求处于活动状态时分配的CPU和内存才会收费，并向上舍入到最接近的100毫秒。

如果容器实例同时收到许多请求，则可计费时间从第一个请求的开始开始，到最后一个请求结束时结束，如下图所示：

对于运行在GKE上的Cloud Run，由于GKE上的Cloud Run是Google Kubernetes Engine的附加组件。群集中运行的工作负载包含在Google Kubernetes Engine定价中。GRE上Cloud Run的最终定价将在GA之前确定。

6.2 - Google Cloud Run产品概述

Google Cloud Run产品概述

在旧金山举办的 Google Cloud Next 2019 大会上，Google Cloud Run正式发布。

Cloud Run是一个类似 Microsoft Azure ACI，AWS Fargate 的容器实例服务。但与 ACI 和 Fargate 这些基于虚拟机技术栈的实现不同，Cloud Run 服务是基于 Knative 的。而 knative 是 Kubernetes 原生的 Serverless 基础设施项目。

这是业界第一个基于 Knative + Kubernetes 的 Serverless 服务。

而且，cloud run 是运行于 gVisor 之上的。

7 - TriggerMesh EveryBridge项目

TriggerMesh EveryBridge项目

7.1 - TriggerMesh EveryBridge

TriggerMesh EveryBridge项目

8 - Solace Event Mesh

Solace Event Mesh项目

8.1 - Event Mesh概述

Solace Event Mesh项目

Solace介绍

官方网站：https://solace.com/ ， 口号：

“Building the digital backbone for real-time enterprises.” 为实时企业构建数字骨干

描述语：

Everything you need to get your business events streaming on an event mesh, plus what you need to discover, manage and govern them.

在 Event Mesh 上流式传输业务事件所需的一切，以及发现、管理和管理它们所需的一切。

pubsub+

Pubsub+ 号称 “The complete event management platform / 完整的事件管理平台”：

Event Broker

At the run-time data movement level, PubSub+ event brokers power an event mesh, a modern messaging layer that can be deployed across every environment and component of the distributed enterprise, to stream events across them all.

在实时数据移动级别，PubSub+ Event Broker 为 Event Mesh 提供支持，Event Mesh 是一种现代的消息传递层，可以在分布式企业的每个环境和组件中进行部署，并在他们之间流式传输事件。

Event Mesh Management

To manage the infrastructure, PubSub+ event mesh management and monitoring solutions make it easy to deploy event brokers, create event meshes, and optimize the health and performance of the event-driven system.

为了管理基础设施，PubSub+ Event Mesh 管理和监视解决方案可以简化部署Event Broker ，创建 Event Mesh 以及优化事件驱动系统的运行状况和性能。

Streaming Intergrations

At the integration level, PubSub+ APIs and Streaming Integrations provide a variety of on-ramps and off-ramps to the event mesh, including support for open standard protocols and APIs (MQTT, AMQP, JMS, REST) as well as proprietary messaging APIs to connect legacy and modern applications, edge streaming technologies (StreamSets, Striim, Adaptris, ASAPIO, Dell Boomi) to integrate 3rd party applications and connectors for technologies like Apache Kafka.

在集成级别上，PubSub+ API 和 Streaming 集成为 Event Mesh 提供了各种渠道，包括支持开放标准协议和API（MQTT，AMQP，JMS，REST），以及支持专有消息API以连接旧的和现代的应用程序，支持边缘流技术（StreamSets，Striim，Adaptris，ASAPIO，Dell Boomi）以为Apache Kafka等技术集成第三方应用程序和连接器。

Event Portal

At the application level, PubSub+ Event Portal gives developers and architects tools to design, describe and discover events within their system, and to see the relationships between applications and events, making event-driven applications and microservices easier to design, deploy and evolve.

在应用程序级别，PubSub+ Event Portal为开发人员和架构师提供了工具来设计，描述和发现系统中的事件，并查看应用程序和事件之间的关系，从而使事件驱动的应用程序和微服务更易于设计，部署和发展。

Security

PubSub+ Platform enables messaging architectures that deliver consistent multi-protocol client authentication and authorization security across the enterprise, deeply integrated with enterprise authentication services using a minimal set of components.

PubSub+ 平台支持使消息传递架构能够在整个企业范围内提供一致的安全性，包括多协议客户端身份验证和授权，并使用最少的组件集与企业身份验证服务进行了深度集成。

Cloud Console

All of the above features and capabilities can be accessed through a single Cloud Console with a single log-in, making it easy for architects, developers and other users to work, collaborate and drive the enterprise’s EDA mission forward.

上述所有特性和能力都可以通过单一登录的单个 Cloud Console 进行访问，从而使架构师，开发人员和其他用户可以轻松地工作，协作并推动企业的EDA远景向前发展。

8.2 - Pubsub+ Event Broker

Pubsub+ Event Broker介绍

Event Broker的自我介绍(来自官方资料)：

The only unified event broker technology available as run-anywhere software, purpose-built hardware, and a managed service that you can use together to stream events across your distributed enterprise.

唯一的统一事件代理技术，可作为随处运行的软件，专用硬件和托管服务使用，可以一起使用以跨整个分布式企业流式传输事件。

详细描述

  • Power Your Event-Driven Transformation / 支持事件驱动转型

    Solace PubSub+ Event Broker有效地跨云，本地和物联网环境流式传输事件和信息。PubSub+ 中的“ +”表示它支持除发布/订阅（publish/subscribe）之外的各种消息交换模式，包括请求/答复（request/reply），流传输（streaming）和重播（replay），以及不同的服务质量，例如尽力而为（best effort）和有保证的传递。 它可以作为设备，软件和服务使用。 所有选项均提供相同的功能和管理体验。

  • Build an Event Mesh and Share Data Everywhere / 建立 Event Mesh 并在任何地方共享数据

    PubSub+可让您连接事件代理以组成 Event Mesh —— Event Mesh 是一个架构层，可让您将事件从一个应用程序动态路由到任何其他应用程序，无论这些应用程序部署在何处（非云，私有云，公共云）），因此您可以连接和编排微服务，将事件从本地记录系统推送到云服务，并实现跨LoB和IoT的数字化转型。

  • Unlock your data – no matter where it is / 解锁数据–无论在何处

    将我们的API用于最流行的编程语言，或者使用您喜欢的open API和协议，以便您可以连接到任何应用程序，采用同类最佳的消息传递方法，而永远不会被任何技术锁定，包括我们。

三种部署选项

  • Cloud/云

    Event Broker:Cloud 是一项托管服务。 在几分钟内启动事件代理服务，扩展到任何级别，并将消息传递基础设施的运维留给我们。 提供免费服务。

  • Software/软件

    Event Broker: Software 可以很容易的部署在您喜欢的云，容器和iPaaS / PaaS环境中。 并且有一个免费的生产就绪版本。

  • Hardware

    Event Broker: Hardware 以紧凑的外形尺寸为您提供出色的性能和容量，并且具有交钥匙设备（turnkey appliance）的可运维性和较低的TCO。

优势所在

世界领先公司依赖PubSub+ Event Broker的更多原因：

您的系统已与业界最强大，经过考验的最可靠事件代理技术联系在一起，可以放心使用。 无论您具有本地记录的 ESB /消息系统，或者云原生服务和业务应用程序的本地数据库系统，还是甚至作为终端的Kafka集群，PubSub +都可以使您的架构体系结合在一起，从而受益于所有最佳技术。

详细展开：

  • Management & Governance / 管理 & 治理
    • Centralized administration / 集中化管理
    • Authentication, authorization and encryption of assets and information / 资产和信息的认证、鉴权和加密
    • Powerful and proactive monitoring and alerting, including integration with existing monitoring tools / 强大而主动的监控和告警，包括和现有监控工具的集成
    • Built-in high availability and automated disaster recovery / 内置高可用性和自动灾难恢复
  • Federated Architecture / 联邦架构
    • Routing across geographically distributed cloud and on-premises environments / 跨地理分布的云和本地环境进行路由
    • Dynamic, self-learning routing / 动态的，自我学习的路由
    • Fast, bandwidth-efficient routing over wide area networks / 在广域网上进行快速，高效带宽的路由
  • Capacity and Performance / 容量和性能
    • 28 million non-persistent and 6 million persistent messages/second per appliance / 每个设备每秒2800万非持久消息和600万持久消息
    • 1.75 million non-persistent and 235,000 persistent messages/second per software broker / 每个软件代理每秒175万非持久消息和235,000持久消息
    • Up to 200,000 concurrent IoT connections per appliance / 每个设备最多200,000个并发IoT连接
  • Advanced Messaging Capabilities / 高级消息能力
    • Message caching and replay / 消息缓存和重播
    • Sophisticated topics including wildcards / 复杂的主题，包括通配符
    • Prioritization, dead message queues / 优先级，死信队列
    • In-service upgrades / 服务中（不间断）升级

DMR

DMR 指 Dynamic Message Routing / 动态消息路由。

介绍来自： https://solace.com/wp-content/uploads/2019/02/DMR.pdf

DMR 的 功能描述简单说是：

Automatic distribution of events and subscriptions across many brokers to enable event mesh

在众多代理之间自动分发事件和订阅，以启用 Event Mesh

随着业务的增长，应用程序和微服务将变得越来越复杂，基础设施将分布在各种越来越多的环境中，包括本地数据中心，私有云，公共云和物联网。这引入了对事件驱动架构（EDA）的需求，该架构可以跨众多位置和接口动态路由信息。

动态消息路由（DMR）是一种自我学习的路由机制，可自动在 PubSub+ 事件代理之间分发订阅和事件，因此您的应用程序和设备可以共享信息，就像它们已连接到同一事件代理一样，而无需了解任何应用程序正在创建或使用数据。

开启 Event Mesh

Event Mesh 是一个架构层，它使来自一个应用程序的事件能够动态路由并被其他任何应用程序接收，无论这些应用程序部署在何处（非云，私有云或公共云）。 DMR通过连接环境内部或环境之间的 PubSub+ 事件代理来启用 Event Mesh。这使您可以轻松扩展环境中的容量或跨多个环境连接应用程序。

在云或数据中心内扩展容量

可以使用 DMR 快速增加任何云或数据中心内的代理容量。

使用DMR，您可以快速将新的HA组（Triplets / 三元组）连接到网络，以使它们自动获知所有订阅，包括持久性订阅和非持久性订阅，这样，感兴趣的消费者与其中任何一个相连都可以获取由任何生产者发布的事件。

启用分布式环境之间的数据流

可以使用DMR连接运行在不同云和数据中心中的代理，以便事件可以在它们之间流动。

一旦配置了双向DMR链接，订阅就会自动传播到企业网络中的所有其他代理。 然后，当应用程序发布事件时，事件会自动分发到世界各地的所有订阅的客户端。

监控

https://solace.com/products/monitor/

PubSub+ Monitor ：

Proactively monitor your brokers so that you can keep your finger on the pulse of mission-critical applications.

主动监视代理，以便可以随时掌握关键任务的应用程序。

Detect issues before they impact end users by using Monitor’s dashboards and alerts on critical broker metrics and events.

通过使用Monitor的仪表板和关键代理指标和事件的警报，在问题影响最终用户之前检测出问题。

获取需要的可行告警

根据预先配置的阈值和状态事件发送主动告警，以帮助运营团队定位开发问题并优化系统性能。

关键能力

  • 改善正常运行时间

    通过允许解决和系统、VPN和客户端相关的事件的主动警报，提高正常运行时间，性能和安全性

  • 持续优化

    通过收集代理指标和事件，并存储起来以进行分析和使用，来帮助优化性能

  • 看到趋势

    提供历史趋势和可行的见解，以优化终端用户服务

  • 避免集成麻烦

    消除了构建本地产品或购买第三方监控解决方案的需要

与现有的其他监视解决方案不同，PubSub + Monitor意味着：

  • 没有更多的选择

    实时收集指标和状态事件

  • 预配置

    包括许多预配置的阈值和警报

  • 易于部署

    采用无代理架构，因此您可以快速滚动

  • 一站式

    统一监视所有 PubSub+ 软件和硬件代理

消息缓存

https://solace.com/products/cache/

PubSub+ Cache的描述：

A scalable and flexible last value cache solution that PubSub+ customers count on.

PubSub+客户可信赖的可扩展且灵活的最终值缓存解决方案。

Group multiple PubSub+ Cache instances into a cluster to provide load balancing and fault tolerance.

将多个PubSub+缓存实例分组到一个群集中以提供负载平衡和容错能力。

“last value cache” 指的是缓存最后一个有效值。

为全球企业提供强大的缓存功能。

快速响应客户对最新发布数据的请求，同时每秒缓存数百万条消息。 将PubSub+缓存与PubSub+事件网格集成，并使用PubSub+ Manager对其进行管理。

Resiliency Need a reliable solution with low latency? We’ve got you covered. Deploy PubSub+ Cache in clusters and we’ll take care of the rest.

Speed & Scalability Service clients in real-time as your business grows in global and distributed environments. Cache almost 2 million messages/sec per instance and send up to 465,000 messages/sec to clients requesting cached messages. Add more clusters for even higher performance.

Flexibility Use your Solace API of choice to connect your subscribers. Add message plug-ins to examine, process and apply custom business rules to the data before caching.

9 - Pivotal Function Service项目

Pivotal Function Service

9.1 - Pivotal Function Service概述

Pivotal Function Service项目介绍

https://pivotal.io/platform/pivotal-function-service

特性

PFS特性介绍，来自PFS网站首页：

  • 可插拔构建系统

    PFS具有源到容器的机制，用于简化部署。 使用经过验证的组件如Cloud Foundry Buildpacks。

  • 可插拔Event Source

    PFS事件源有助于从各种外部事件源（如GitHub webhooks，blob存储和数据库服务）创建Feeds。

  • 可插拔Event Broker

    PFS可以与流行的消息代理轻松连接，如Kafka，Google Pub/Sub和RabbitMQ。 这些为消息传递通道提供了可靠的支持服务。

    备注：knative没有RabbitMQ的支持，难道是PFS扩展的？

  • 可插拔的Invoker

    Pivotal将继续在PFS中开发riff调用程序模型，使开发人员能够使用简单的语言惯用接口提供流和非流功能代码。

  • 事件扩展

    自动缩放，从0到1，从1到N个实例，然后返回到零个实例。

  • 在Kubernetes和Istio上运行

    PFS可以帮助您体现Kubernetes和Istio的优势，即使它抽象出两种技术的复杂性。

  • 使用带有函数的现代DevOps工作流程

    PFS允许您使用熟悉的，基于容器的工作流程来实现serverless方案。

  • 多语种

    PFS支持在您选择的框架中创建函数 - Node.js，Spring / Java，Go，Python和Shell。