2016企业开发趋势：Lightbend关于JVM开发者的调查_Java_Michael Redlich

大咖直播-鸿蒙原生开发与智能提效实战！>>> 了解详情 



 写点什么

Lightbend 最近调查了 2100 个 JVM（包括 Java 和 Scala）开发者，进行了以下研究：

开发趋势和 IT 基础设施趋势之间的相互关系。
各家公司在怎样用最新技术实现他们的应用程序。
新兴技术的实际生产使用率统计分析。

报告全文题为：“2016 企业开发趋势：2100 个 JVM 开发者的云、容器和微服务分析”，分析了从使用重量级 J2EE 服务器到微服务和轻量级容器来构建应用程序，这个变革背后的主要驱动力。

如下图所示，参与调查的开发者来自于不同的公司：

调查主要得出了以下三个发现：

微服务和快速数据是现代应用程序开发的主要驱动力。
轻量级容器在使基础设施大众化，并且在挑战着 Java EE 应用程序服务器。
可移植性和弹性的优势在推动着“本地云”的进程。

当今的分布式服务都是为前所未有的大量数据而设计的，它们需要有更加弹性的、松耦合和可扩展的反应式系统。

这种向反应式系统演化的驱势可以从反应式宣言中找到答案：

发生这些变化主要是因为近年来对应用程序的需求已经急剧改变了。几年前，一套大型系统还会运行在几十台服务器上，命令响应时间要几秒钟，维护一次要停服几小时，数据以 GB 来计算。可现在应用程序已经到处都可以部署了，从移动终端到基于云的集群，上面运行着几千个多核处理器。用户希望得到毫秒级的响应，而且要 100% 在线。数据也开始用 PB 来衡量了。当今的需求已经不可能用过去的软件架构来满足了。

频繁的发布周期在保持对连续的数据的需求方面起着关键作用。如报告中所说：

如果你还需要 12 到 18 个月才能发布一次软件，可能你就已经退化回瀑布模型了。

微服务与快速数据

现在的企业应用在设计之初就都会关注实时数据和流。微服务是一个在应用开发中较新的趋势，起源于面向服务的架构。如报告中所说：

十年前，面向服务的架构（Service-Oriented Architecture，SOA）里面包含了许多和微服务相同的原则，在设计接口和解耦应用程序这些方面也做得很出色。但 SOA 没有全面成功的原因在于对基础设施的强调不够。现在到处都在采用微服务，原因在于除了服务隔离之外，它还包括了部署和生命周期方面的考虑，这些都是 SOA 没能处理好的问题。

C2B2 的首席咨询顾问 Matt Brasier 去年末就微服务和 SOA 之间的争执发表过一篇博客：

SOA 和微服务都是相同规则集的内容，只是应用在公司内的不同层。

微服务的存在也要归功于 SOA 原则为大家所接受。

SOA 与微服务之争的真正答案应该是它们分别适合于不同的解决方案，但因为产生的应用程序数量要远远多于企业架构的数量，因此微服务框架就显得比 ESB 更适合于你的项目。

Payara 和 C2B2 的创建者和董事 Steve Millidge 声称：

微服务与 SOA 没什么不同，它还是在说 SOA 那些事。

除此之外，调查结果也表明企业中向微服务迁移呈增多趋势，如下图所示：

去年末大家已经预见到了这种微服务的增长趋势，今年早期 InfoQ 也讨论了这一点：“2016 年将成为 Java EE 微服务之年”。

调查结果显示，如 Apache Spark、Apache Kafka 和 Akka 等为了满足持续数据的需求而设计的框架已经越来越受大家欢迎，如下图所示：

尽管微服务的增长趋势看着很有前途，在 Lightbend 的报告中却有一个关键点提到：

看起来微服务很容易运维，但事实真的如此吗？对于那些真的在生产环境中运行微服务的公司来说，有 34% 表达到对运维工具成熟度的担忧（在调查结果中，有 22% 表示运维工具的成熟度是微服务的主要挑战）。

InfoQ 讨论了从七个微服务反模式中学到的经验。 OpenCredo 的首席科学家 Daniel Bryant 谈到了微服务的七宗罪，以及如何避免它们。在这篇Basho博客上，Sean Kelly 也谈到了一些关于微服务的错误见解，而大家还常常以它们作为迁移到微服务的指引。在OverOps博客中, Alex Zhitnitsky 做了一次“对框架的彻底研究……来看明白它的实现，并了解它们到底是干什么的”。其中涉及到的框架有 Java EE 、Lightbend 的 Lagom 、Pivotal 的 Spring Boot 、 Dropwizard 和 Spotify 的 Apollo 。