红帽白皮书新鲜出炉!点击获取,让你的云战略更胜一筹! 了解详情
写点什么

微服务与 Java EE

  • 2016-01-08
  • 本文字数:2218 字

    阅读完需:约 7 分钟

时至今日,基于微服务的架构已经随处可见了。我们见识到了 Netflix 与 Amazon 等创新者是如何通过微服务来取得业务上的成功。不过,对于那些使用 Java EE 服务器,编写传统系统的开发者来说应该何去何从呢?我们一直所做的都是错误的么?我们该如何让技术设计能够适应于未来?

单体架构

首先,我们来看一下这些传统系统,或者说是单体应用。虽然单体这个词现在看起来颇有一种坏味道之感,但这确实是我们长久以来构建软件的方式。基本上,它指的是这样一个事实,即我们构建一个个应用来实现某些功能。单体指的就是 Java EE 或是一开始的 Java 2 Enterprise Edition 设计的目标。集中式应用可以进行伸缩与集群,但其设计却不一定具有弹性。在大多数时候,其失败场景都要依赖于底层基础设施与运维。

传统上,Java EE 应用遵循着一些核心模式,并且会分成 3 个主要的层次:展现、业务与集成。展现层会被打包到 Web Application Archives(WARs)中,业务与集成逻辑则会被划分到单独的 Java Archives(JARs)中。他们会被打包作为一个部署单元,即所谓的 Enterprise Archive(EAR)。围绕着 Java EE 的技术与最佳实践足以构建出设计良好的单体应用。不过,大多数企业级项目都不太关注架构。这也说明了为何有时设计良好的意大利面条是项目依赖与内部结构可视化的最佳方式。当这发生时,我们很快就会体会到一些严重的缺陷。由于一切都是耦合并且集成到一起的,因此即便进行一些非常小的变更也需要大量的工作(有时还需要重构),然后才能将修改过的部分放到产品中;同时,我们还需要从始至终非常小心地对应用进行测试。整个应用不仅仅只是一些程序化的构件:它还包含了很多部署描述符以及服务端配置文件,此外还有第三方环境的属性等。开发这些企业项目需要多个团队联手,需要很多人从更高的视角来审查整个项目。业务组件与领域大多数都是由既有的数据库设计或是业务对象定义所驱动的。

变更的高风险与将新配置引入到生产中的复杂性会导致发布频率变得越来越低。新的发布可能一年才有那么几次。甚至团队结构都会受到单体软件架构的严重影响。长久的测试周期就是最直观的证据。

微服务

时代在不断发展,下一代系统架构与设计在几年前出现了。随着集中式集成组件日益增长的复杂性以及应用之间连接的成本越来越高,人们开始寻求更加轻量级、更加富有弹性的解决方案,逐步开始放弃大型、重量级基础设施与设计。与之相伴的是 IT 部门开始重新审视应用服务器以及冗长的协议和接口技术。

对于那些基于 SOA 与 ESB 的项目来说,其服务实现回归到了更加敏捷的构件与服务中来。相对于智能路由与转换来说,微服务使用了简单路由,并且将逻辑封装到了端点本身当中。微服务是围绕单业务目标而展开的。虽然企业系统的设置让人感到非常烦恼,但对于微服务来说,最有效的运行时却并不一定是功能完善的应用服务器。它可能只是个 Servlet 引擎,JVM 已经足以作为一个执行环境了。运行时千变万化,编程语言的选择也是数量庞大的,因此这种开发模式很可能会成为另一种运维梦魇。甚至连开发者都可能会在定义微服务以及如何将这种设计应用到既有应用中迷失方向。微服务的设计目标是要形成小型、无状态、独立且自包含的应用。在理想情况下,可以将其部署到任何地方,因为部署本身已经包含了所有必要的组件。

微服务要足够小。不过,“小型”的定义是很主观的。可以使用一些估算方法如代码行数、功能点、用例等。不过一般来说,“小型”与尺寸之间并没有什么必然的联系。在 Building Microservices 一书中,作者 Sam Newman 就微服务尺寸的定义给出了一些技术:

  • 足够小,可以由一个小型的敏捷开发团队所拥有
  • 可以在一两个敏捷 Sprint(一般来说是 2 到 4 周)中完成重写
  • 其复杂度不需要对服务做进一步拆分

