如何使用 Java 构建微服务?

标签: java | 发表时间:2016-01-20 15:04 | 作者:OneAPM蓝海讯通
出处:http://segmentfault.com/blogs

【编者按】微服务背后的大理念是将大型、复杂且历时长久的应用在架构上设计为内聚的服务,这些服务能够随着时间的流逝而演化。本文主要介绍了利用 Java 生态系统构建微服务的多种方法,并分析了每种方法的利弊。

快速预览

  1. 在 Java 生态系统中构建微服务的策略主要有:container-less, self-contained 和 in-container;

  2. Container-less 微服务把应用程序及其所有依赖打包成单一的 jar 文件;

  3. Self-contained 微服务也会将应用及其依赖打包成单一的Jar文件,但它还包含可能含有第三方库的嵌入式框架;

  4. In-container 微服务会打包一个完整的 Java EE 容器,并且它的服务是在 Docker image 中实现。

基于微服务的架构设计是架构师和程序员们面临的一项新挑战。然而,随着语言及工具的不断更新,架构师们完全有能力征服这样的挑战。 Java 也不例外,本文探讨了使用Java生态系统来构建微服务的几种不同方式。

介绍

本文不会讨论微服务的好与坏,也不会建议你提前为微服务设计应用程序,或当它们出现在你庞大的应用中时,是否应该剥离这些微服务。

本文介绍的方法并不是唯一的,但应该可以达到抛砖引玉的效果。尽管本文的重点是使用 Java 生态系统来构建微服务,但这些概念同样可以转移到其它语言和技术中。

笔者把本文用到的方法命名为 container-less、self-contained 和 in-containe。这些名称或许不是非常正式,但足以区分相互间的差别。接下来,笔者会详细描述每种方法。

Container-less

在此方法中,开发者会将 JVM 之上的任何事物视为应用程序的一部分。

container-less 方法会启用所谓的单 jar 部署(也可称作“fat jar部署”),这也就意味着,应用程序及其所有依赖都会被打包成单一的jar文件,并且作为独立的Java进程运行。

如何使用 Java 构建微服务?

  $ java -jar myservice.jar

该方法的第一个优点就是当对应用的规模进行伸缩时,服务很容易按需求快速启动和停止;另一优点是方便部署,你只需要传递一个 jar 文件即可。

该方法的缺点就是库的兼容性。对于事务支持这类问题,你需要自己来实现,或必须引入第三方库才能实现。而后,如果你需要更多支持,例如持续性问题的支持,你就需要解决第三方库之间的兼容性问题。

Self-contained

另一种单 jar 部署就是使用一个嵌入式框架来构建服务。在此方法中,框架提供了所需服务的实现方法,开发者可以选择在项目中包括哪些服务。

你可能会认为这个方法与 container-less 完全一样,但笔者认为,两者的区别在于,self-contained 方法会提供一套相互兼容的第三方库。所以,该方法不存在库兼容性问题。

如何使用 Java 构建微服务?

该方法可能涉及 Spring Boot、Wildfly Swarm 之类的工具。

Spring Boot

在Java中, Spring BootSpring Cloud Netflix 项目对构建微服务提供了很好的支持。 Spring Boot 允许你选择各种 Spring 工具和其它流行的工具,然后把它们和你的应用打包成一个 jar 文件。 Spring Initializr 提供了一个简单的复选框列表来完成上面这些事。一个简单的Hello World服务示例如下: Gist Snippet

Wildfly Swarm

在 Java EE 中,和 Spring Boot 相对应是 Wildfly Swarm 。它允许你根据自己的需求挑选 Java EE 规范,然后把它们和你的应用程序打包成一个 jar 文件。这里有一个简单的 Hello World 示例: Gist Snippet

self-contained 方法的优点是你可以自主选择用于服务运行的项目。

这种方法的缺点是配置更加复杂,由于它在实际的服务中构建所需的容器功能,由此产生的 jar 文件也会稍大一些。

In-container

虽然在 Java EE 容器中部署微服务的开销似乎很大,然而,一些开发者认为,微服务中的“微”并不表示该服务的小或者简单。

如何使用 Java 构建微服务?

在这些案例中,将 Java EE 容器作为所需平台似乎是合适的。因此,你唯一需要的依赖就是 Java EE API 。注意,由于该依赖的实现是由容器提供的,因此该依赖项已经满足了,这也就意味着所产生的 war 文件是非常精简的,该服务的实现与上面 Wildfly Swarm 的例子是一样的: Gist Snippet

该方法的优点是,容器通过标准 API 提供了经过测试和验证的标准功能的实现。因此,开发者可以完全聚焦于业务功能,并在应用代码之外维护底层代码。

另一个优点是,应用程序代码不依赖 Java EE 应用服务器,无论该应用部署到 GlassFishWildFlyWebLogicWebSphere 还是任何与 Java EE 兼容的其他实现系统。

该方法的缺点是你需要把服务部署到容器中,这样就增加了部署的复杂性。

Docker

现在来谈谈 Docker 。通过把 Java EE 容器和服务实现打包到 Docker 镜像,你可以得到与单一 jar 部署相似的结果。唯一的不同是服务打包在 Docker 镜像中,而不是在 jar 文件中。

  Dockerfile
FROM jboss/wildfly:9.0.1.Final
ADD myservice.war /opt/jboss/wildfly/standalone/deployments

在 Docker 引擎中启动 Docker 镜像可以唤醒服务:

  $ docker run -it -p 8081:8080 myorganization/myservice

