在旧金山举行的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