视频
克服微服务采用挑战
了解更多
速度的未来将在您的城市举办的活动中到来。
加入我们参加 Redis 发布会
分享
了解您的微服务部署选项，包括自动化以节省您的团队宝贵时间，以及其他关于如何保护系统免受意外故障的实用建议。
在介绍了 微服务架构关键概念 之后，接着介绍了 微服务设计原则，我们将继续介绍使用容器化微服务应用程序的系列内容。本文将概述微服务管理，涵盖部署策略、版本控制的重要性以及配置方法，这些方法可以使团队避免为了代码库之外的简单更改而启动完整的重新部署。
您已经相信将应用程序转换为使用微服务方法的好处。但是，关于如何进行转换的问题出现了。在设计您希望用于管理微服务的结构时，请考虑以下要素，并熟悉这些概念。从长远来看，这将为您节省许多困惑。
容器是预先打包的软件包，包含运行软件所需的所有组件——这可能意味着任何东西，从独立应用程序到编排系统环境中的数据库。容器支持 基础设施即代码，并且在 DevOps 团队中很受欢迎。容器的运营效率功能通过自动化频繁的命令、扩展数据库以包含 主动-主动配置 以及为离线的集群或节点建立自动故障转移协议来提供帮助。如果每个微服务都在自己的容器中运行，团队可以启动自己的发布并消除对其他团队工作流的依赖。
> 了解团队如何使用 操作员来充分利用 Kubernetes。
A/B 测试是一种通过以受控方式将不同的变量注入每个版本（功能、用户界面差异、服务器配置等）来测试微服务应用程序或服务的多个版本的方法，以确定哪些元素在性能方面产生了最大的成功——无论成功在相应领域意味着什么。为了评估多种方法，网络流量在测试 A 和测试 B 之间进行拆分，以使用日志、跟踪和监控来监控用户如何响应和与每个正在测试的独立产品的新的实现或已删除的功能进行交互。
> 了解 如何使用 Redis 构建实时 A/B 测试工具。
蓝绿部署是一种有助于迁移数据、测试数据、以受限的暴露方式对更改做出反应以及减少停机的策略。正如 数据摄取：加速应用程序的 6 种方法 中所解释的，蓝绿部署是执行数据迁移的一种方法。基于此前提，您可以并行摄取数据。应用程序继续使用“蓝色”传统数据库，而新的“绿色”云原生数据库则并行部署，用于实时生产测试和此新数据管道的切换，并确保回滚。
> DevOps 团队有许多方法可以迁移数据。 Redis 企业云服务 随时准备帮助您统一混合云和多云数据层。
从历史上看，矿工使用金丝雀作为早期预警系统 来通知他们氧气含量低。金丝雀发布的想法相同——帮助在问题变得严重之前识别问题。这种增量部署策略通过将微服务发布分发到一小部分用户，然后将其展示给整个用户群来测试微服务发布。这样，开发团队可以测试用户体验问题、重点关注有缺陷的代码以及响应真实用户的反馈，然后可以将这些反馈实施到最终产品中。
微服务及其各自的应用程序很少保持静止。必须偶尔实施更新、刷新和一般的代码调整。
顾名思义，持续集成 (CI) 是一种将新代码部署到现有部署环境中的自动化流程。为了使 CI 对开发人员和 DevOps 团队有利，它需要一个可靠的测试和部署自动化策略，以确保快速交付生产质量的发布。
持续部署 (CD) 通常在经过自动化测试后将新部署提升到生产环境中。
> 了解 Redis 开发人员中心扩展以支持 DevOps 团队的需求，方法是将数据库作为 CI/CD 管道的一部分。
配置管理确保每个微服务的相应配置文件正确且立即可用。配置管理使开发人员和 IT 部门不必在微服务需要修改时更改应用程序代码。保持代码完整并仅更新配置文件还可以使团队不必为启动应用程序的重新构建而烦恼。
微服务架构 是一种动态框架，封装了工作流或流程的组件，通常侧重于特定的业务领域。例如，零售应用程序包含基本功能，例如购物车管理、订单处理、支付处理、结账流程、产品目录、与后端财务和会计系统无缝集成以及强大的客户服务支持。
在设置微服务架构时，DevOps 的任务是应用使微服务在整个应用程序基础设施中以特定方式运行的准则。这些设置可能包括数据库连接详细信息、API 端点、日志记录级别、运行时配置和功能切换，也称为“功能标志”。
微服务的正确配置值（通常存储在 JSON 或 YAML 文件中）取决于应用程序的安全要求、它运行的数据库、它在开发周期中的状态以及它的部署环境，以及其他因素。除了 JSON 和 YAML 文件之外，配置源还存在于命令行参数中设置的参数内。
集中式配置存储是一个服务器或存储库，从中可以管理所有微服务的配置，无论其环境如何。从一个微服务到另一个微服务的配置功能可能差异很大，并且在没有全局可用的单个记录“可能会很快变得过于复杂”的情况下，处理如此不同的参数和机密会让事情变得非常复杂。除了成为配置的专用中心之外，它还简化并加速了新发布的正常运行时间流程。
动态配置管理 (DCM) 解决应用程序中的配置更改，而无需启动重新部署。接触应用程序代码会自动触发运行包含所有功能和集成测试的完整回归套件的需要。
这些预先存储的测试通常通过集中式配置存储执行。
机密共享敏感数据，例如密码、密钥、凭据和身份验证令牌。机密使机密数据与应用程序的代码分离，从而可以在不需要代码更改的情况下管理机密。
在 Kubernetes 中，机密“默认情况下，存储在 API 服务器底层数据存储（etcd）中未加密。任何具有 API 访问权限的人都可以检索或修改机密，任何具有 etcd 访问权限的人也可以。此外，任何被授权在命名空间中创建 Pod 的人都可以使用该访问权限读取该命名空间中的任何机密；这包括间接访问，例如创建部署的能力。”
为了维护安全的用户身份验证，开发团队可以使用外部机密操作员（例如 HashiCorp Vault）来维护安全的用户身份验证。机密操作员在共享敏感信息之前授权所有访问。
版本控制是 DevOps 团队跟踪对微服务属性（包括“键值对、软件物料清单 (SBOM)、常见漏洞和披露 (CVE)、许可证、swagger 详细信息、使用应用程序以及部署元数据”）所做的历史配置更改的一种方式。
这有助于 DevOps 验证所有命名空间和集群是否具有它们应该运行的版本化发布，并且允许在需要以前使用的功能或设置时快速实施配置回滚。因此，任何从事组织微服务工作的人员都可以适应新功能、错误修复和其他更改。
服务网格、服务发现和负载均衡都是相关的概念，它们协同工作以增强微服务的可观察性和可靠性。
服务网格是一种插入基础设施层的模式，用于控制服务间消息传递。对于拥有大量不断增长的微服务的应用程序而言，服务网格可以保持请求清晰和简化，并将相关信息路由到相应的服务，同时保持应用程序性能稳固。
服务网格由数据平面和控制平面组成。这两个平面之间的区别在于“控制平面决定如何管理、路由和处理数据，而数据平面负责数据的实际移动。”以太网、Wi-Fi、蜂窝网络和卫星网络是数据平面的示例。跟踪多个服务的控制平面也称为“服务发现”。
服务发现通过突出显示可用于通信的可用实例来促进服务间通信，而无需进行配置更改。服务注册表存储了可用服务的 IP 地址、端口和运行状况，成为发现哪些服务可用于通信的集中式中心。
在任何网络场景中，负载均衡都是将工作负载和计算资源分布到服务器上的过程，将工作分解以实现更好的资源利用率和系统响应时间。
负载均衡器是服务网格内置功能之一。它使用算法来决定将流量路由到何处，动态地分配流量，而无需在其他网络上使用外部负载均衡设备。当请求到达微服务时，该请求会被拦截并委托给相应的实例。哪个实例处理流量本质上由服务发现或控制平面决定，使用测试和运行状况检查。
自动扩展使用预定义的系统阈值来扩展或缩减服务。假设某个网站预计由于促销、热门体育赛事或备受期待的新产品发布而导致流量大幅激增。在这种情况下，自动扩展会根据需要包含尽可能多的实例，以满足需求并保持基于微服务的应用程序以最佳性能运行。
系统故障有时会发生，因此为节点或集群故障做好准备至关重要。
在实现级别预测这些问题。在 微服务设计原则 中，我们简要介绍了为弹性设计微服务的重要性，以及诸如 断路器模式 等策略，介绍 容错模式，以及使用事件驱动的消息代理实现异步通信，以促进最终一致性。
有关最终一致性的更多信息，请阅读 数据库一致性说明。
想要查找有关微服务的更多信息？在我们的 Youtube 频道上探索我们专门的 微服务播放列表。
