需求背景

随着业务的发展，单体应用的缺点已经越来越明显了，逻辑复杂、模块耦合、代码臃肿，修改难度大，版本迭代效率低下； 系统启动慢，一个进程包含了所有的业务逻辑，涉及到的启动模块过多，导致系统的启动、重启时间周期过长；系统错误隔离性差、可用性差，任何一个模块的错误均可能造成整个系统的宕机；可伸缩性差；系统的扩容只能只对这个应用进行扩容，不能做到对某个功能点进行扩容；线上问题修复周期长；任何一个线上问题修复需要对整个应用系统进行全面升级。
适当的业务上拆分独立微服务化已经是迫在眉睫了。

主要需求：

1. 选择适合当前项目的微服务框架
2. 改动最小化

现有技术组件

• Akka Http、Akka、Slick（Lightbend技术栈,以前称为Typesafe）

Akka HTTP是基于Akka Streams 的Reactive Streams兼容工具包，它实现了完全异步且无阻塞的服务器端和客户端HTTP堆栈。Akka HTTP的编程模型提供了高级路由DSL和低级API。虽然它在后台使用了Akka Actors和Actor模型，但它的API对最终用户隐藏了这一点。

Akka HTTP是一组库，而不是Play和Lagom之类的框架-与浏览器的交互属于范围之内，但这不是其主要重点。Akka HTTP旨在通过集成层（而不是应用程序核心）实现灵活性。它包括对Akka Streams和Reactive Streams的流API的内置支持，而客户端API提供了相同的异步，非阻塞和流支持。

Akka是基于角色的，消息驱动的运行时，用于在JVM上管理并发性，弹性和弹性，并具有对Java和Scala的一流支持。Akka背后的编程模型基于Actor模型，而Akka Streams基于Reactive Streams提供了针对处理流数据而优化的模型。

Akka使用Actor模型，简化并行，提高资源的使用情况，提供集群功能，包括拆分，无冲突复制数据类型（CRDTs） ，GRPC，路由器等。它还包括Akka Streams，用于支持具有无阻塞背压的流数据，以及Alpakka，用于提供与各种外部技术集成的Akka Streams端点。

Slick简介（https://www.jianshu.com/p/928bacec577f）

Reactive简介

2014年，Lightbend联合创始人兼首席技术官JonasBonér与Reactive Manifesto定义并编纂了Reactive，该宣言现在有来自全球的24,000个签名者。该宣言已得到业界的广泛采用，并有效地提出了真正的云原生应用程序设计原则。

响应系统是：

响应式—超高性能，在任何情况下均基于用户和API交互提供即时反馈
弹性 —自动恢复和修复自身，以实现无缝的业务连续性
弹性 -能够根据需要在核心，节点，集群和Pod上按需灵活地伸缩

能够在维持高弹性的同时支持弹性的基本基础架构原则是，系统应：

消息驱动 -并行，异步，无阻塞地处理消息，以确保松散耦合，隔离和位置透明。（换句话说，服务可以在任何地方运行，并且可以与其他服务通信，而不必知道它们的物理位置—这是云原生设计的重要方面。）

Web框架

• Play（Reactive）
• Spring WebFlux（Reactive）
• Spring MVC（基于Servlet API）

微服务框架

Lagom（Reactive）

Lagom 是瑞典语，意为“恰到好处”。微服务通常被归类为小型服务。但是，Lightbend想要强调的是，在构建基于微服务的系统时，最重要的方面是找到服务之间的正确边界，使其与有限的上下文，业务功能和隔离需求保持一致。因此，它非常适合以域驱动设计为重点的思维方式。

遵循此步骤将有助于构建易于部署和管理的可伸缩性和弹性系统。根据Lightbend的说法，重点不应放在服务的大小上，而应该是大小合适的服务，即“ Lagom”大小的服务。Lagom 基于“ 响应式宣言”中定义的响应式原理，为开发人员提供了良好的默认值，可为开发人员提供后卫的方法，并在必要时允许偏离。

