了解微服务架构

现代应用由一些独立构建的服务组成。这为解决问题和引入新功能提供了敏捷性和上市速度。

这种范式被称为微服务架构，尽管为完整应用而整合的服务数量可以是数百个（微服务），也可以是几十个（宏观服务）。还有一些新的术语也用于称为模态的模块化单体，而 Spring Modulith 就是一个例子。

尽管许多组织已经拥有微服务架构，但微服务部署的复杂性与日俱增，大多数组织仍在进行成功的部署。此解决方案手册尝试使用流行的 Spring Boot 平台以及 Oracle Database 的云基础设施、容器、Kubernetes 和后端即服务平台来简化现代微服务的构建和部署。

如果您希望设计一个多语言、可轻松扩展、易于维护和部署、高度可用且可最大程度减少故障的应用，则可以使用微服务架构设计和部署云应用。在微服务架构中，每个微服务都拥有一个简单的任务，并通过使用轻量级通信机制（例如 REST API 请求）与客户端或其他微服务进行通信。

下图显示了由多个微服务组成的应用程序的体系结构。

插图 microservice_architecture.png 的说明

微服务使您可以将应用设计为松散耦合服务的集合。微服务遵循无共享模式，并作为无状态进程运行。这种方法可以更轻松地扩展和维护应用程序。

API 层是微服务的所有客户端请求的入口点。API 层还允许微服务通过 HTTP、gRPC 和 TCP/UDP 相互通信。
逻辑层专注于单个业务任务，最大限度地减少对其他微服务的依赖。对于每个微服务，此层可以用不同的语言编写。
数据存储层提供了持久性机制，例如数据库存储引擎、日志文件等。请考虑为每个微服务使用单独的持久性数据存储。Oracle 提供包含多个可插入数据库的数据库容器，使微服务可以轻松地隔离数据，以实现安全性、高可用性和扩展。此外，SaaS 应用程序还可以安全地利用多租户。此外，融合数据库将各种数据整合到一个屋檐下，以便从数据中获得更丰富的洞察力。

通常，每个微服务都在一个容器中运行，该容器可提供轻量级运行时环境。

微服务和单体架构的区别

在开始使用微服务体系结构设计应用程序之前，您必须了解此体系结构与传统单体体系结构的区别。

应用程序设计侧重于解决业务需求和实施业务逻辑。在单体架构中，整个应用程序构建为包含所有业务逻辑的单个单元。在微服务架构中，业务逻辑组织为多个松散耦合服务。

下图显示了单体和微服务体系结构。

插图 monolithic_vs_microservice.png 的说明

下表汇总了微服务和单体体系结构之间的差异。

特性	微服务架构	整体架构
单元设计	应用程序由松散耦合的服务组成。每项服务都支持单个业务任务。	整个应用程序被设计、开发和部署为一个单元。
功能重用	微服务定义 API，向任何客户端公开其功能。客户甚至可能成为其他应用程序。	在应用之间重用功能的机会有限。
应用程序中的通信	为了相互通信，应用程序的微服务使用请求 - 响应通信模型。典型实施使用基于 HTTP 协议的 REST API 调用。	内部过程（函数调用）有助于应用程序组件之间的通信。无需限制内部过程调用数。
技术灵活性	每个微服务都可以使用最适合微服务设计解决问题的编程语言和框架进行开发。	通常，整个应用程序都是用一种编程语言编写的。
数据管理	分散：每个微服务都可以使用自己的数据库。	集中：整个应用程序使用一个或多个数据库。
部署	每个微服务都是独立部署的，不会影响应用程序中的其他微服务。	任何更改（无论大小）都需要重新部署和重新启动整个应用程序。
可维护性	微服务简单、专注且独立。因此，应用程序更容易维护。	随着应用程序范围的增加，代码的维护变得更加复杂。
弹性	应用程序功能分布在多个服务中。如果微服务失败，其他微服务提供的功能将继续可用。	任何组件中的故障都会影响整个应用程序的可用性。
可扩展性	每个微服务都可以独立于其他服务进行扩展。	即使业务要求仅缩放应用程序的某些部分，也必须缩放整个应用程序。

