vlambda博客
学习文章列表

添加 Spring Boot 执行器与向项目添加下一个依赖项一样 simple。在 Gradle 构建的文件中考虑以下依赖项：

compile('org.springframework.boot:spring-boot-starter-actuator')

在这里，我们依赖于一个事实，即库的实际版本及其所有依赖项 在 Spring Boot 物料清单（BOM）。

Spring Boot 执行器最初是在 Spring Boot 版本 1.x 中引入的，但在 Spring Boot 2.x 中已经改进了很多。目前，执行器在技术上是不可知的，并且支持 Spring Web MVC 和 Spring WebFlux。它还与应用程序的其余部分共享安全模型，因此它可以轻松地用于反应式应用程序并利用反应式编程的所有优势。

执行器的默认配置公开了 URL /actuator 下的所有端点，但这可以通过 management.endpoints.web.base 进行更改-path 属性。因此，在 application 启动后，我们可以立即开始探索服务的内部结构。

现在让我们回顾一下前面描述的主要问题 并看看如何在反应式应用程序中实现它们。

默认情况下，Spring Boot 执行器提供 用于系统监控、扩展和随时间演变的最有价值的信息。根据应用程序配置，它公开有关应用程序可执行工件（服务组、工件 ID、工件名称、工件版本、构建时间）和 Git 坐标（分支名称、提交 ID、提交时间）的信息。当然，如果需要，我们可能会在此列表中添加更多信息。

执行器通过/actuator/info 端点显示应用程序信息。一般来说，这个端点默认是启用的，但是它的可访问性可以通过management.endpoint.info.enabled property. 

我们可以通过以下方式配置 application.property 文件来添加一些暴露在该REST端点上的自定义信息：

info:
   name: "Reactive Spring App"
   mode: "testing"
   service-version: "2.0"
     features:
        feature-a: "enabled"
        feature-b: "disabled"

或者，我们可以通过注册实现 InfoContributor 接口的 bean 以编程方式提供类似信息。以下代码描述了此功能：

@Component
public class AppModeInfoProvider implements InfoContributor {        // (1)
   private final Random rnd = new Random();

   @Override
   public void contribute(Info.Builder builder) {                    // (2)
      boolean appMode = rnd.nextBoolean();
      builder
         .withDetail("application-mode",                             // (3)
                     appMode ? "experimental" : "stable");
   }
}

在这里，我们必须实现一个 InfoContributor接口(1)只有 contribute (...)(2) 方法， 提供了一个builder，可以用来添加 需要的<一个 id="id326206647" class="indexterm"> 信息使用 withDetail(...)(3)  builder方法：

图 10.1。 Canary 部署模式的一个示例。负载 balancer 根据版本将流量路由到服务实例

