1.微服务的历史
微服务的概念源于 21 世纪初盛行的面向服务架构 (SOA)。然而,“微服务”一词本身直到 2012 年左右才出现,当时它开始在软件架构活动和软件架构博客上被讨论。
微服务的早期先驱包括 Netflix、Amazon 和 eBay 等公司。例如,2009 年,Netflix 开始从单体架构过渡到微服务架构,以更好地处理快速扩展的客户群。其他大公司也纷纷效仿,意识到单体架构模型在处理大规模复杂系统时存在局限性。
此后,微服务变得越来越流行,许多组织将其作为软件开发和部署实践的一部分。云计算的采用也是微服务发展的推动力,因为它提供了独立构建和部署单个服务所需的基础设施。
2.使用微服务的原因
-
可扩展性:微服务最显著的优势之一是其能够独立扩展。在单片系统中,如果一项功能需要更多资源,则必须扩展整个系统。然而,在微服务架构中,只需要扩展必要的服务。
-
弹性:如果单片架构中的一个组件发生故障,则可能导致整个系统崩溃。但是,使用微服务,如果一项服务发生故障,则不一定会导致整个系统崩溃,因此微服务是更具弹性的选择。
-
更快的部署和更新:由于每个微服务都可以独立部署,因此可以更快、更安全地推出更新和新功能。如果新功能导致问题,则只有包含该功能的微服务会受到影响。
-
技术栈的灵活性:每个微服务都可以使用最适合其需求的技术进行开发。这意味着团队可以选择最适合其特定任务的工具,而不受整个系统需求的限制。
-
针对持续集成和交付(CI/CD)进行优化:微服务与 CI/CD 等现代开发实践完美契合,可实现高效、持续的代码集成、测试和部署。
-
更容易维护和调试:与大型单片代码库相比,微服务更小、更集中,更容易理解和调试。
然而,需要注意的是,微服务并不是灵丹妙药。它们也面临着挑战,例如需要强大的服务协调、数据一致性和更高的复杂性。因此,在采用微服务架构之前,了解权衡利弊并确保它们适合您的特定环境至关重要。
Java 是用于构建微服务的最流行的语言之一,因为它具有强大的生态系统、强大的开发者社区以及与容器化和编排工具的兼容性。
3.微服务框架
3.1.Spring Boot
Spring Boot 是一个基于 Spring Framework 的项目。它提供了一种更简单、更快捷的方式来设置、配置和运行简单和基于 Web 的应用程序。它是用 Java 创建微服务的非常受欢迎的选择。
3.1.1.优点
- 快速开发: Spring Boot 提供了一种应用程序开发的方法,重点是减少设置新项目所需的时间和精力。这使开发人员可以立即开始编码,而不必担心配置。流行的初始化工具包已成为其他项目中许多类似工具的基础。
- 自动配置: Spring Boot 根据类路径上的库提供自动配置,这意味着需要更少的手动配置。
- 嵌入式服务器:使用 Spring Boot,您不需要将应用程序部署到 Web 服务器,因为它附带了 Tomcat、Jetty 或 Undertow 等嵌入式服务器,从而简化了部署过程。
- Spring 生态系统: Spring Boot 与更广泛的 Spring 生态系统(包括 Spring Data、Spring Security、Spring Integration 和 Spring Batch)顺利集成,从而更容易将这些功能包含在您的应用程序中。
- 微服务组件:由Netflix微服务工作演变而来,包括API网关、服务发现、断路器。
- 云原生:通过通用库和针对不同云提供商的特定支持,为构建云原生应用程序提供广泛支持。还可与 Kubernetes 编排接口。
- 庞大而活跃的社区: Spring Boot 社区非常活跃且庞大,这意味着在需要时更容易找到帮助、资源和库。
- 性能指标: Spring Boot Actuator 提供了开箱即用的基本生产就绪功能,无需您自己实现这些功能。
- 可测试性:为测试提供了强大的支持,包括特定的测试注解和用于集成测试的TestRestTemplate。
3.1.2.缺点
- 学习曲线: Spring Boot 虽然简化了很多,但需要相当多的 Spring 知识。如果您不熟悉 Spring 生态系统,学习曲线可能会很陡峭。
- 内存消耗: Spring Boot 应用程序比使用其他一些轻量级框架或工具包构建的应用程序消耗更多的内存。
- AoT 和原生镜像方面不够成熟:在这些领域不如 Quarkus 发达,但经过大量努力,正在迎头赶上。
- 自动配置可能过于广泛:在某些情况下,Spring Boot 的自动配置可能不符合您的确切需求,并且可能难以覆盖。
总之,Spring Boot 是构建可“直接运行”的独立生产级应用程序的绝佳选择。其庞大的生态系统,加上约定优于配置的便利性,使其成为使用 Java 构建微服务的首选。
3.2.Quarkus
Quarkus 是一个全栈、Kubernetes 原生 Java 框架,专为 GraalVM 和 HotSpot 量身定制,并基于领先的 Java 库和标准精心打造。它的主要承诺是让 Java 成为 Kubernetes 和无服务器环境中的领先平台,为开发人员提供统一的反应式和命令式编程模型。
3.2.1.优点
- 开发人员生产力: Quarkus 拥有一种开发模式,可提供实时编码和热重载功能,从而显著提高开发人员的生产力。对应用程序的更改会自动反映在正在运行的应用程序中,而无需重新启动。
- 快速启动时间和低内存消耗: Quarkus 大量使用 Graal 技术进行 AoT 编译和原生镜像,以实现快速启动时间和低内存占用。这对于需要快速启动时间且在空闲时可以缩减为零的函数即服务执行环境尤其有用。
- 基于标准: Quarkus 支持广泛的应用程序开发模型和功能,如 CDI、RESTEasy(JAX-RS)、Hibernate ORM(JPA)等。
- Kubernetes-Native:作为 Kubernetes 原生框架,Quarkus 简化了在 Kubernetes 集群上部署和管理应用程序的过程。
- 大型生态系统: Quarkus 通过其扩展模型支持广泛的库和框架,例如 Apache Kafka、GraphQL 等。
- 反应式和命令式编程: Quarkus 支持反应式和命令式编程模型,为开发人员提供了根据其用例灵活选择最佳模型的能力。
- 企业支持:由于 Quarkus 是 Red Hat 赞助的项目,因此它具有可靠的企业级支持,是企业的可靠选择。
3.2.2.缺点
- 相对较新:与 Spring Boot 等成熟框架相比,Quarkus 相对较新,但它附带大量文档。
- 有限的扩展:虽然 Quarkus 确实有一个扩展模型,但它可能不支持所有库和框架,尤其是一些小众或不太常用的库和框架。
- 学习曲线:如果开发人员还不熟悉 Quarkus 使用的库和标准,则可能会有一个学习曲线。
3.3.Micronaut
Micronaut 是一个现代框架,自称是 Spring Boot 的替代品。首席开发人员参与了 Graal 的开发,Micronaut 利用这些知识提供了优于 Spring Boot 的性能。它使用提前编译,结合不基于反射的 IoC 方法,提供极低的内存使用率和快速的启动时间。
3.3.1.优点
- 与 Spring 相比,内存消耗大大减少
- 非常快的启动时间提高了开发/测试周期的效率
- 提前编译在构建时检测 DI 错误
- 支持多种语言,包括 Java、Groovy、Kotlin
- 与 GraalVM 集成以进行提前编译
3.3.2.缺点
//TODO
3.4.Helidon
Helidon 是 Oracle 推出的一组用于编写微服务的 Java 库。它提供两种编程模型:Helidon SE(一种反应式、非阻塞 API 样式)和 Helidon MP(为熟悉 Java EE 的开发人员实现 MicroProfile)。
3.4.1.优点
- 轻量快速: Helidon 设计简洁、轻量,占用内存小,与较为臃肿的框架相比,有助于缩短启动时间、提高性能。
- 灵活的编程模型: Helidon 提供两种不同的编程模型:Helidon SE 用于函数式编程方法,Helidon MP 用于声明式、基于注释的方法。
- 可观察性: Helidon 内置了对健康检查、指标和跟踪的支持,这对于观察微服务的状态至关重要。
- 与 Oracle 云基础设施的本机集成:作为 Oracle 产品,Helidon 提供与 Oracle 云基础设施服务的无缝集成,如果您是 OCI 客户,这可能是一个很大的优势。
- 易于部署: Helidon 应用程序只是独立的 Java 程序,这简化了部署。它们也可以打包在 Docker 容器中并部署到 Kubernetes。
- 支持 GraalVM: Helidon 支持 GraalVM,可用于将 Java 应用程序编译为本机可执行文件,以缩短启动时间并降低运行时内存开销。
3.4.2.缺点
- 社区和支持:作为该领域的一个相对较新的参与者,Helidon 的社区不如 Spring Boot 等更成熟的框架那么大。这可能意味着资源更少、第三方集成更少、寻求帮助的人更少。
- 学习曲线:如果您还不熟悉反应式编程或 MicroProfile,那么可能需要学习 Helidon SE 或 Helidon MP。
总而言之,Helidon 是微服务框架领域一个很有前途的新产品,特别是对于那些喜欢响应式、非阻塞编程模型或基于 MicroProfile 的方法的人来说。
如果您已经使用或计划使用 Oracle 的云服务,它与 Oracle 云基础设施的紧密集成将使其成为一个绝佳的选择。
3.5.Chronicle
Chronicle Software 的微服务框架称为 Chronicle Services,是一个低延迟 Java 框架,旨在构建高性能分布式应用程序。
它们在性能、简单性和可靠性至关重要的金融和交易环境中尤其受到青睐。
3.5.1.优点
- 低延迟: Chronicle Services 专为必须高速处理的场景而设计,例如金融交易系统。
- 高性能:由于其高效的设计,Chronicle Services 每秒可以处理大量交易,使其适用于高吞吐量系统。
- 分布式系统:它们为创建分布式系统提供内置支持,允许各个组件通过网络协同工作。
- 简单易用且易于开发: Chronicle Services 的设计注重简单性,提供简洁直观的 API。再加上全面的文档,使开发过程更加顺畅和快捷。
- 可测试性:通过内置对单元测试和集成测试的支持,Chronicle Services 可以更轻松地在软件发展过程中维护其可靠性和完整性。
- 持久性和监控:它为数据持久性和系统监控提供了强大的工具,对于维护分布式系统的健康至关重要。
- 开发人员灵活性:它们提供了很大的灵活性,允许开发人员根据他们的特定需求实施定制解决方案。
3.5.2.缺点
- 缺乏社区和资源:与 Spring Boot 等其他更成熟的框架相比,Chronicle Services 的社区规模较小,可用的资源、教程和指南较少。
- 兼容性有限:虽然它提供了相当大的灵活性,但它可能与某些流行的库和框架不具备开箱即用的兼容性,这可能会导致额外的开发。
- 成本: Chronicle Software 是一个商业组织,虽然一些组件是开源的,但使用全套 Chronicle Services 将涉及许可费用。
它专注于高性能计算,是需要每秒处理大量事务的应用程序的绝佳选择。它提供了一套强大的工具来构建分布式系统,确保高效的数据持久性和系统监控。
尽管存在一些挑战,例如社区规模较小和学习曲线较陡,但它在性能关键型应用程序中提供的好处远远超过这些考虑因素。此外,Chronicle Software 的商业支持确保了专门的支持和持续改进。
对于需要高性能和管理迁移到微服务和云的复杂性的组织来说,Chronicle Services 是一个不错的选择。虽然传统上专注于交易系统,但 Chronicle Services 正在向其他市场扩展。这是一个绝佳的技术选择。
3.6.Vert.x
Vert.x 是一个事件驱动、非阻塞、响应式工具包,用于在 Java 虚拟机 (JVM) 上开发应用程序。它旨在轻松处理高并发性,非常适合微服务架构。
3.6.1.优点
- 事件驱动和非阻塞:通过有效处理并发请求帮助创建可扩展的微服务。
- 多语言:支持多种基于 JVM 的语言,如 Java、Kotlin、Groovy 和 Scala,为语言选择提供了灵活性。
- 轻量级和高性能:提供传统 Java 框架的轻量级、高性能替代方案。
- 分布式事件总线:通过简单的发布-订阅消息促进组件之间的通信。
- 开发人员友好:提供实时编码和热重载等功能,带来愉快的开发体验。
- 由 Eclipse 基金会支持:确保稳定性和持续改进。
使用 Java 创建微服务有很多种选择。评估性能、开发人员生产力、运营管理和生态系统兼容性等关键优先事项以找到最佳选择非常重要。
3.6.2.缺点
//TODO
3.7.Kalix.io
Lightbend 是市场上的新手。可以看作是其之前的微服务平台 Lagom 和 Web 应用程序平台 Play 的演变。基于 Akka 构建,Akka 是一种基于参与者的模型,用于处理单元之间的快速通信,该模型已在其他领域得到广泛应用。
Kalix 是一款商业产品,提供用于构建和运行云原生应用程序的 PaaS。其主要卖点是开发人员专注于业务逻辑,将其他一切交给 Kallix。它提供了少量相对高级的抽象:实体、动作、工作流和视图。
可以在本地构建和测试应用程序,然后将其部署到所选云提供商托管的运行时平台上。费用根据底层资源的使用情况计算,提供免费试用期,随后可以选择从按使用量付费到在 GCP 和 AWS 上基于安全沙盒的部署等定价计划。
Kalix 声称其性能数据非常吸引人:
读取延迟 6ms @ 1000 tps,12ms @ 15000 tps(99%ile)
写入延迟 8ms @ 1000 tps,20ms @ 15000 tps(99%ile)
3.7.1.优点
- 从一开始就专注于云原生应用
- 旨在缩短产品上市时间的开发环境
- 基于常用的 Akka 方法的水平可扩展性
- 内置安全性
- 支持多种语言(Java、Javascript、Typescript、Scala)
- 生产的托管平台,包括 SRE、DevOps 和 DB 管理员
- 根据使用情况定价
3.7.2.缺点
- 刚刚进入市场,尚未经过验证(尽管底层技术已被广泛使用)
- 非开源,因此社区较为有限
- 不太适合非云使用