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

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

InfoQ&＃xff1a;欢迎二位。你们能介绍一下你们是做什么的吗&＃xff1f;

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

Simon&＃xff1a;我是Reactor项目的软件工程师。

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

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

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

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

InfoQ&＃xff1a;你能介绍一下CloudFoundry是如何助力DevOps的吗&＃xff1f;

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

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

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

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

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

InfoQ&＃xff1a;为什么我们需要两个反应式项目&＃xff1f;如果我是一名Spring开发者&＃xff0c;我为什么要选择RxJava&＃xff1f;

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

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

\

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

\\

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

\

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

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

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

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

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

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

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

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

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

InfoQ&＃xff1a;与会者的组成是怎样的&＃xff1f;

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

InfoQ&＃xff1a;SpringOne大会未来有什么计划&＃xff1f;2018年将在哪里召开&＃xff1f;

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

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

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

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