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