将Java EE单体应用打造成微服务

本文涉及的产品
云原生网关 MSE Higress,422元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: 本文讲的是将Java EE单体应用打造成微服务【编者的话】如何将单体应用拆分成微服务相信是很多人共同的疑问,本文作者就技术和组织结构等方面为我们提供了一个思路,一起来看看吧~
本文讲的是将Java EE单体应用打造成微服务【编者的话】如何将单体应用拆分成微服务相信是很多人共同的疑问,本文作者就技术和组织结构等方面为我们提供了一个思路,一起来看看吧~

紧接着上篇 为什么微服务应该是事件驱动的介绍博客 ,我还想再花一些文章和篇幅就这块为我即将参加的一些演讲做些准备(与你相约 jBCNconf 在旧金山的Red Hat峰会 )。你可以通过在twitter上关注我@christianposta来跟进这个项目的最新进展。在本文里,我们将讨论第一部分,即如何拆分一个单体应用。

这些文章里我所深入探索的单体应用,教程案例取自 Ticket Monster ,它已经在很长一段时间内被当成是讲解如何使用Java EE和 Red Hat技术 来构建一个出色应用的经典例子。我们选用Ticket Monster是因为它是一个精心编写的应用,它在“作为教程不够详尽”和“作为例子来讲太过复杂”这两条线之间权衡的很好。它很适用于教学用途,而且我们可以具体以它为蓝本,就真实的样例代码来探讨某些方法的利弊。在进一步讨论之前,请先 仔细看一下相关域和当前架构

tm-arch.png


观看上述的现有架构,我们可以看到各项事物事先都已经被很好的拆分开来。我们有UI组件,业务服务,以及从其他各块很好地分离和解耦并且被打包成一个单独可部署文件(在这里是一个WAR文件)的长期持久化存储。如果我们仔细看下源代码的话,我们会看到它也拥有 类似的 结构 。倘若我们想要部署这个应用的话,任何组件有任何变动都意味着整个部署包的一次重新构建,测试和发布。推进微服务的其中一个先决条件便是组件的自治,这样一来他们便能够相对独立地进行开发,测试和部署,而无需中断系统的其他部分。因此,要是我们在这里就只是打造出不同层,然后将它们独立地部署下去会怎样?那样我们能否实现一些自治能力呢?

过去我们花了大量的时间论证这一类型的架构,而这些工作似乎是有意义的。我们希望能够按照各个组件自己的需求来进行扩展。如果我们需要处理更多的web请求那就向外扩展web层就好了。如果那些服务开始陷入瓶颈,那就扩展业务服务层。与数据库以及数据访问层打交道和管理维护对于整个应用/服务的其他部分而言是相对独立的。从中间层和数据访问中“解耦”出来UI逻辑是一个不错的指导原则,但是不要把它和必需的分层搞混淆了。

实践中的真实情况是所有这些“分层”的架构化组件,针对所有对它的单独关注来看很容易殒命于数据和数据库引发的怪问题。我们可以尽情地添加所需的CPU,中间件和UI,但是无论我们的网络、计算、内存等等变得如何快速,对于这类系统的瓶颈往往都在于域模型和最终的数据库的相互竞争。这里面的压力便是“域模型”———互联网公司所践行的微服务可能不会拥有像FSI或者保险、零售商那样复杂、模糊而又矛盾的域模型。比如,推特有一个简单的域:发布和展示推文。但是这一案例也会在大规模场景下变得复杂———一些企业正开始同时遭遇这两方面问题的困扰———域模型及其复杂性与如何扩展它同等重要(并且常常会
在努力扩展时有所妨碍)。所以如今你单纯想着“我们只要用一个像MongoDB这样的NoSQL数据库就能实现后端的扩展性”的话———你现在恐怕会遇到更多问题。

那说说我们的团队?像这样架构一个系统的另外一部分是因为这样我们就能在这些分层上分配各个专业的团队以不同的效率,在不同地方,用不同的工具等相对独立地进行工作。他们只需要和其他人共享一个接口,然后便能自主进行他们的工作。这里用到一点康威定律:

设计系统的组织,其产生的设计和架构等价于组织间的沟通结构。
不幸的是,我感觉它与事实恰好相反。这并不是说通过搭建这个架构,我们就可以创造这个机会来给团队专业化分工和提高效率。因为我们这样的组织结构反而会倒逼我们沿着这个系统架构演进。就像我们有很多独立的数据库团队,UI团队,安全,运维,QA,构建,以及发布等等。这正是我们过去十年来的组织结构。然而,如果你看下一些企业践行微服务的成功案例的话,你会发现 他们所组织的结构有些不太不一样

