SpringOne 2017：与 Pivotal 聊大会、Spring、Reactor、WebFlux 及其他

在旧金山举行的 SpringOne 平台大会上，我们采访了来自 Pivotal 的 Pieter Humphrey 和 Simon Basle。

InfoQ：欢迎二位。你们能介绍一下你们是做什么的吗？

Pieter：我负责 Spring 团队产品和市场方面的工作，比如提供视频在 YouTube 频道上播放，等等。

Simon：我是 Reactor 项目的软件工程师。

InfoQ：这次大会令人印象深刻。你们带来了很多很好的内容，你们是怎么找到这些讲师的？又是如何评选演讲内容的？以及如何向潜在的与会者进行宣传的？

Pieter：我们的挑战在于如何找到合适的主题，包括开源项目、基础设施开发相关的主题和应用开发相关的主题。在之前，我们还没有经历过这些。对于大多数人来说，他们习惯了参加开发者大会或者基础设施大会。要把这两种大会结合在一起，你需要面对一大帮人，他们有不同的兴趣点，他们可能会说“我对这个不感兴趣”，或者“为什么不能多讲一些这方面的内容”，所以要让每个人都满意是很难的。不过我觉得事情在往好的方面发展，人们开始意识到基础设施即代码，这是他们需要关注的东西。所以，把这些东西放在一个大会上就没有那么难了，比如用于应用开发的基础设施、敏捷、案例学习。这就是我们面临的最大的一个挑战。

InfoQ：这个世界正朝着 DevOps 的方向发展，我发现 DevOps 的发展有迹可循，我觉得这是不是要归功于 CloudFoundry 提供的 DevOps CI/CD 能力？

Pieter：是的，不仅仅是 CloudFoundry，Kubernetes 也是以容器管理为中心。事实上，CI/CD 是很重要的，我们在谈论这些平台时，你可能是以人们能够很好地实施 CI/CD 为前提。我们的产品在很大程度上也依赖了好的 CI/CD。这是一个巨大的挑战。

InfoQ：你能介绍一下 CloudFoundry 是如何助力 DevOps 的吗？

Pieter：Concourse 在前期取得了一定的成功。Jenkins 服务器是有状态的，所以无法将配置提交到代码版本控制系统上。而 Concourse 是无状态的，开发人员可以将配置管道提交到系统中，可以在任何时候重新创建 worker 节点。在开发人员看来，这是 Concourse 的优点之一。这种方式相当流行，管道即代码，基础设施即代码，一切皆代码。

InfoQ：不过我们从演讲中听到，Pivotal CloudFoundry 处理了很多 DevOps 管道细节，你能解释一下 PCF 是怎么做到的吗？

Pieter：我们看到 Kubernetes 在市场上很受欢迎，而在 Kubernetes 之前好几年，我们就已经在 CloudFoundry 中嵌入了一个容器管理系统。不管怎么说，Pivotal 的应用服务是对应用的高度抽象，PKS（我们正在开发的 Kubernetes 服务）就对容器进行了抽象。如果你是一名开发者，而且你只喜欢 CloudFoundry 好的一面，你的应用程序是无状态的，并且只有服务层，那么 PAS 就能够满足你的需求。但如果你想加入数据库，或者要使用 ElasticSearch，或者想要控制 TCP 流量、自定义端口，那么 Kubernetes 会是更好的选择。这是一个不断演化的过程，我们并不想做出万金油式的产品，我们知道一种方案只适用于某一部分场景。

InfoQ：Reactor API 似乎发展得很快，涵盖了很多内容，而且越来越健壮和成熟。你们是怎么做到的？你们是如何添加新特性的？你们是怎么知道这些特性有没有用的？你们是如何实现它们的？

Simon：实现是最困难的部分！因为我们的用户越来越多，他们的应用场景也在不断变化，他们会说“如果能够提供这种操作就好了”。我们欢迎来自社区的反馈。但我们首先要看看通过组合已有的操作是否能够满足用户的需求。这个库真的很强大，我们有很多基本特性，通过组合它们可以实现复杂的异步操作管道。但有时候会有人说“这太难调试了，或许你们可以提供新的操作”，这些建议我们也会采纳。当然，除此之外，也会有 bug 修复、特性改进和优化。 也有一些代码提交者不是 Pivotal 的员工，他们也会向我们提供反馈。比如 David Karnok，他负责 RxJava 的开发，同时也参与了 Reactor 项目。最初，他重度参与到项目中，设计了所有的下一代反应式组件。他现在仍然很活跃，大家可以在拉取请求上看到他给出的批注。 Reactor 没有像 RxJava 那样的历史包袱，这是 Reactor 好的一面，但两者都有它们好的地方，所以 David 继续活跃在 Reactor 项目上当然是一个好迹象。

InfoQ：为什么我们需要两个反应式项目？如果我是一名 Spring 开发者，我为什么要选择 RxJava？

Simon：它们其实是不一样的，RxJava 面向的是另一波人。事实上，RxJava 仍然支持 Java 6，这也是 Android 大量使用 RxJava 的主要原因，而 Reactor 的目标并不在 Android 上。如果你是做 Android 开发，那么可以使用 RxJava，而如果是做后端的 Spring 开发，那么可以选择 Reactor。但它们都遵循相同的反应式流规范，选择在于你自己。Spring 内部使用了 Reactor，但如果你要使用 RxJava Route 和 Flowable，那也没有问题。