Lagom框架充当多个Lightbend框架的抽象层，由以下核心技术和框架组成：
Scala
Java
Play Framework
Akka and Akka Persistence
sbt
Cassandra
Guice
ConductR

核心概念

https://www.jianshu.com/p/dd4992723a82
https://www.jianshu.com/p/c1911c364dfc
https://www.jianshu.com/p/50dd47687423

Lagom发展历程

Lagom 1.0版本

Lagom依赖于某些sbt功能，因此支持其他构建工具并非易事。虽然支持Maven可能是可行的，但我们需要构建概念验证来验证这一点。

根据Lightbend的说法，Scala的构建工具“ sbt”为Lagom提供了许多方便的功能，例如快速增量重新编译，热代码重新加载，并行启动和停止服务以及自动注入配置默认值。Sbt被大多数Java开发人员视为障碍，因为它是Maven和Gradle（在较小程度上是Ant）），该规则统治了大多数Java项目。向诸如Lagom之类的微服务框架过渡已经构成了相当大的转变，因此我们认为这可能会阻止Java开发人员采用该框架。Lightbend的品牌重塑可以解释为从面向Scala的公司转向更具Java意识的公司。在这方面，降低初始学习曲线是有意义的，尤其是对于诸如构建工具之类的琐碎组件而言。毕竟，实现采用的最重要的事情是允许人们轻松地开始使用新技术。我们认为为Maven或Gradle提供集成将对采用率产生积极影响，尽管实现起来可能并不容易，但它应该有助于说服Java开发人员放手使用Lagom。

Lagom 1.1版本

2016年9月，Lightbend发布了Lagom 1.1。他们引入了Maven支持，其中还包括对在Maven中运行Lagom开发环境的支持。

Lagom 1.2版本

• Message Broker API和Kafka实现
• JDBC支持
• 通用读取侧支持，分片支持和自动偏移处理

Lagom 1.3版本

• Scala API for Lagom

Lagom 1.4版本

• Lagom 1.4还更新为Play（2.6）和Akka（2.5）的最新主要版本。
• Akka HTTP作为默认的服务器引擎
  Play 2.6引入了使用Akka HTTP而非Netty 实现的新默认服务器引擎。
• Lagom 1.4要求每个使用Cassandra持久性的服务在以下项中定义三个键空间配置设置

Lagom 1.5版本

• Akka 管理
  Akka Management是一套用于操作Akka驱动的应用程序的工具。Akka Management使用专用的HTTP端口来公开一些路由，从而可以远程检查Akka Actor系统的状态。
  Lagom提供了开箱即用的Akka Management HTTP端口。Lagom将默认添加运行状况检查路由。您可以重用库提供的运行状况检查，也可以自己插入。例如，Lagom使用群集状态来确定节点何时健康。这称为群集成员资格检查，由Akka群集HTTP管理库提供。
• GRPC
  Lagom 1.5引入了对跨服务gRPC通信的支持。gRPC是一个高性能的开放源代码通用RPC框架。最初的基于HTTP / JSON的传输并没有消失，相反，Lagom引入了gRPC，因此用户可以选择公开替代传输，从而增加其服务的采用率。Lagom对gRPC的支持是在Play-gRPC的基础上使用Lagom中的新additionalRouter功能构建的（请参见下文）。
• 其他路由器
  从Lagom 1.5开始，可以扩展您的服务公开的路线。因此，您的服务不仅会公开列出的呼叫，Service.Descriptor还将为所处理的端点提供服务additionalRouters。该文档涵盖了所有详细信息。其他路由器可以轻松扩展Service.DescriptorPlay本身支持的功能，例如上传文件。还有一个Lagom食谱详细介绍了这种用例。

Spring Cloud（资源很多，自行百度）

选型组合

1. Play + Lagom（Lightbend技术栈）
2. Spring WebFlux + Spring Cloud（Spring技术栈）
3. Spring MVC + Spring Cloud（Spring技术栈）

vs Spring

Lagom

在我看来，Lagom的开发环境极大地提高了生产力，使用单个命令启动所有微服务，代码热重载和表达性服务接口声明是Lagom高度重视开发人员生产力的一些示例。

