在上世纪60年代和70年代， 整体架构 由于计算资源有限，它需要将所有功能组合成一个单一的、有凝聚力的单元，因此被青睐于开发应用程序。
直到 90 年代末和 2000 年代，单体结构开始变得过于有限，无法满足应用程序不断增长的规模和复杂性，特别是随着互联网和分布式系统的兴起。
这导致了更多模块化方法的开发，例如 面向服务的架构（SOA） 并且，后来， 微服务架构（MSA），最终在 2010 年代初期变得突出。
也就是说，这只是对微服务的基本概念和使用的简要说明。那么，让我们讨论一下微服务如何取代单体架构、微服务如何工作以及一些微服务示例。之后，我们将讨论微服务部署的关键方面以及如果您想部署微服务该怎么做。
什么是微服务？它们如何工作？
正如我之前提到的，微服务是作为增加应用程序复杂性和规模的解决方案而出现的，允许公司将功能分解为可独立部署的服务。
“微服务”一词由 Martin Fowler 和 James Lewis 等行业专家普及，他们在 2014 年的一篇博客文章中正式介绍了该术语。他们的工作定义了关键原则和特征，包括对可独立部署服务、去中心化数据管理和技术不可知论的需求。
从那时起，在技术进步的支持下，微服务已成为主流架构选择。 Docker 等容器化技术、Kubernetes 等编排工具以及无服务器计算平台。但微服务是如何工作的呢？
微服务如何工作？
微服务架构的核心是将大型应用程序分解为更小的、不同的服务，每个服务负责特定的业务功能。这些服务通常通过 REST API、gRPC 或 RabbitMQ 或 Apache Kafka 等消息代理通过网络相互通信。
根据 Martin Fowler 和 James Lewis 的定义，微服务都具有以下四个关键特征：
- 单一职责： 每个微服务都旨在执行特定的任务或功能，从而实现专业化并降低复杂性。
- 独立： 微服务可以相互独立地开发、部署和扩展，从而提供了灵活性和弹性。
- 去中心化数据管理： 微服务通常拥有自己的数据库，从而避免了对单一集中式数据库的需求。
- 技术不可知论： 团队可以为每个服务选择最佳技术，而不受其他服务选择的约束。
这种方法与传统的整体架构形成鲜明对比，在传统的整体架构中，所有应用程序组件都紧密集成到一个单一的、有凝聚力的单元中。
微服务部署的关键阶段
虽然微服务架构提供了许多好处，例如高可扩展性、灵活性、效率、故障隔离等，但它需要了解如何有效地部署微服务并进行大量规划才能成功。
这就是为什么全面了解部署微服务的关键概念、阶段和微服务最佳实践对于成功的微服务架构至关重要。因此，让我们探讨一下微服务部署的关键阶段以及每个阶段的含义。
微服务部署的规划和准备
所有美好的事情都需要规划和耐心，要成功部署微服务，您当然需要大量的规划和耐心。这就是为什么遵循微服务最佳实践并规划和准备部署微服务时所需的一切非常重要。
正如我之前提到的，微服务的关键原则和特征之一是 单一责任原则。通过忠实于这一原则并确保每个微服务专注于并负责一项功能和能力，您可以让您的团队独立开发、部署和扩展服务。
此外，该原则的一个子类别是 松耦合设计原则。这意味着每个服务都可以独立地进行通信，并且对其他服务的依赖程度最低。反过来，这允许对一项服务的更改或更新不会影响其他服务，从而允许独立的微服务扩展。
这降低了级联故障的风险，在级联故障中，系统某一部分的问题或故障会触发连锁反应，导致整个系统出现故障并导致整个服务瘫痪。
一个重要的微服务实践是在部署微服务时为每个服务提供专用的数据存储，作为松耦合设计原则的扩展，因为这可以防止冲突并实现更好的服务可扩展性。
此外，您还需要异步微服务通信模式（例如消息代理），以确保每个服务都可以在没有直接依赖关系的情况下进行通信。
最后一个难题是为微服务实施持续集成和持续交付 (CI/CD) 管道。这些管道允许团队通过以下方式部署新功能或修复 持续集成/持续交付工具 像 Jenkins 和 GitLab 一样，允许组织在保持系统稳定性的同时频繁发布新功能。
现在您已经对微服务部署所需的规划和准备有了总体了解，我们来谈谈微服务部署策略。
微服务部署策略
部署微服务时，选择部署策略取决于服务功能、流量、基础设施设置、团队专业知识和成本考虑。但一般来说，微服务部署策略有以下几种：
- 每个容器的服务实例： 在这种方法中，每个微服务都在自己的容器中运行，与每个主机模型的多个实例相比，提供更好的隔离。容器有助于轻松扩展并改善资源分配。
- 每个虚拟机的服务实例： 每个服务都在单独的虚拟机 (VM) 中运行，提供比容器更好的隔离性。虽然这提高了安全性和稳定性，但通常会产生更多的开销。
- 分阶段发布： 最初，将微服务版本部署给一小部分用户，在全面部署之前测试其稳定性。这种方法可以最大限度地减少出现问题时的影响，并允许快速回滚以保持系统完整性。
- 蓝绿部署： 此方法使用两个相同的生产环境，一个环境提供实时流量，另一个环境用于测试下一个版本。蓝绿部署可以轻松回滚和零停机更新，因为流量可以在两个环境之间无缝切换。
- 分阶段发布： 该策略涉及逐步向不同的用户群体或环境推出更新。它通常在进入生产之前从内部环境开始，限制任何潜在问题的影响范围，并允许团队分阶段解决问题。
- 无服务器部署： 这种方法利用 AWS Fargate 和 Google Cloud Run 等无服务器平台，通过为您处理扩展和资源分配来自动化基础设施管理。通过无服务器部署，无需管理底层服务器，使您能够专注于微服务本身。
一旦您选择了上述微服务之一来部署微服务，您将需要一个微服务编排工具。
微服务编排
选择多种微服务部署策略之一后，您将需要一种用于微服务编排的指挥者。微服务编排工具，例如 库伯内斯，帮助自动化微服务部署、微服务扩展、微服务监控和容器化微服务管理。
例如，Airbnb 使用 Kubernetes，允许其工程师在其微服务中部署数百项更改，而无需人工监督。 Kubernetes 等微服务编排工具的一项重要功能是内置负载平衡。
拥有强大的负载平衡功能有助于在微服务的多个实例之间分配传入流量。这可以防止任何单个实例成为瓶颈，并增强系统处理需求峰值的能力。
Kubernetes 通过其自我修复功能在管理微服务方面发挥着重要作用，其中出现故障的容器会自动替换并重新启动。 《纽约时报》利用此功能来维护其微服务，而不会影响用户体验和停机。
此外，Kubernetes 还使用 ConfigMap 和 Secrets 提高了微服务安全性，如配置和机密，例如数据库凭证或 API 密钥。这对于处理敏感客户和用户信息的公司和服务（例如 Uber）尤其重要。
最后，像 Kubernetes 这样的微服务编排工具对于涉及滚动更新和回滚（例如分阶段发布）的微服务策略特别有利。滚动更新允许通过保持旧版本的某些实例运行来部署新的微服务版本，而不会中断服务。
设置微服务编排工具后，您需要构建和自动化 CI/CD 管道 用于微服务部署。
用于微服务部署的 CI/CD 管道
正如我们之前谈到的，微服务的持续集成和持续交付管道是微服务部署的重要方面。 CI/CD 管道中的 CD 管道负责在代码更改通过 CI/CD 管道的测试和集成阶段后自动将其部署到生产环境。
然后，CI/CD 管道的 CD 部分开始发挥作用，以便每当代码更改通过测试和集成阶段时，服务就会部署到微服务编排工具（例如 Kubernetes 集群）。
此外，测试和集成阶段全部由 CI/CD 管道自动完成，因为单元测试、集成测试和端到端测试都合并到管道中。
这使得团队可以在每个阶段验证更新，同时保持系统稳定性。另外，如果代码更改出现任何问题，尽管进行了各种测试，自动回滚仍然可以恢复到之前的稳定版本。
最后，根据微服务最佳实践实施微服务的 CI/CD 管道有助于组织实现更快的开发、减少手动错误并保持高质量标准。
Spotify、Expedia、iRobot、Lufthansa、Pandora 等许多公司通过 CircleCI、AWS CodePipeline 和 GitLab 等 CI/CD 工具将 CI/CD 管道用于微服务，以自动化部署流程，确保一致的代码质量，并在保持系统稳定性的同时快速交付新功能。
微服务通信模式
微服务如何相互通信完全取决于微服务的功能、整体架构、所需的可扩展性和可靠性。通常，采用两种主要的微服务通信模式： 同步 和 异步 微服务通信模式。
在同步微服务通信模式中，服务实时交互，这意味着服务将发送请求并等待响应，然后再继续。最常用的同步微服务通信模式是 REST（表述性状态传输）API, gRPC（谷歌远程过程调用）， 和 GraphQL.
通常，这种微服务通信模式用于通常需要实时数据处理和立即响应的行业和公司。金融、医疗保健和电子商务等行业通常使用同步通信模式来确保交易、数据检索或交互立即发生，从而保持流畅且响应迅速的用户体验。
也就是说，虽然同步微服务通信模式具有实时响应和简单性等优点，但它们也具有某些缺点，例如由于紧密耦合而造成的潜在瓶颈、高负载下的可扩展性低、响应时间慢以及高流量实例下的高延迟。
另一方面，异步微服务通信模式通常更适合微服务，因为它们基于我们之前讨论的松耦合原则。
这种类型的微服务通信模式允许服务通过 Kafka 或 RabbitMQ 等代理发送和接收消息，从而解耦服务。通过将消息发送到充当缓冲区的队列，服务可以独立通信，而不是像在同步通信模式中那样等待响应。此缓冲区使其他服务能够按照自己的节奏处理消息，从而允许发送者继续其工作而无需等待接收者。
异步微服务通信模式不仅为微服务部署提供解耦结构，而且还提供与同步微服务通信模式相同的实时响应。
这是由于异步事件驱动的微服务通信模式的事件驱动架构所致，因为服务通过在发生特定操作时发出事件来进行通信。其他服务可以订阅这些事件并做出相应的反应。这允许高度响应的系统实时响应变化，而无需服务之间的直接耦合。
此外，在异步 发布-订阅 (Pub/Sub) 在微服务通信模式中，服务（发布者）向主题发送消息，其他服务（订阅者）监听该主题以接收更新。该模型支持多个订阅者，同时向许多服务广播消息。
最后，与事件驱动模式类似，异步 基于编舞的传奇 微服务通信模式也使用事件来相互通信；但是，在此模式中，存在特定的顺序，这意味着事件会触发下一步并激活特定的服务。
这里的区别在于，在事件驱动模式中，没有特定的顺序或工作流程，并且多个服务可以对事件做出反应，而不是基于编排的传奇模式中的特定过程和顺序。
使用哪种类型的异步微服务通信模式取决于微服务的任务和整体功能。 RabbitMQ 和 Amazon SQS 等消息队列通常用于任务调度、工作负载分配以及订单处理和通知系统的电子商务。
事件驱动的消息代理（例如 Apache Kafka 和 AWS EventBridge）通常用于实时处理大规模事件流以及金融服务和 AWS 环境等领域中微服务之间的事件路由。
至于发布-订阅 (Pub/Sub) 消息代理（例如 Google Cloud Pub/Sub 和 Redis Streams），这些消息代理通常用于跨分布式系统的可扩展消息传递，以实现实时分析和事件摄取以及实时通知和聊天应用程序。
最后，基于编排的传奇消息代理主要用于电子商务订单处理、旅行预订系统以及需要在没有中央控制的情况下跨多个服务协调复杂的多步骤事务的用例。
微服务服务发现
一旦您设置并实施了适合您需求的通信模式，您就需要确保您的服务能够首先找到彼此。正如我前面提到的，Kubernetes 等微服务编排工具在微服务服务发现中发挥着重要作用。
这是通过 Kubernetes DNS 提供的内置服务发现来完成的，当服务扩展或更改集群中的位置时，它会动态更新 IP 地址和 DNS 记录。
这种微服务服务发现方法称为服务器端发现，因为路由责任被委托给负载均衡器，然后负载均衡器查询注册表并将流量引导到适当的实例。
另一方面，我们还有用于微服务服务发现的客户端发现方法，其中服务或API网关查询服务注册表（例如Consul或Eureka）以查找可用实例。
选择最适合微服务部署的服务发现方法取决于系统的要求和规模。
通过客户端微服务服务发现，客户端可以完全控制与哪个实例通信。这不仅允许更多的定制，而且还降低了复杂性，因为不需要集中的发现服务。
例如，Netflix 的微服务部署使用 Eureka 和 Ribbon 的客户端微服务服务发现来实现负载平衡，允许客户端根据延迟和服务器负载等标准选择最佳实例。
然而，服务器端微服务服务发现更适合更大的环境，因为集中式服务发现可以提高效率并允许跨分布式系统实现一致的负载平衡。
服务器端微服务服务发现解决方案，例如 Kubernetes、AWS Elastic Load Balancing 和 API 网关（Kong、NGINX 等）有助于高效路由流量并保持高可用性，并被 Airbnb、Pinterest、Expedia、Lyft 等公司使用。
微服务安全
虽然整体架构大多不如 MSA，但整体架构的优势之一是安全性。由于微服务是基于松耦合原则构建的，并且本质上是分布式的，因此无法实施单一的、通用的安全措施。
由于每个服务必须独立保护，因此需要额外的保护措施，因为微服务中的攻击面要大得多。为此，您可能已经猜到，OAuth2 和 JSON Web 令牌 (JWT) 等标准通常用于身份验证和授权。
此外，API 网关还经常用于管理跨微服务的安全性，因为它在入口点强制执行身份验证和授权。此外，网关 API 还可以实现速率限制、日志记录和监控，从而提供额外的微服务安全层。
虽然这些措施保护了主要入口点，但还需要更多的微服务安全措施来覆盖服务间通信。
这就是服务网格发挥作用的地方，因为它们添加了一层网络微服务安全性并加密服务之间的流量并强制执行相互 TLS 等策略。这些服务器网格基本上建立了全面的端到端加密，可显着提高微服务的安全性。
微服务扩展
MSA 的最大优势之一是其高可扩展性，这也是开发它来取代整体架构的原因。通常，微服务扩展可以通过两种方式发生：垂直和水平。
基本上，垂直微服务扩展（向上扩展）是向现有实例添加更多资源，例如 CPU 或内存。或者，水平微服务扩展（横向扩展）可以分配负载并增加容量。
在实施方面，垂直微服务扩展是两者中更容易的一个，因为您所要做的就是通过升级到更大的服务器、增加云实例中的内存或处理能力或添加更多存储来修改单个实例。
这种类型的扩展通常用于增加 RAM 或 CPU 功率可以提高查询性能和数据处理的情况，例如负责内存中缓存的服务。
也就是说，虽然垂直微服务扩展更容易并且可以立即提升性能，但它也有缺点。垂直扩展受到服务器硬件容量的限制，因此在某些时候，您需要切换到水平扩展以继续垂直扩展。
此外，垂直扩展的成本很高，因为硬件和更大的实例通常价格昂贵。最后，如果扩展的实例失败，服务将完全关闭，因为没有其他实例来处理负载。
对于水平微服务扩展，您无需升级单个实例的资源，而是部署该服务的新实例。虽然这些实例独立工作，但它们仍然处理相同的服务和部分相同的工作负载。
与垂直扩展不同，水平微服务扩展是无限的，这意味着您可以添加任意数量的实例来处理不断增加的工作负载和流量峰值，从而提供更大的可扩展性。
此外，由于您有多个实例，如果其中一个实例发生故障，您就不会把所有鸡蛋放在一个篮子里，因为其他实例可以继续处理请求。最后，从长远来看，水平扩展更具成本效益，因为您可以使用多个更小、更便宜的实例来形成更可靠、更强大的性能。
也就是说，水平扩展和添加更多实例需要更多的负载均衡器、微服务服务发现机制和微服务编排工具，从而使您的微服务架构变得更加复杂。
水平扩展更适合 Web 服务和电子商务或社交媒体平台等应用程序等用例，这些用例经常会遇到流量波动和大量请求的情况。
也就是说，这并不是一个非此即彼的情况，因为这两种类型的扩展都在微服务中得到支持，并且在许多情况下都是必要的。通常，较小的组织使用垂直扩展，因为它更容易实施和管理，但随着时间的推移和应用程序的增长，会引入水平扩展来处理繁重的需求。
最后，云平台提供自动扩展服务，可以根据实时需求自动添加或删除实例，这极大地帮助组织平衡垂直和水平扩展。
微服务监控
在此阶段，您已经基本完成了微服务部署；剩下的就是确保它持续可靠地工作。这就是微服务监控工具的用途，例如 普罗米修斯和格拉法纳 介入。
这些工具提供对服务指标的实时洞察，以便团队可以跟踪资源使用情况、延迟和错误率。此外，这些工具还提供分布式跟踪（Jaeger、Zipkin 等），这有助于可视化跨服务的请求流，并且对于诊断问题非常有益。
最后，由于微服务的分布式设计，故障可能会跨服务级联，因此日志聚合是微服务监控中的关键实践。通过将日志整合到集中式平台并设置实时警报，您将始终领先问题两步，并可以在问题影响用户之前主动做出响应。
最后的想法
虽然微服务的世界确实是一个难以理解的世界，但了解微服务部署的基础知识和关键阶段可以使整个过程变得更加容易。此外，随着时间的推移，越来越多具有更多功能的工具可供您使用，这使得微服务部署比以往任何时候都更加简单。
常问问题
微服务通常采用哪些部署策略？
虽然微服务部署有许多不同的策略，但最常用的部署策略包括每个容器的服务实例、分阶段发布、蓝绿部署和无服务器部署，每种策略都提供不同级别的隔离、灵活性和可扩展性。
Kubernetes 在编排微服务方面扮演什么角色？
微服务依靠 Kubernetes 等微服务编排工具来自动化部署、扩展和管理容器化服务，提供负载均衡、自动扩展和自我修复功能，以确保微服务的弹性和高效。
如何确保微服务环境中的安全？
由于其分布式特性，微服务在安全性方面比单体架构更加复杂。微服务中的安全性涉及对请求进行身份验证和授权、加密服务间通信以及实现 API 网关和服务网格（例如 Istio）以进行集中安全管理。