让我们一起来看看到底发生了什么。以Ticket Monster为例,业务要求我们改变所处理网站的管理方式。他们要求我们添加一些相关的额外字段来追踪音乐会在网站上添加和删除的频繁程度,因为他们想据此添加一些预测分析,基于时间,位置,天气等决定在未来添加该活动是否是一个好主意。如果业务想要给管理用户展示这个预测分析的话,这可能还会涉及到UI团队。这也必将涉及改变应用的业务逻辑层,并且它肯定会导致数据库的变动。我们想给我们的应用添加一些功能特性,而这引发了所有分层的波动效应,而更为重要的是,涉及到了整个团队。如今我们不得不需要项目经理为所有相关团队协调和跟进会议。我们需要在创建票单的时候保证UI和团队做什么事情不会让QA,安全,运维等全部介入。所有这一切造就了我们各个团队之间的复杂同步处境,而如今我们不得不协调我们分层的全部变动,构建和发布(并且一切都同时部署!)。这不是我们想要的那种自治。我们无法相互独立地做出变动,事实上,我们已经变得相当脆弱。

针对我们的Ticket Monster应用,让我们改为将功能切分成可拼接的各个“垂直频道”而不是以技术或者组织层面。每一个垂直频道有它自己的“UI”(或者UI组件),“业务服务”和“数据库”,它们用于管理网站的特定功能。(然而,在第一步里,我们将把UI留作一个单体,然后将它背后的模块切分开来。我们会回过头来切分UI,尽管这有其自己的挑战。)Ticket Monster还允许用户查看和预订音乐会票。让我们将这块功能切分到它自己的垂直频道里。它可能也有忠诚度,推荐,搜索,广告,个性化等等。我们将这些都切分到它们自己的垂直频道里,每个都拥有它们自己的数据库,UI,和集成点(REST服务,后端,等等)。如果我们需要对网站忠诚度这块功能做出变动的话,我不需要去重新部署整个单体的业务服务层或是任何相关的服务,比如搜索。我可以从UI到DB部署忠诚度这块的功能而无需再被迫触发其他服务的变动。在理想情况下,一个团队拥有和运维的每个服务都将如此。

next-arch.png


这给我们各服务之间的代码注入了更强的凝聚力,以及更多的自主权。而一旦你开始努力去理解切分业务功能到各个垂直频道的意义时,我们便可以探索一下针对每个垂直频道而言,什么才看起来像是它的 上下文边界 ;比如它在一个上下文边界里是否适用 CQRS 。又或者基于它的读/写模型(文档?关系型?图)应该适用哪种类型的数据库以及你是否偏向于一致性或者能够容忍数据的丢失/数据的不一致。再者可能看上去像的什么事务啊,补偿啊,认错啊,等等,以及诸如此类的...现在我们可以就单个服务怎样才是最好的这一问题作出这些决策,它不是单个分层或者一个单体的共同分母最小化。这也是我们在下一篇文章里将继续探索的内容!敬请关注!

原文链接:Carving the Java EE Monolith Into Microservices(翻译:吴佳兴)

原文发布时间为:2016-07-31

本文作者:吴佳兴

本文来自云栖社区合作伙伴Dockerone.io,了解相关信息可以关注Dockerone.io。

原文标题:将Java EE单体应用打造成微服务

