k8s

微服务框架选型

2020-01-17  本文已影响0人  walker_

需求背景

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

主要需求:

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

现有技术组件

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框架

微服务框架

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版本
Lagom 1.3版本
Lagom 1.4版本
Lagom 1.5版本

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/)

上一篇下一篇

猜你喜欢

热点阅读