需求背景
随着业务的发展,单体应用的缺点已经越来越明显了,逻辑复杂、模块耦合、代码臃肿,修改难度大,版本迭代效率低下; 系统启动慢,一个进程包含了所有的业务逻辑,涉及到的启动模块过多,导致系统的启动、重启时间周期过长;系统错误隔离性差、可用性差,任何一个模块的错误均可能造成整个系统的宕机;可伸缩性差;系统的扩容只能只对这个应用进行扩容,不能做到对某个功能点进行扩容;线上问题修复周期长;任何一个线上问题修复需要对整个应用系统进行全面升级。
适当的业务上拆分独立微服务化已经是迫在眉睫了。
主要需求:
- 选择适合当前项目的微服务框架
- 改动最小化
现有技术组件
- 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(资源很多,自行百度)
选型组合
- Play + Lagom(Lightbend技术栈)
- Spring WebFlux + Spring Cloud(Spring技术栈)
- 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/)
网友评论