微服务架构是目前讨论最多的软件架构趋势之一，它永远改变了企业应用程序的构建方式。与过去缓慢、复杂的单一方法不同，各地的开发人员和公司都在转向微服务架构来简化和扩展他们的结构。
事实上，即使是亚马逊、Netflix、Spotify 和 Uber 等公司也已经完成了转型。
无论您是想开始使用微服务，还是只是对围绕它的争论感到好奇，您都来对地方了。今天，我将向您介绍您需要了解的有关微服务的所有内容，从实际示例到[架构模式]等等。
什么是微服务架构？
术语微服务没有通用的定义。微服务的最简单定义，也称为微服务架构，是一种使用松耦合服务构建应用程序的架构风格。这些集合或模块可以独立开发、部署和维护。
与传统上复杂的整体应用程序相比，它们以更快、更可靠的速度运行。使用微服务架构，任何规模的组织都可以发展为其能力量身定制的技术堆栈。
使用微服务有很多切实的好处，我们将在后面讨论，但是对于公司是否应该从单体架构转向微服务架构仍然存在一些争议。让我们检查一下两者之间的区别以了解辩论。
单体与微服务
单体架构是构建和部署应用程序的传统方式。这种结构基于一个单一的、不可分割的单元的概念，包括服务器端、客户端和数据库。所有方面都统一并作为一个单元和代码库进行管理。这意味着必须对同一代码库进行任何更新，因此必须更改整个堆栈。随着整体应用程序的扩展，它们会变得相当复杂，因此总体开发时间通常会更长。
另一方面，微服务架构将该单元分解为独立的单元，作为单独的服务运行。这意味着每个服务都有自己的逻辑和代码库。它们通过 API（应用程序编程接口）相互通信。
那么，您应该选择哪种架构？让我们分解一下。
选择单体架构
- 如果你的公司是一个小团队。 这样，您就不必处理部署微服务架构的复杂性。
- 如果你想要更快的启动。 单体架构需要更少的启动时间。该系统稍后需要更多时间来更新您的系统，但初始启动速度更快。
选择微服务架构
- 如果你想开发一个更具扩展性的应用程序。 扩展微服务架构要容易得多。可以非常轻松快速地添加新功能和模块。
- 如果您的公司更大或计划发展。 使用微服务对于计划发展的公司来说非常有用，因为随着时间的推移，微服务架构的可扩展性要高得多，也更容易定制。
微服务的优点和缺点
微服务架构成为贵公司更好选择的原因有很多。让我们讨论最显着的好处，然后检查一些缺点。
好处
提高可扩展性和生产力
大型团队通常必须在复杂的项目上协同工作。借助微服务，项目可以划分为更小的独立单元。这意味着团队可以根据领域逻辑独立行动，从而最大限度地减少协调和工作量。最重要的是，负责每个微服务的团队可以根据自己的需要做出自己的技术决策。
例如，只要接口功能正常，每个单元或容器的内部结构并不重要。因此，任何编程语言都可以用来编写微服务，因此负责的团队可以为队友选择最好的语言。
与遗留系统很好地集成
单体系统很难维护。许多遗留系统结构不良、测试不当或依赖过时的技术。幸运的是，微服务可以与遗留系统一起工作以改进代码并替换系统的旧部分。集成很容易，并且可以解决许多使单一系统成为过去的问题。
可持续发展
微服务架构创建的系统从长远来看保持可维护性，因为各个部分都是可更换的。这意味着可以轻松地重写微服务，而不会影响整个系统。只要适当地管理微服务之间的依赖关系，就可以轻松地进行更改以优化团队需求和性能。
跨功能
微服务最适合分布式团队。如果您的团队或多个部门遍布世界各地，微服务可提供必要的自由和灵活性以自主工作。可以快速做出技术决策，并在瞬间与其他服务集成。跨功能从未如此简单。
缺点
部署需要更多努力
微服务系统的操作通常需要更多的努力，因为有更多的可部署单元必须每个都被部署和监控。必须实施对接口的更改，以便仍然可以独立部署各个微服务。
测试必须是独立的
由于所有微服务必须一起测试，一个微服务可以阻塞测试阶段并阻止其他微服务的部署。需要测试的接口比较多，接口两边的测试要独立。
难以更改多个微服务
影响多个微服务的更改可能更难实施。在微服务系统中，更改需要多个协调部署。
微服务和 Docker
Docker和微服务几乎是同义词。微服务必须是可单独部署、可扩展的独立单元。但是，如果您为您的应用程序创建多个微服务呢？Docker 是用于部署微服务的轻量级解决方案。微服务可以打包到 Docker 镜像中，并作为 Docker 容器隔离。这样，您就可以构建独立于宿主环境的应用程序。
Docker 容器不是拥有自己的完整虚拟机，而是共享 Docker 主机上的操作系统内核。来自容器的进程出现在运行 Docker 容器的操作系统的进程表中。
要将 Docker 与微服务一起使用，您需要通过名为Dockerfile. Dockerfile 易于编写，因此推出软件也很容易。查看 Java 微服务的 Dockerfile 示例。
FROM openjdk:11.0.2-jre-slim COPY target/customer.jar . CMD /usr/bin/java -Xmx400m -Xms400m -jar customer.jar EXPOSE 8080 复制代码
一个典型的微服务系统包含多个 Docker 容器。协调多个 Docker 容器的系统需要配置虚拟网络。容器必须能够找到彼此才能进行通信。Docker Compose 环境可以通过链接联系另一台服务器，提供服务发现系统。
技术栈和架构模式
了解微体系结构的工作原理是一回事，而实际构建和实施它又是另一回事。这就是为什么我们要专注于为整个微服务系统提供的各种技术。让我们通过一些不同的技术堆栈、模式和设计来创建可执行的微服务架构。
微观和宏观架构决策
建议将您的架构分为微观和宏观架构。微架构涉及为每个微服务做出的所有决策。宏架构涉及在全局级别做出的所有决策，这些决策适用于所有微服务。
可以将微观和宏观架构的概念扩展到技术决策。 技术决策可以在宏观或微观架构的框架内做出。例如，看看要在数据库的微观和宏观层面做出的技术决策：
- 微： 每个微服务都可以有自己的数据库实例。如果数据库是在微架构中定义的，那么一个数据库的崩溃只会导致一个微服务的崩溃。这使得整个应用程序更加健壮。
- 宏： 数据库也可以定义为宏架构的一部分。多个微服务不得共享数据库架构。
独立系统
自包含系统 (SCS) 是一种微服务架构，它指定了宏架构的元素。这意味着它们不代表整个系统。由于 SCS 是独立的，它提供了实现域逻辑的一部分所需的一切，例如日志数据和 UI。SCS 也有一个可选的 API。
例如，用于微服务支付的 SCS 会将与该支付相关的信息存储为有界上下文。它还将实现 UI 以显示支付历史记录，并且有关客户的数据将从其他 SCS 复制。
将这些视为最佳实践的集合；SCS 提供基于既定模式的精确规则，为如何构建微服务架构提供参考点。所有这些规则确保一个 SCS 实现一个域，因此添加的功能只会改变一个 SCS。
我们可以将 SCS 视为微服务架构，因为它可以独立部署并将系统划分为独立的 Web 应用程序。事实上，一个SCS甚至可以拆分成多个微服务。它们在三个主要方面与微服务不同：它们比微服务更大，它们专注于松散耦合，并且它们必须具有 UI。
前端整合
微服务也可以与 Web 前端集成。将前端划分为不同的模块有助于解决将其视为整体的一些问题。模块化前端由可单独部署的微服务组成。这可以为您的前端带来很多好处。
例如，模块化的前端可以有独立的领域逻辑，领域的改变可以通过只修改一个微服务来实现。要组合单独的前端，必须将它们集成，因此需要一个集成系统。
这可以通过链接来实现，其中一个前端显示另一个前端读取和处理的链接。这也可以通过重定向来完成，例如 OAuth2 如何处理前端集成。重定向将数据传输与前端集成相结合。
但是，当前端应作为整体部署时，也有一些例外。例如，本机移动应用程序应该是部署单体，或者如果有一个单独的团队负责前端开发。
异步微服务
同步微服务在处理请求并等待结果的同时向其他微服务发出请求。异步通信协议发送接收者做出反应的消息，但没有直接响应。如果一个微服务在处理时不向其他微服务发出请求，或者它发出请求但不等待结果，则可以定义为异步微服务。
异步微服务为同步微服务提供了几个显着的优势，并解决了分布式系统的许多挑战。处理微服务请求所需的逻辑不依赖于结果，使它们更加独立。
同样，如果通信伙伴出现故障，它不会使整个系统崩溃，从而为您的系统提供整体弹性。最重要的是，加工和交付几乎总是有保证的。
异步微服务技术的一些常见示例是 Kafka（一种常用于消息传递的 MOM）、REST 和 Atom 数据格式（用于附加基础设施）。
微服务平台
微服务平台，如 PaaS 和 Docker 调度程序，支持微服务的运行和通信。这些技术支持微服务之间的通信以进行部署、日志分析和监控。
例如，这些平台支持具有负载平衡和服务发现功能的 HTTP 和 REST。微服务的实现只需要有限的运维支持，可以快速部署，支持多种微服务。
微服务平台代表了常见问题的简化和解决方案。一些著名的平台是[Kubernetes]和 Docker，这对于微服务操作非常重要。PaaS 和 Cloud Foundry 也很有用，但没有那么流行。
值得注意的是，迁移到这些平台需要更改应用程序的操作和安装，这可以使微服务平台的使用成为一个重要且及时的步骤。这是微服务平台的主要缺点。