InfoQ：我经常觉得需要用到 Flux 操作，Java 的可扩展性让我在必要的时候可以自己实现这类功能。是否可以使用 Reactor 来创建组件生成新的 Flux？

Simon：我们的目标是提供一系列高效的操作来满足大家的需求。如果你们看过 Reactor 的源代码，你会发现一些新的东西。我们使用了一些高级的模式，用户不需要自己去实现操作，因为那样太麻烦了，我们提供了一组反应式流 API，可以帮助用户来实现操作。但如果这些仍然无法满足你们的需求，那么就有点麻烦了。David 写了一些有关 RxJava2 的 Wiki，解释了他的实现模式，但那个很复杂，不到万不得已最好不要那么做。如果你们实在找不到你们需要的操作，可以尝试换一种方式来解决问题。或许可以进行组合操作，或者使用命令式的方式来处理。如果非要一个新的操作不可，那么可以在我们的问题跟踪系统里提交请求。

在今天的一个演讲中，有人建议增加一个 zip 操作，在第一个流结束时不结束 zip 操作，有点类似左连接 zip。目前还没有这样的操作，所以或许可以考虑增加一个。

InfoQ：我想你应该知道，如果能够通过现有的操作来组合出任意一种新的操作，那么你们的工作也就完成了。

Simon：是的，问题在于我们要知道需要提供哪些操作。要知道，命令式编程习惯会影响到我们寻找正确的解决方案。

InfoQ：在演讲中，你们在强调 Spring Web MVC 和 Spring WebFlux 的互操作性，我想这样可以降低学习门槛，我可以开发一个 Web MVC Controller，然后把它变成 WebFlux Controller，只需要把返回类型改成 Flux。这是出于技术决策还是市场决策的考虑？

Simon：我们尝试为不熟悉反应式编程的开发者提供良好的开发者体验。如果你有一个 MVC Controller，返回的是 Flux 类型，框架会知道怎样处理它。我们想尽可能逐步为开发者提供这种简单的开发体验。刚开始先迈出一小步，先从 Web MVC 开始，将返回类型改成 Flux。如果这样没问题，就继续，或者可以直接切换到 WebFlux，进入新的世界。

Pieter：是的，这更多是一种技术上的决策，我们尝试着从用户的角度看待问题，逐步帮助他们转向新的思维。

InfoQ：我觉得这是一个非常好的决策，学习反应式开发方式最难的部分就是如何克服陡峭的学习前，事实上，可以说它是一门新的编程语言。我们很感激你们所做的每一件。之前你们面向对象，后来又面向流，跨度非常大。

Pieter：是的。另一方面，我们也想说的是，并非所有的东西都是反应式的。我们可以做出自己的选择，这个世界不是非黑即白。

InfoQ：我发现大会有很多内容是关于流程的，比如敏捷，Vaughn Vernon 还提到了领域驱动设计，还有整个系列是关于 DevOps 的。

Pieter：我们试着多做一些架构方法论方面的演讲。我们是 Pivotal 实验室，所以会有很多演讲是关于敏捷、测试驱动开发、CI/CD。我希望能够看到更多这样的内容，谈论设计、架构、新的工具，开发者们如饥食渴地想听到这类演讲，所以我们会关注这一块。

InfoQ：与会者的组成是怎样的？

Pieter：他们大部分都来自美国，60% 是开发者，40% 来自其他领域，如 Ops、IT 管理、管理层，等等。我们也为他们准备了特定的内容，比如案例学习、技术故事等。

InfoQ：SpringOne 大会未来有什么计划？2018 年将在哪里召开？

Pieter：下一届将会在华盛顿举行，明年的 9 月 24 日至 27 日。我们想多去几个地方，东海岸、西海岸、东海岸中部，时间根据具体情况而定，一般在每年的最后一个季度。今年我们卖出了 3000 张票，也卖出了赞助广告位，地点在莫斯康会展中心。今年的规模是去年的两倍。你们可以看到基础设施即代码正在发展，你也看到有些与会者不仅仅是来看应用开发相关的内容，也是来看基础设施开发的相关内容。

InfoQ：对我的开发工作来说，Spring 已经变得与 Java 同样重要，我无法想象不使用 Spring 将会是怎样的一番景象。相信大部分 Java 开发者也有同感，Pivotal 为开发社区做的事情是非常有意义，而对于 Pivotal 来说这又意味着什么呢？

Pieter：是的。我们要教会客户如何实施敏捷，如果进行测试驱动开发，如何开发自己的平台。我们走向商业化的动机主要来自那些正在寻找 CloudFoundry 和 Bosh 这样平台的用户，在摆脱了应用程序开发的桎梏，他们还要做很多其他的事情，而这也这是我们的机会。我们的策略就是为开发者提供足够的价值，把他们留在我们的编程范式里，在我们的平台上可以很容易地运行他们的应用。对于小公司来说，他们或许不需要我们的产品，但大企业或许能从我们的平台中看到价值。

查看英文原文： SpringOne 2017 - Chat with Pivotal about the Conference, Spring, Reactor, WebFlux and Other Goodies