无状态应用在处理每个请求时只会使用请求所包含的信息。微服务必须要是无状态的,在处理请求时无需记住与外部系统之前通信的信息。微服务必须要能独立处理请求,它可以与生态系统当中的其他微服务协作来进行处理。比如说,在与其他微服务交互后生成报表的微服务就是个相互依赖的系统。在这种场景中,只向报表微服务提供必要数据的微服务可能是个独立服务。全栈应用本身是可以部署的。它拥有自己的服务器、网络、托管环境。业务逻辑、数据模型与服务接口(API / UI)必须是整个系统的一部分。微服务必须是个全栈应用。

创新与持续不断的改进是企业与企业级项目背后的助推器。如果没有创新,那些过时与昂贵的基础设施组件可能要比在他们上面运行的软件的生命周期还要长。老旧的中间件可能会超期服役,结果是只有少数供应商才知道如何开发它。落后于最新标准的平台栈可能会引入临时应急的解决方案,最终则会产生技术债务。将项目快速迁移到微服务的就是那些开源项目了。Netflix OSS、Spring、Camel、Fabric8 等都是很好的例子。借助于当下的 PaaS,我们可以更加轻松地操纵多语言构成的全栈应用,而 PasS 一般来说也是由诸如 Docker 和 Kubernetes 等开源项目所维护的。在这个快节奏的时代中,从开发到上线以及修复 Bug 的时间被大大缩短了。几乎没有多少企业还能够容忍几个月的产品周期,他们需要软件为业务创造更多的价值。对于那些完全由软件驱动的公司如 Uber、NetFlix、Amazon 等来说更是如此。我们需要针对灵活性与弹性来构建系统,而不仅仅是效率和健壮性。Java EE 并不会消亡,它会得到补充和完善。

如果对如何将 Java EE 应用演化为微服务感兴趣,那么请下载这本电子书。此外,还可以通过这里了解更多信息。

2016-01-08 11:004379
用户头像

发布了 88 篇内容, 共 258.1 次阅读, 收获喜欢 7 次。

关注

评论

发布
暂无评论
发现更多内容

阿里巴巴Java开发手册-日志规约

魏杰

第十二周学习总结

赵龙

第十二周总结

Linuxer

大数据简介&架构(一)

dony.zhang

大数据 hdfs hive YARN MAPRED

week12 作业

雪涛公子

架构师训练营第十二周总结

R20114

Flink从一致性检查点中恢复-14

小知识点

scala 大数据 flink

架构师训练营学习总结(大数据)

qihuajun

大数据课程笔记

superman

week12

强哥

极客大学架构师训练营

如何判断程序员的代码是否优美?

Garfield

代码质量 代码 代码优化 代码重构

第 0 期架构师训练营第 7 周作业 2 ----总结

fujin

大数据总结

周冬辉

大数据

week12 总结

雪涛公子

极客大学架构师训练营 0 期 week 12 作业

chun1123

大数据 hive

【架构师训练营】第 12 周作业

花生无翼

区块链技术创新应用势在必行 食品药品开启全链条溯源时代

CECBC

区块链 溯源 药品

打开 政务上链 应用场景

CECBC

区块链 数字身份 政务

后疫情时代 数字经济如何大显身手

CECBC

疫情 数字经济 数字技术

架构师训练营作业

qihuajun

大数据

GalaxyCreater

大数据

Go云原生应用实战系列(一)

田晓亮

云计算 微服务 云原生 Go 语言

架构师训练营第十二周作业

吴吴

第十二周作业

赵龙

大数据应用

GalaxyCreater

大数据

第 0 期架构师训练营第 7 周作业 1

fujin

极客大学架构师训练营 0 期 week 12 学习笔记

chun1123

大数据 学习

mapReduce

纯纯

Android的特殊攻击面(三)——隐蔽的call函数

OPPO安全

android 安全攻防 安全 函数

隐秘的MySQL类型转换

架构精进之路

MySQL

架构师课程第十二周总结

dongge

微服务与Java EE_语言 & 开发_张龙_InfoQ精选文章