视频
微服务的 5 个误解
了解更多
Redis 8 发布了——而且它是开源的
了解更多
分享
因此，您已经评估了应用程序的现状，并得出结论认为采用微服务将改善整体性能和可伸缩性。太棒了。接下来是什么？在本文中，我们将概述微服务设计和实现的基本注意事项。
微服务是一种软件架构策略，它将应用程序分解为一组解耦的自主服务。这些独立的应用服务通过 API 相互通信。每个服务都由其自己的领域专家团队管理，这样每个软件开发团队都可以控制自己的开发周期，按照自己的计划进行测试和部署，使用自己的企业工具和资源，并加快产品上市速度。
我们的微服务架构关键概念深入探讨了这一概念的基础知识，并提供了一些入门的实用建议，包括评估贵公司采用微服务架构的合理性。现在是深入探讨细节的时候了。
设计微服务架构的第一步是了解现状，可以这么说。Developer.com 的十大微服务设计原则之一是单一职责原则，该原则要求每个服务都必须负责并将所有资源投入到微服务应用程序中一个且只有一个功能的成功开发中。
软件架构师应考虑进行领域分析，以规划如何对每个服务进行划分，以及哪些元素需要纳入应用程序堆栈。这种领域分析被称为领域驱动设计 (DDD)。它将实体模式和聚合模式等模式应用于单个有界上下文，以更精确地确定单个领域的边界。
正如作者和敏捷宣言签署者Martin Fowler 所解释的，DDD 是一种“以围绕对领域流程和规则有深入理解的领域模型进行编程为中心的软件开发方法”。换句话说，你应该围绕特定的业务功能构建每个微服务。
一旦确定了领域并勾勒出它们的边界，就可以定义最适合应用程序堆栈的变量了。
构建微服务技术栈有点临时性。你通常需要使用大量的工具、框架和编程语言，将所有这些实现到一个内聚但松散耦合的系统中。
选择工具时考虑这些变量
选择最适合微服务的编程语言取决于您对语言的熟悉程度、您需要的功能所对应的可用库，以及每种语言提供的功能集。显然，选择开发团队已经掌握的语言可以节省时间和精力。
根据 2021 年 JetBrains 关于微服务的调查，“微服务开发最流行的三种语言是 Java (41%)、JavaScript (37%) 和 Python (25%)。” 这些流行的编程语言都拥有大量的在线开发者支持、许多成功的应用程序开发案例、运行环境（例如 Node.JS）以及庞大的客户端库。
确保所选语言适合当前业务问题；例如，Python 在数据分析领域很受欢迎，而 JavaScript 是全栈开发的一个可靠选择。
在《Redis OM 客户端库介绍》中了解更多关于直观对象映射和高级客户端库的信息。
当您为微服务架构构建应用程序选择合适的数据库时，请始终将可伸缩性、可用性和安全性放在首位。选择最能支持您计划在微服务中使用的数据模型的数据库。您的技术栈应该能够扩展以处理任何应用程序负载，通过故障转移协议确保可用性，并保护应用程序免受任何恶意攻击。
有关为基于微服务的应用程序寻找高性能数据库的更多信息，请阅读《微服务与数据层》。
您的业务功能可能要求您的微服务对某些操作使用同步服务间通信方法，而对其他操作使用异步通信。可以使用多种通信格式和协议来协助微服务通信，包括 HTTP/REST、gRPC 和 AMQP。
对于异步通信，利用带有消费者组的流（Streams）的事件驱动消息代理可以帮助增强可伸缩性和可靠性，使应用程序能够增长，并且没有任何服务会变得不可用。
有关选择正确的通信工具和模式的更多信息，请参阅《如何选择同步和异步通信需求》。
每个微服务团队负责监控应用程序性能，这通常会使用日志和可观察性工具来跟踪操作状态。这使得开发人员和运维人员能够跟踪整个系统，从应用程序性能到消息代理流再到数据库资源利用。
使用消息代理时，考虑使用一个日志流，每个微服务都可以在其中发布消息。这样，您就可以将您偏好的日志和可观察性工具连接到该流，并异步监控您的应用程序，而不会降低速度。
在我们的博客文章《微服务的 5 个误解》中了解正确的监控资源如何应对系统复杂性。
希望您的微服务架构真正蓬勃发展？以下是五个微服务应用设计原则，供您在设计旨在确保最佳性能的架构时参考。
松耦合和高内聚都可以通过前面提到的单一职责原则来解释；为每个领域团队赋予一个单一职责有助于增强该领域内部的内聚性，讽刺的是，这将该服务内的所有功能整合得如此紧密，以至于它们本质上是密不可分的。每个服务都有其自己的领域专家和工具，但仍然可以通过 API 和其他协议相互通信。这很像不同部门的同事之间的互动方式：当有助于完成工作时，你们会互相分享信息，但不会就与他人无关的细节过于冗长。
业务应用程序很少是静态的。随着新的业务需求出现、行业假设改变以及技术能力提供更多功能，软件也会发生变化。微服务应该能够演进并在需要时适应新的需求。
响应变化是敏捷宣言的基础之一，这是有充分理由的。世界在变。人在变。您的软件也应该如此。
实现微服务的一个原因是它们能够自动化改善整体可伸缩性的流程。借助 Kubernetes 等容器编排系统，您可以将微服务的整个数据库与微服务一起从单个镜像部署。借助Kubernetes 控制器的帮助，这些可移植性优势可以帮助 DevOps 团队管理、调度和协调自动容器部署。
实现微服务要求任何给定应用程序中的服务都维护自己的去中心化数据。服务边界应该将任何单个服务相关的所有逻辑和数据与应用程序中的其他服务隔离开来。
这与允许容器化微服务进行独立部署的逻辑相同。根据Red Hat 的说法，这个原则也有反对者，他们认为该原则会导致数据冗余的泛滥。但是，建立这些明确边界的最大好处之一是：“当微服务拥有自己的数据时，任何异常行为都被限制在该微服务内部。” 谁还需要猜测呢？
中断会发生。应用程序服务会在没有警告的情况下宕机。寻找光纤的挖掘机会破坏网络操作。人们会忘记续订域名。系统会因防火墙故障导致的数据连接问题而中断。
计划应对所有可能出错的情况。尽力在实现级别考虑潜在的故障。设计弹性，例如使用断路器模式，以防止当微服务无法执行给定操作时服务中断。
基础设施自动化可能是支持微服务的一个重要优势，但操作中断仍然是一种非常真实的可能。在《组织数据混沌》中，Redis 的 Allen Terleto 与 Enterprise Strategy Group (ESG) 的 Mike Leone 和 Google Cloud 的 Jim Roomer 一起揭示了数据库灾难的内幕。他们展示了实现高效数据处理的途径，并介绍了 Redis 在 Google Cloud 上的客户案例。