在讨论高级使用场景时，可以在进行金丝雀部署时利用执行器服务信息端点 ( https://martinfowler.com/bliki/CanaryRelease.html)。在这里，负载均衡器可以使用关于 服务版本的信息来路由传入的 流量。 

由于 Spring Boot 执行器不提供任何用于信息公开的反应式或异步 API，因此反应式服务与阻塞式服务没有任何不同。

系统监控的下一个基本点是检查服务健康状态的能力。在最直接的方法中，服务健康可能被解释为服务响应请求的能力。下图描述了这样的场景：

图 10.2。一个简单的健康检查的例子，而不是检查服务是否可用

这里的核心问题是该服务可能可以通过网络访问。但是，某些重要组件，例如硬盘驱动器（如果使用）、底层数据库或相关服务可能无法访问。因此，该服务无法完全发挥作用。从操作的角度来看，健康检查不仅仅意味着可用性状态。首先，健康的服务是一种安装了子组件并且也可用的服务。此外， 健康信息应包括允许运营团队尽快对潜在的故障威胁做出反应的所有细节。响应数据库不可用或可用磁盘空间不足的情况，将使 DevOps 能够采取相应的行动。因此，健康信息可能包括更多详细信息，如下图所示：

图 10.3。包含底层资源详细信息的运行状况检查示例

令我们高兴的是，Spring Boot 执行器提供了一种成熟的健康监控方法。服务健康的基本细节可以通过/actuator/health端点访问。此端点默认启用并公开。 此外，Spring Boot 执行器具有广泛的内置健康指标列表，用于最常见的组件，例如 Cassandra、MongoDB、JMS 和其他集成到 Spring 生态系统中的流行服务。

除了内置指标，我们还可以提供一个 HealthIndicator的自定义实现。然而，Spring Boot Actuator 2.0 最令人兴奋的部分是与 Spring WebFlux 和 Reactor 3 的正确集成。这种混合提供了一个用于健康指标的新 反应接口称为 ReactiveHealthIndicators。如第 6 章, WebFlux 异步非阻塞通信。以下代码使用新 API 实现自定义运行状况指示器：

@Component
class TemperatureSensor {                                          // (1)
  public Mono<Integer> batteryLevel() {                            // (1.1)
    // A network request here
  }
  ...
}

@Component
class BatteryHealthIndicator implements ReactiveHealthIndicator {  // (2)
   private final TemperatureSensor temperatureSensor;              // (2.1)

   @Override
   public Mono<Health> health() {                                  // (3)
      return temperatureSensor
         .batteryLevel()
         .map(level -> {                              
            if (level > 40) {
               return new Health.Builder()
                  .up()                                            // (4)
                  .withDetail("level", level)
                  .build();
            } else {
               return new Health.Builder()
                  .status(new Status("Low Battery"))               // (5)
                  .withDetail("level", level)
                  .build();
            }
         }).onErrorResume(err -> Mono.                             // (6)
            just(new Health.Builder()
               .outOfService()                                     // (6.1)
               .withDetail("error", err.getMessage())
               .build())
         );
   }
}

前面的示例代码显示了如何与可以安装在房屋中但可通过网络使用的外部传感器进行有线通信：

这样的监控方式可以让用户安排相应的动作，比如提出更换电池的罚单或发送通知 给管家 关于低电量状态。

成功监控应用程序的下一个重要部分是通过操作指标收集。当然，Spring Boot 执行器也涵盖了这方面，并提供对基本 JVM 特征的监控，例如进程正常运行时间、内存使用情况、CPU 使用情况和 GC 暂停。此外，WebFlux 提供了一些有关处理传入 HTTP 请求的统计信息。但是，为了从业务角度提供对服务中发生的情况的有意义的洞察，我们必须自行扩展运营指标。

从 Spring Boot 2.0 开始，执行器更改了用于度量收集的底层库，现在使用了千分尺库： https ://micrometer.io。

如果暴露， /actuator/metrics REST 端点会提供跟踪指标列表，并可以导航到所需的仪表或计时器，还提供额外的上下文 信息标签的形式。一个指标的摘要，比如 jvm.gc.pause，可能如下所示：

{
  "name": "jvm.gc.pause",
  "measurements": [
    {
      "statistic": "COUNT",
      "value": 5
    },
    {
      "statistic": "TOTALTIME",
      "value": 0.347
    }
  ],
  "availableTags": [
    {
      "tag": "cause",
      "values": [
        "Heap Dump Initiated GC",
        "Metadata GC Threshold",
        "Allocation Failure"
      ]
    }
  ]
}

与 Spring Boot 1.x 对应物相比，新指标端点的一个缺点是无法通过单个 REST 请求检索所有跟踪的指标摘要。然而，这可能只是一个小问题。

像往常一样，我们可以使用千分尺指标注册表自由注册新指标。在本章后面，我们将介绍此过程的机制，并将了解哪些操作指标对反应式应用程序有用。

同样，Spring Boot 执行器提供了两个 valueable 端点用于日志管理。第一个是 /actuator/loggers， 它允许在运行时访问和更改日志级别，而无需重新启动应用程序。此端点非常有用，因为在不重新启动服务的情况下切换信息粒度是成功的应用程序操作的重要部分。鉴于与反应式应用程序相关的复杂调试体验，切换日志级别和动态分析结果的能力至关重要。当然，用 curl 命令从控制台改变日志级别不是很方便，但是这个特性和Spring Boot admin配合得很好，它提供了一个漂亮的UI用于此类目的。

此功能可以启用或禁用 动态 生成 日志 由log()操作符" linkend="ch04">第 4 章，Project Reactor - 响应式应用程序的基础。以下代码描述了将事件推送到 SSE 流的反应式服务：

@GetMapping(path = "/temperature-stream", 
            produces = MediaType.TEXTEVENTSTREAMVALUE)
public Flux<TemperatureDto> temperatureEvents() {
    return temperatureSensor.temperatureStream()                  
                            .log("sse.temperature", Level.FINE)      // (1)
                            .map(this::toDto);
}

在这里， log() 操作符注册了一个带有 Level 的记录器 sse.temperature。很好(1)。因此，我们可以使用 /actuator/loggers 端点动态启用或禁用此记录器的输出。

另一方面，无需从远程服务器复制文件即可访问应用程序日志的能力可能是有利的。为了简化这一点，Spring Boot 执行器提供了一个 /actuator/logfile 端点，它通过 Web 公开带有日志的文件。 Spring Boot 管理员还有一个简洁的网页，streams 应用程序以非常方便的方式记录到 UI。

除了前面提到的 endpoints，Spring Boot 执行器还提供了大量方便的 Web 端点列表。正确的文档可从以下链接获得：https://docs.spring.io/spring-boot/docs/current/actuator-api/html。

尽管如此，这里还是列出了最重要的一些简要说明（所有端点都位于基本 Actuator URL /actuator 下）：

Spring Boot 执行器允许注册 自定义端点，这些端点不仅可以显示数据，还可以更新应用程序的行为。为此， 一个 Spring bean 应该用一个 @Endpoint 注解来装饰。要将读/写操作注册为执行器 端点，库提供了 @ReadOperation、 @WriteOperation和  @DeleteOperation 注解依次映射到 HTTP GET, POST 和 DELETE 分别。但请注意，生成的 REST 端点使用并生成以下内容类型：application/vnd.spring-boot.actuator.v2+json, application/json。

为了演示如何在反应式应用程序中使用此功能，让我们创建一个自定义端点，该端点使用 网络时间协议<报告当前服务器时间和时差/span> (NTP) 服务器。有时，此类功能有助于解决由于服务器或 network 配置错误而导致的与错误时间相关的问题。这对于分布式系统特别方便。为此，我们需要注册一个装饰有 @Endpoint 注解和配置 ID 属性的 bean（在我们的例子中是 server-时间）。我们还将通过一个带有 @ReadOperation注解的方法返回感兴趣的数据，如下：

@Component
@Endpoint(id = "server-time")                                        // (1)
public class ServerTimeEndpoint {
   private Mono<Long> getNtpTimeOffset() {                           // (2)
      // Actual network call to get the current time offset
   }

   @ReadOperation                                                    // (3)
   public Mono<Map<String, Object>> reportServerTime() {             // (4)
      return getNtpTimeOffset()                                      // (5)
         .map(timeOffset -> {                                        // (6)
            Map<String, Object> rsp = new LinkedHashMap<>();         //
            rsp.put("serverTime", Instant.now().toString());         //   
            rsp.put("ntpOffsetMillis", timeOffset);                  //
            return rsp;
         });
   }

前面的代码 示例 展示了如何使用 Project Reactor 中的反应类型创建自定义执行器 @Endpoint。上述代码示例可以解释为 如下：

使用自定义端点，我们可以快速实现动态功能切换、自定义请求跟踪、操作模式（主/从）、旧会话失效或与成功应用程序操作相关的许多其他功能。现在也可以以反应方式执行此操作。

在前面的部分中，我们介绍了 Spring Boot 执行器的基本要素并实现了我们的自定义反应式执行器端点。请注意，在公开有用信息时，Spring Boot 执行器也可能会泄露敏感信息。访问环境变量、应用程序的结构、配置属性、进行堆和线程转储的能力以及其他因素可能会简化试图破解我们应用程序的坏人的生活。在这些情况下，Spring Boot 执行器也可能会暴露私人用户的数据。因此，我们必须关心所有执行器端点以及通常的 REST 端点的安全访问。

由于 Spring Boot 执行器与应用程序的其余部分共享安全模型，因此很容易在定义主要安全配置的地方配置访问权限。例如，以下代码 仅 允许拥有 ACTUATOR/actuator/ 端点> 权威：

@Beanpublic SecurityWebFilterChain securityWebFilterChain(
   ServerHttpSecurity http
){return http.authorizeExchange().pathMatchers("/actuator/").hasRole("ACTUATOR").anyExchange().authenticated().and().build();}

当然，我们可能会以不同的方式配置访问策略。通常，对 /actuator/info 和 /actuator/health endpoints 提供未经身份验证的访问是合适的，这通常用于应用程序识别和健康检查程序，以及保护可能保存一些敏感信息或可能在系统受到攻击期间提供帮助的信息的其他端点。

另一方面，我们可以将所有管理端点暴露在一个单独的端口上并配置网络访问规则。因此，所有管理将 仅 通过内部虚拟网络进行。要提供这样的配置，我们所要做的就是为 management.server.port属性提供所需的 HTTP 端口。

概括地说，Spring Boot 执行器带来了许多简化应用程序识别、监控和管理的特性。通过紧密的 Spring WebFlux 集成，Actuator 2.x 可以有效地使用资源，这要归功于它的大多数端点都支持响应式类型。 Actuator 2.x 简化了整个开发过程，而不会造成很多麻烦，扩展了应用程序功能，整合了更好的默认应用程序行为，并使 DevOps 团队的生活更轻松。

尽管 Spring Boot Actuator 本身非常有用，但与自动收集监控信息并表示此类 信息< /a> 通过图表、趋势和警报以视觉形式呈现。因此，在本章的后面，我们将介绍一个名为 Spring Boot Admin 的便捷模块，它允许通过一个漂亮的 UI 访问多个服务的所有重要管理信息。

默认情况下，Spring Boot 执行器 configures Micrometer 收集最常用的指标，例如进程正常运行时间、CPU 使用率、内存区域使用情况、GC 暂停、treads 计数、加载的类和打开的文件描述符的数量。它还将 Logback logger 事件作为计数器进行跟踪。所有这些行为都由执行器的 MetricsAutoConfiguration  定义，并提供了关于服务指标的非常明显的图片。

对于响应式应用程序，执行器提供WebFluxMetricsAutoConfiguration，它添加了一个专门的WebFilter。此过滤器将回调添加到ServerWebExchange，以与请求处理完成的时刻相交。可以报​​告请求时间。此外，在指标的报告中，该过滤器以标签的形式包含请求 URI、HTTP 方法、响应状态和异常类型（如果有）等信息。通过这种方式，可以使用 Micrometer 库轻松测量 HTTP 请求的反应式处理。度量结果使用名为http.server.requests 的度量来报告。

同样，Spring Boot 执行器检测RestTemplate并注册 http.client.requests指标以报告传出请求。从 Spring Boot 2.1 开始，执行器对 WebClient.Builder bean 执行相同的操作。尽管如此，即使对于 Spring Boot 2.0，为WebClient 相关工作流添加所需的指标仍然很容易。下一节将解释这种方法。

除了其他有用的东西之外，Spring Boot 执行器还可以将通用标签添加到应用程序的所有Meter。这在多节点服务部署中特别方便，因为它可以让我们通过标签清楚地区分服务节点。为此，应用程序应该注册一个实现MeterRegistryCustomizer接口的bean。

在 Project Reactor 3.2 中，响应式类型Flux和Mono获得了一个metrics()运营商。这会在调用时报告有关流的操作指标。 metrics() 运算符的行为类似于 log() 运算符。它与 name() 运算符合作，构建目标指标名称并添加标签。例如，以下 代码演示了如何将指标添加到传出的 SSE 流：

@GetMapping(
       path ="/temperature-stream",
       produces = MediaType.TEXTEVENTSTREAMVALUE)public Flux<Temperature>events(){return temperatureSensor.temperatureStream()// (1).name("temperature.stream")// (2).metrics();// (3)}

在这里， temperatureSensor.temperatureStream()返回Flux (1 )，而 name("temperature.stream")  ;方法 为监控点添加一个名称(2)。 metrics()方法(3) 将一个新指标注册到MeterRegistry 实例。

结果，Reactor 库注册了以下计数器——reactor.subscribed、reactor.requested和以下计时器——reactor.flow.duration,reactor.onNext.delay，每一个都有一个标签（维度）叫做流带有temperature.stream 值。仅这些指标就可以让我们跟踪流实例化的 number、请求元素的数量、流的最大和总时间存在以及onNext延迟。

因为响应式 streams 通常在不同的 reactor 调度程序上运行，因此跟踪有关其运行的细粒度指标可能是有益的。在某些情况下，将自定义ScheduledThreadPoolExecutor 与手动指标检测一起使用是合理的。例如，假设我们有以下类：

publicclassMeteredScheduledThreadPoolExecutorextendsScheduledThreadPoolExecutor{// (1)publicMeteredScheduledThreadPoolExecutorShort(int corePoolSize,
      MeterRegistry registry                                         // (2)){super(corePoolSize);
      registry.gauge("pool.core.size",this.getCorePoolSize());// (3)
      registry.gauge("pool.active.tasks",this.getActiveCount());//
      registry.gauge("pool.queue.size",this.getQueue().size());//}}

在这里， MeteredScheduledThreadPoolExecutor类扩展了一个普通的ScheduledThreadPoolExecutor(1) 另外还接收一个MeterRegistry实例(2)。在构造函数中，我们注册了几个仪表(3) 来跟踪线程池的核心大小、活动任务数和队列大小。

只需稍加修改，此类执行器还可以跟踪成功和失败任务的数量以及执行这些任务所花费的时间。为此， 执行器的实现  还应该覆盖beforeExecute()和afterExecute()方法。

现在我们可以在以下反应流中使用这样的 instrumented 执行器：

MeterRegistry meterRegistry =this.getRegistry();

ScheduledExecutorService executor =newMeteredScheduledThreadPoolExecutor(3, meterRegistry);

Scheduler eventsScheduler = Schedulers.fromExecutor(executor);

Mono.fromCallable(this::businessOperation).subscribeOn(eventsScheduler)....

尽管这种方法非常强大，但它不包括内置的调度程序，如parallel()或弹性（）。为了检测所有反应器调度程序，我们可以使用自定义Schedulers.Factory。例如，让我们看一下这样一个工厂的以下实现：

classMetersSchedulersFactoryimplementsSchedulers.Factory{// (1)privatefinal MeterRegistry registry;public ScheduledExecutorService decorateExecutorService(// (2)
      String type,// (2.1)
      Supplier<?extendsScheduledExecutorService> actual          // (2.2)){
      ScheduledExecutorService actualScheduler = actual.get();// (3)
      String metric ="scheduler."+ type +".execution";// (4)

      ScheduledExecutorService scheduledExecutorService =newScheduledExecutorService(){// (5)publicvoidexecute(Runnable command){// (6)
            registry.counter(metric,"tag","execute")// (6.1).increment();
            actualScheduler.execute(command);// (6.2)}public<T> Future<T>submit(Callable<T> task){// (7)
            registry.counter(metric,"tag","submit")// (7.1).increment();return actualScheduler.submit(task);// (7.2)}// other method overrides ...};

      registry.counter("scheduler."+ type +".instances")// (8).increment();return scheduledExecutorService;// (9)}}

上述代码解释如下：

要使用 MetersSchedulersFactory，我们必须注册工厂如下：

Schedulers.setFactory(newMeteredSchedulersFactory(meterRegistry));

现在所有 Reactor 调度程序（包括在MeteredScheduledThreadPoolExecutor 上定义的自定义调度程序）都使用 Micrometer 指标进行计量。这种方法提供了很大的灵活性，但需要一些纪律来防止指标收集成为应用程序中最需要资源的部分。例如，即使仪表注册表中的仪表（计数器/计时器/仪表）查找应该很快，但最好将检索到的引用保存到局部变量或实例字段以减少冗余查找。此外，并非应用程序执行 的所有方面都值得一组专门的指标。通常，应用程序域和使用我们的常识有助于选择要监控的基本应用程序特征。

在响应式流中，即使没有内置支持，我们也可以轻松添加自定义监控逻辑。例如，以下代码说明了如何为 WebClient invocation 计数器代码> that 没有任何默认检测：

WebClient.create(serviceUri)// (1).get().exchange().flatMap(cr -> cr.toEntity(User.class))// (2).doOnTerminate(()-> registry
               .counter("user.request","uri", serviceUri)// (3).increment())

在这里，我们为目标创建一个新的WebClientserviceUri(1) ，发出请求并将响应反序列化到Userentity(2)。当操作终止时，我们手动增加一个自定义标签uri的计数器，其中值代表serviceUri(3)。

类似地，我们可以结合流钩子（如 .doOnNext(),.doOnComplete(),.doOnSubscribe(), or .doOnTerminate()) 与不同类型的千分尺（如 .counter()、.timer() 或 .gauge()) 来测量所需的操作反应流的特征，具有由代表不同维度的标签提供的足够详细程度的细节。

让我们回到我们的应用程序。整个 system 是基于 RabbitMQ 上的异步通信。正如我们可能从 第 8 章中了解到的， 使用 Cloud Streams 进行扩展< /em>，要建立与本地 RabbitMQ 实例的连接，我们所要做的就是提供两个额外的 Spring Boot 依赖项。此外，对于云基础设施，我们必须添加spring-cloud-spring-service-connector和spring-cloud-cloudfoundry-connector 依赖项。最后，我们必须提供如下代码片段中描述的配置和附加的@ScanCloud 注解：

@Configuration@Profile("cloud")publicclassCloudConfigextendsAbstractCloudConfig{@Beanpublic ConnectionFactory rabbitMQConnectionFactory(){returnconnectionFactory().rabbitConnectionFactory();}}

为了获得更好的灵活性，我们使用了@Profile("cloud") 注解， 它仅在云上运行时启用 RabbitMQ 配置，而不是在本地 在开发过程中。

除了简单的 RabbitMQ 配置外，还有一个稍微复杂的反应式数据存储配置。非反应式和反应式数据存储之间的概念差异之一是客户端或驱动程序。非反应式客户端和驱动程序很好地集成到 Spring 生态系统中，并经过许多解决方案的实战测试。相比之下，响应式客户端仍然是一个新事物。

在撰写本文时，PCF 版本 2.2 没有为 Reactive MongoDB（以及任何其他具有响应式客户端的 DB）提供开箱即用的配置。幸运的是，使用 Spring Cloud Connectors 模块，我们可以访问所需的信息并配置 Reactive MongoDB Client，如以下示例代码所示：

@Configuration@Profile("cloud")publicclassCloudConfigextendsAbstractCloudConfig{// (1)...@Configuration// (2)@ConditionalOnClass(MongoClient.class)//@EnableConfigurationProperties(MongoProperties.class)//publicclassMongoCloudConfigextendsMongoReactiveAutoConfiguration{...@Bean@Overridepublic MongoClient reactiveStreamsMongoClient(// (3)
      MongoProperties properties,
      Environment environment,
      ObjectProvider<List<MongoClientSettingsBuilderCustomizer>>
         builderCustomizers
    ){
      List<ServiceInfo> infos =cloud()// (3.1).getServiceInfos(MongoDbFactory.class);if(infos.size()==1){
         MongoServiceInfo mongoInfo =(MongoServiceInfo) infos.get(0);
         properties.setUri(mongoInfo.getUri());// (3.2)}returnsuper.reactiveStreamsMongoClient(// (3.3)
        properties,
        environment,
        builderCustomizers
      );}}}

以下是代码示例的说明：

在这里，我们从org.springframework.boot.autoconfigure.mongo.MongoReactiveAutoConfiguration扩展了一个配置类，并动态定制MongoProperties关于可用的cloud()配置。

遵循 Cloud Foundry 说明后，https:/ /docs.run.pivotal.io/devguide/deploy-apps/deploy-app.html 并适当配置 MongoDB服务，存储服务应该可用并且流数据应该存储在MongoDB中。

尽管 Pivotal Cloud Foundry 简化了整体部署流程，Spring Cloud 生态系统提供了全面的帮助，以最小化内部的配置量应用程序，我们仍然需要处理其中的一些。但是，我们可能记得第 8 章， 使用 Cloud Streams 扩展，有一个很棒的解决方案可以简化云的应用程序开发。该解决方案称为 Spring Cloud Data Flow。该项目背后的中心思想是通过用户友好的界面简化反应式系统开发。除了该核心功能之外，Spring Cloud Data Flow 还为不同的云提供商提供了广泛的实现列表，可以在以下链接中找到：https://cloud.spring.io/spring-cloud-dataflow/#platform-implementations。对于我们的用例来说，最重要的是 PCF 的实现。 Spring Cloud Data Flow 可以安装在 PCF 上，并提供开箱即用的无服务器解决方案，用于将管道直接部署到 PCF。

总而言之，作为 PaaS 的 Pivotal Cloud Foundry 为简化应用程序部署过程提供了广泛的支持，而开发人员所需的工作量最少。它为我们的应用程序处理许多基础设施职责，例如配置消息代理或数据库实例。此外，PCF 与 Spring Cloud Data Flow 集成得很好。因此，Reactive Cloud Native Applications 的开发成为开发者的梦想。