建立良好的构建实践认为是Lagom的响应性服务，例如默认情况下为异步通信，ES / CQRS，...

Spring

Spring已经存在了10多年，随着Spring Boot和Spring Cloud的出现，一种趋势已经转向使用独立的应用程序，作为微服务开发的基础。Spring收获了Netflix OSS的成果，同时提供了Spring自己的组件，例如Spring Cloud Config和Spring Security。Netflix和Spring堆栈附带了用于在生产环境中构建和运行微服务的所有必要工具。

外部化配置，用于服务注册表的开箱即用免费仪表板，断路器监视和分布式跟踪，与Eureka，Consul和Zookeeper等服务注册表的集成，可用于Actuator端点的生产就绪的监视和指标功能，与构建工具的集成例如Maven和Gradle以及广泛的安全功能（包括即将与Vault集成）只是Spring提供的功能的一部分。

鉴于Lagom仍处于发展中阶段，Lightbend与Spring栈进行深入比较并不公平。我们希望Lagom将继续朝着更成熟的框架发展，并在各个层面上真正替代Spring。我们目前看到的第一步看起来很有希望，我们希望他们将考虑我们关于如何进一步发展框架的评论。很高兴看到更多的微服务框架可用，我们为Lightbend与Spring展开竞争而称赞。

Spring WebFlux vs Spring MVC

传统的Spring MVC基于Servlet，是阻塞式的，每次请求由一个线程处理。
Spring WebFlux不依赖于Servlet API，可以运行在基于Netty等网络服务器上。Spring WebFlux通过事件循环Event Loop的方式，由单个线程非阻塞的处理事件。当需要处理耗时任务时，Event Loop绑定的线程会新启线程来执行，完成后通知Event Loop。

相对于Servlet多线程的处理方式来说，Spring WebFlux在应对高并发的请求时，借助于异步IO，能够以少量而稳定的线程处理更高吞吐量的请求，尤其是当请求处理过程如果因为业务复杂或IO阻塞等导致处理时长较长时，对比更加显著。

结论

我们认为Lagom看起来很有前途，我们一定会跟进。由于Lagom是一个opinionated的框架，所以一切都可以很好地融合在一起。Lagom只是Akka和Play之上的一薄层，多年来非常成熟并且变硬。

尽管仍然有一些重要的事情需要解决，我们相信我们可以得出结论，Lightbend正在认真听取社区提供的反馈。他们继续通过新功能改进Lagom，并为开发人员提供更好的用户体验。

我们的建议是密切跟踪Lagom的进展。

如果您当前正在寻找具有几乎所有功能的集成功能的成熟框架，请使用Spring。

如果你的项目是传统web项目，比如说需要集成现有的Servlet包用于过滤拦截，推荐用Spring MVC + Spring Cloud，不然推荐Spring WebFlux + Spring Cloud，Reactive的框架具有性能更好、速度更快的优势。

参考资料

LAGOM：与SPRING CLOUD的第一印象和初步比较：(https://ordina-jworks.github.io/microservices/2016/04/22/Lagom-First-Impressions-and-Initial-Comparison-to-Spring-Cloud.html)
LAGOM 1.2：有哪些新功能？(https://ordina-jworks.github.io/microservices/2017/02/01/Lagom-1-2.html)
Lightbend播客：何时在项目中使用Play，Lagom或Akka HTTP: (https://www.lightbend.com/blog/lightbend-podcast-when-to-use-play-lagom-or-akka-http)
Spring MVC 过时了吗？(https://www.zhihu.com/question/294282002?sort=created)
WebFlux和SpringMVC性能对比(https://www.jianshu.com/p/24f824b878d9)
领域驱动设计DDD和CQRS落地 (https://www.jianshu.com/p/Tozpp3)
微服务的单体应用的优缺点对照(https://blog.csdn.net/liujianhuiouc/article/details/52711050)
sbt参考手册 (https://www.scala-sbt.org/1.x/docs/)