采用微服务体系结构的注意事项

在设计新应用时，请考虑适用于需要高度可扩展性、灵活性和可靠性的应用的微服务架构。您可以使用不同的编程语言和框架来开发每个组件。

如果您可以将应用程序的功能划分到聚焦服务中（每个服务范围有限），请考虑将单体应用程序迁移到微服务。对于无法迁移到微服务架构的复杂单体应用，请仅考虑将新功能开发为微服务。

服务之间的相互依赖关系可能会影响在服务重新部署期间应用程序不可用的情况。在应用程序设计期间解决任何此类相关性问题。

重构单个应用程序非常困难。如果您打算使用微服务体系结构，请从项目开始就对其进行规划。

在开发微服务时，请考虑分布式系统的复杂性，并记住远程调用很慢并且可能会失败。根据具体使用情形，必须在一致性、可用性和分区容差之间进行平衡。

为微服务架构所涉及的运营复杂性做好准备。我们建议在将单体应用程序移动到微服务体系结构之前满足以下先决条件：

快速预配：能够快速预配服务器
基本监控：能够检测服务问题和业务问题。服务问题包括服务可用性、功能错误和性能问题
快速部署应用：能够快速将任何服务部署到测试和生产环境中

确保微服务架构的优势大于成本。

关于微服务体系结构中的通信机制

在微服务体系结构中，服务在多个服务器上运行。这些服务之间的通信通过 HTTP、AMQP 和 TCP 等协议进行。HTTP/REST 和异步消息传递是最广泛使用的协议。

Web 服务的 REST API 通常使用 HTTP 协议。使用 HTTP 方法（如 GET、POST、PUT 和 DELETE），客户机可以使用统一的资源定位符 (URL) 访问和处理应用程序资源。

客户端通过 REST API 发送请求，该 API 表示应用功能的入口点。客户端可以直接或通过 API 网关与微服务通信。

API 网关模式为所有服务请求定义一个入口点。当客户端请求到达时，API 网关会将请求路由到相应的服务。

API 网关模式的一个变体是前端后端模式，该模式为每种客户机定义单独的 API 网关（例如，一个网关用于移动客户机，另一个网关用于 Web 应用程序）。

建议的做法是尽量减少服务之间的通信。当通信至关重要时，最好使用异步通信。发送请求的服务可以在不等待响应的情况下继续运行。

消息队列和流系统是提供异步通信的理想方法，当它们集成到数据库中时，它们为数据操作和发送消息提供事务语义。这使得微服务部署更简单、更可扩展。使用 REST API 可以使微服务之间的通信同步，并且通常会限制扩展。

关于必需的服务和角色

此解决方案需要以下服务：

Oracle Cloud Infrastructure Database （包括 Oracle Autonomous Database ）
适用于 Kubernetes 的 Oracle Cloud Infrastructure 容器引擎
Oracle Backend for Spring Boot and Microservices

这些是每项服务所需的角色。

服务名：角色	需要 ...
Oracle Cloud Infrastructure Database ：`SYSTEM` 或 `ADMIN`	在配置 Oracle Backend for Spring Boot and Microservices 时创建用于代理数据库访问的用户。虽然 `SYSTEM` 或 `ADMIN` 可以工作，但它们权限过高，不应在生产环境中使用。
Oracle Cloud Infrastructure Container Engine for Kubernetes :`CLUSTER_MANAGE`	创建 Oracle Cloud Infrastructure Container Engine for Kubernetes 集群和包含三个 worker 节点的节点池。
Oracle Backend for Spring Boot and Microservices:`ROLE_ADMIN`	安装 Oracle Backend for Spring Boot and Microservices。

要满足您的需求，请参阅 Oracle 产品、解决方案和服务。