Snoop

细心的读者可能已经在先前的 Spring Boot 代码段中注意到了 @EnableEurekaClient 注解。该注解在 Eureka 中注册服务,使其能够被服务消费者发现。 Eureka 是 Spring Cloud Netflix 包的一部分,并且是一个极易使用和配置服务发现的解决方案。

Java EE 在外部并没有提供这样的功能,但是有一些开源解决方案可以使用,其中一个就是 Snoop它的功能与Eureka相似。要使 Java EE 微服务支持任务查找,唯一要做的是使用 @EnableSnoopClient 注解,如本例所示: Gist Snippet

总结

在构建微服务时, Java 是一个非常好的选择。本文中介绍的任何一种方法都可以实现微服务。当然,最好的方法还是根据服务需求而定。对于简单的服务, container-less 或者 self-contained 服务就是不错的选择。不过,借助 in-container ,开发者可以更快更简单地实现更高级的服务。无论针对哪种服务,Java 生态系统都能提供行之有效的实现方法。

(编译自: https://dzone.com/articles/building-microservices-with-java

OneAPM 为您提供端到端的 Java 应用性能解决方案,我们支持所有常见的 Java 框架及应用服务器,助您快速发现系统瓶颈,定位异常根本原因。分钟级部署,即刻体验, Java 监控从来没有如此简单。想阅读更多技术文章,请访问 OneAPM 官方技术博客
本文转自 OneAPM 官方博客

相关 [java 微服务] 推荐:

如何使用 Java 构建微服务?

- - SegmentFault 最新的文章
【编者按】微服务背后的大理念是将大型、复杂且历时长久的应用在架构上设计为内聚的服务,这些服务能够随着时间的流逝而演化. 本文主要介绍了利用 Java 生态系统构建微服务的多种方法,并分析了每种方法的利弊. 在 Java 生态系统中构建微服务的策略主要有:container-less, self-contained 和 in-container;.

微服务之间的最佳调用方式 - Java学习之道

- -
在微服务架构中,需要调用很多服务才能完成一项功能. 服务之间如何互相调用就变成微服务架构中的一个关键问题. 服务调用有两种方式,一种是RPC方式,另一种是事件驱动(Event-driven)方式,也就是发消息方式. 消息方式是松耦合方式,比紧耦合的RPC方式要优越,但RPC方式如果用在适合的场景也有它的一席之地..

初识微服务

- - ITeye博客
微服务架构越来越火,有必要学习一下. 软件开发过程中碰到什么问题. 一个简单的应用会随着时间推移逐渐变大. 在每次的sprint中,开发团队都会面对新“故事”,然后开发许多新代码. 几年后,这个小而简单的应用会变成了一个巨大的怪物. 一旦你的应用变成一个又大又复杂的怪物,那开发团队肯定很痛苦. 敏捷开发和部署举步维艰,其中最主要问题就是这个应用太复杂,以至于任何单个开发者都不可能搞懂它.

谈微服务架构

- - 人月神话的BLOG
其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性. 从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,但是本质还是紧耦合的,这关键的一个判断标准就是如果要将原有的业务系统按照模块分开部署到不同的进程里面并完成一个完整业务系统是不可能实现的.

微服务性能模式

- - 互联网 - ITeye博客
前言:基于微服务系统越来越普遍. 下面我们就来看看五种常见的特定微服务性能的挑战,以及如何应解他们. 背景:在IT界微服务架构为基础的系统越来越多, 每一个应用系统都集成了不同的组件和服务,几乎所有的特定业务应用程序都需要集成一个或更多的应用服务. 但是一个综合性系统集成不同的服务这无疑是一个巨大的挑战.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

从Excel到微服务

- - 乱象,印迹
Excel很老,Excel很土,Excel一点也不sexy;微服务新,微服务很潮门,微服务很高大上. 那么,Excel和微服务有什么关系. 上个月看了篇文章,The Unbunlding of Excel. 作者认为,对于初创公司(尤其是非“纯IT”初创公司)来说,Excel几乎包办各种工作. 想做轻量级的CRM,可用Excel.

微服务拆分之道

- - DockOne.io
微服务在最近几年大行其道,很多公司的研发人员都在考虑微服务架构,同时,随着 Docker 容器技术和自动化运维等相关技术发展,微服务变得更容易管理,这给了微服务架构良好的发展机会. 在做微服务的路上,拆分服务是个很热的话题. 我们应该按照什么原则将现有的业务进行拆分. 接下来一起谈谈服务拆分的策略和坚持的原则.

微服务之saga模式

- -
你已经使用 database ber service 模式. 每个service拥有自己的database. 一些业务事务会跨越多个service,所以你需要来确保data consistency. 例如,假设你正在构建一个电子商务网站,这个网站的用户的会有一个最大欠款限制,应用程序必须确保一个新订单不能超过用户的最大前款限制,但是orders表和customers表不在同一个数据库,所以应用程序不能简单的使用本地的ACID事务.

微服务安全简介

- - 掘金 架构
​由于其可扩展性、灵活性和敏捷性,微服务架构已经变得越来越受欢迎. 然而,随着这种架构的分布和复杂性增加,确保强大的安全措施变得至关重要. 微服务的安全性超越了传统的方法,需要采用全面的策略来保护免受不断演变的威胁和漏洞的影响. 通过理解核心原则并采取有效的安全措施,组织可以加强其微服务架构,并保护敏感数据和资源.