视频
5 大微服务误解
了解更多
快速的未来正在你的城市举行活动。
加入我们参加 Redis 发布会
分享
所以，你已经评估了应用程序的现状，并得出结论，采用微服务将提高整体性能和可扩展性。很棒。接下来呢？在本文中，我们概述了微服务设计和实现的基本考虑因素。
微服务是一种软件架构策略，它将应用程序分解为一组解耦的、自治的服务。这些独立的应用程序服务通过 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 团队管理、安排和编排自动容器部署。
实施微服务要求任何给定应用程序中的服务维护自己的分散数据。服务边界应该将所有与任何单个服务相关的逻辑和数据与应用程序中的其他服务隔离开来。
这与允许容器化微服务进行独立部署的逻辑相同。根据 红帽 的说法，这一原则有自己的反对者，他们认为 该原则会导致数据冗余的激增。但建立这些离散边界的最大优势之一是，“当微服务携带自己的数据时，任何奇怪的行为都局限在该微服务内”。谁需要猜测呢？
中断会发生。应用程序服务会毫无预兆地停止运行。 寻找光纤的挖掘机 会使网络操作瘫痪。人们会忘记续订域名。系统会因 防火墙故障导致的数据连接问题 而中断。
为所有可能出错的方式做好计划。尽你所能，在实现级别考虑潜在的失败。设计弹性，例如使用 断路器模式，以防止服务在微服务无法执行给定操作时掉线。
基础设施自动化可能是微服务的重大优势，但运营中断仍然是真实存在的可能性。在“组织数据混乱”中，Redis 的 Allen Terleto 与企业战略集团 (ESG) 的 Mike Leone 和 Google Cloud 的 Jim Roomer 共同揭示了数据库灾难背后的真相。他们展示了实现高效数据处理的路径，并以 Redis 在 Google Cloud 上的客户案例为特色。