相关文章
|
10天前
|
Kubernetes Cloud Native Java
云原生之旅:从容器到微服务的演进之路Java 内存管理:垃圾收集器与性能调优
【8月更文挑战第30天】在数字化时代的浪潮中,企业如何乘风破浪?云原生技术提供了一个强有力的桨。本文将带你从容器技术的基石出发,探索微服务架构的奥秘,最终实现在云端自由翱翔的梦想。我们将一起见证代码如何转化为业务的翅膀,让你的应用在云海中高飞。
|
11天前
|
Prometheus 监控 Kubernetes
Prometheus 在微服务架构中的应用
【8月更文第29天】随着微服务架构的普及,监控和跟踪各个服务的状态变得尤为重要。Prometheus 是一个开源的监控系统和时间序列数据库,非常适合用于微服务架构中的监控。本文将详细介绍 Prometheus 如何支持微服务架构下的监控需求,包括服务发现、服务间的监控指标收集以及如何配置 Prometheus 来适应这些需求。
36 0
|
1天前
|
Cloud Native 持续交付 云计算
云原生之旅:从传统应用到容器化微服务
随着数字化转型的浪潮不断推进,企业对IT系统的要求日益提高。本文将引导你了解如何将传统应用转变为云原生架构,重点介绍容器化和微服务的概念、优势以及实施步骤,旨在帮助读者掌握将应用迁移到云平台的关键技巧,确保在云计算时代保持竞争力。
12 5
|
5天前
|
存储 Java 程序员
优化Java多线程应用:是创建Thread对象直接调用start()方法?还是用个变量调用?
这篇文章探讨了Java中两种创建和启动线程的方法,并分析了它们的区别。作者建议直接调用 `Thread` 对象的 `start()` 方法,而非保持强引用,以避免内存泄漏、简化线程生命周期管理,并减少不必要的线程控制。文章详细解释了这种方法在使用 `ThreadLocal` 时的优势,并提供了代码示例。作者洛小豆,文章来源于稀土掘金。
|
7天前
|
数据采集 存储 前端开发
Java爬虫开发:Jsoup库在图片URL提取中的实战应用
Java爬虫开发:Jsoup库在图片URL提取中的实战应用
|
10天前
|
Java
java代码和详细的代码应用
代码块分为局部、构造、静态和同步代码块。局部代码块控制变量生命周期,例如 `int a` 只在特定代码块内有效。构造代码块用于创建对象时执行附加功能,避免构造方法中代码重复。静态代码块随类加载执行一次,常用于初始化操作。同步代码块确保多线程环境下方法执行的原子性,通过 `synchronized` 关键字实现。
22 3
|
10天前
|
算法 Java 数据库
Java 性能优化秘籍:在数字化浪潮中,让你的应用如火箭般飞驰!
【8月更文挑战第30天】Java 作为一种广泛使用的编程语言,其性能优化是开发者关注的重点。优化需基于对 Java 内存模型、垃圾回收及线程并发模型的理解。合理的垃圾回收算法与线程安全措施、锁机制的应用至关重要。实践中,避免不必要的对象创建可减轻内存压力;优化数据库操作,如合理使用索引和查询语句,同样重要。JVM 参数调优,如调整堆大小和垃圾回收器选择,也能显著提升性能。综合运用这些策略并通过持续测试与调整,可以使 Java 应用在高并发和大数据量场景下保持高效运行,提供流畅的用户体验。
29 3
|
10天前
|
Java UED 开发者
揭开Java性能提升之谜:异步编程如何让你的应用响应速度飞升?
【8月更文挑战第30天】随着互联网技术的发展,系统性能和用户体验成为关注焦点,异步编程因其能提高应用响应速度和吞吐量而在Java领域广泛应用。本文将详细阐述Java异步编程的概念与优势,并通过实战示例展示其在实际项目中的应用,如使用`Future`、`Callable`及`CompletableFuture`等接口和类实现异步操作,帮助开发者更好地理解和运用这一技术,以提升程序性能和用户体验。
11 0
|
9天前
|
C# 微服务 Windows
模块化革命:揭秘WPF与微服务架构的完美融合——从单一职责原则到事件聚合器模式,构建高度解耦与可扩展的应用程序
【8月更文挑战第31天】本文探讨了如何在Windows Presentation Foundation(WPF)应用中借鉴微服务架构思想,实现模块化设计。通过将WPF应用分解为独立的功能模块,并利用事件聚合器实现模块间解耦通信,可以有效提升开发效率和系统可维护性。文中还提供了具体示例代码,展示了如何使用事件聚合器进行模块间通信,以及如何利用依赖注入进一步提高模块解耦程度。此方法不仅有助于简化复杂度,还能使应用更加灵活易扩展。
23 0
|
9天前
|
开发者 C# 自然语言处理
WPF开发者必读:掌握多语言应用程序开发秘籍,带你玩转WPF国际化支持!
【8月更文挑战第31天】随着全球化的加速,开发多语言应用程序成为趋势。WPF作为一种强大的图形界面技术,提供了优秀的国际化支持,包括资源文件存储、本地化处理及用户界面元素本地化。本文将介绍WPF国际化的实现方法,通过示例代码展示如何创建和绑定资源文件,并设置应用程序语言环境,帮助开发者轻松实现多语言应用开发,满足不同地区用户的需求。
20 0
下一篇
DDNS