微服务最佳实践
转载请注明来源：https://janrs.com/5s0t
微服务架构是一种进化模式，它从根本上改变了服务器端代码的开发和管理方式。 这种架构模式涉及将应用程序设计和开发为一组松散耦合的服务，这些服务通过定义明确的轻量级 API 进行交互以满足业务需求。 它旨在通过促进持续交付和开发来帮助软件开发公司加速开发过程。
如果我们谈论它的基本级别，一个特定的微服务本身就是一个应用程序，它与其他微服务一起形成一个更大的应用程序； 这使得：
- 更轻松、更快速的开发
- 可维护性
- 可扩展性
从本质上讲，这使您可以更有效地管理和维护应用程序。 但是，此模式具有固有的特定复杂性，可以通过使用某些最佳实践来减轻这种复杂性。
众所周知，微服务设计对现代架构的网络弹性有直接影响。 当企业决定使用微服务进行构建时，重要的是要高效且有效地开发它们，以便它们可以在网络上运行，而不会导致过多的延迟、带宽消耗和数据包丢失。
在本文中，我们将讨论基本的微服务最佳实践，如果您想实现一个没有极端架构复杂性的高效微服务生态系统，您应该考虑这些最佳实践。 所以，事不宜迟，让我们开始吧。
采用单一职责原则
单一职责原则是 OOP 中的任何单个对象都应该为一个特定功能创建的概念。 基本上，它是 Robert Martin 提出的编程原则的一部分。 就像代码一样，一个类应该只有一个更改原因，使软件更易于维护、可扩展且更易于理解。 要在软件开发中采用 SRP，您应该确保每个类或模块都有明确定义的职责，并且不会尝试做太多事情。 您还应该保持模块解耦，并使用清晰简洁的界面在它们之间进行通信。 总结一下，我们有一个有趣的引用：
“将那些因相同原因而变化的事物聚集在一起，而将那些因不同原因而变化的事物分开。” — O’reilly
我们可以说这是构建良好架构设计的最佳和最基本原则之一，因为它表示微服务、模块、类、子系统或功能不应有多种更改原因。
让我们通过一个例子来理解这个原则：
电子商务门户可能具有如下微服务架构：
在这里，所有服务（例如产品列表服务、订单服务、客户服务、支付服务、购物车服务、愿望清单服务等）都有单一的职责。 这意味着确保在非绝对必要时不将一项服务与另一项服务集成很重要，因为这会使架构的维护和测试变得更加复杂。
建立职责明确的团队
要开发微服务架构，我们需要建立职责明确的团队。 这可以通过多种方式完成，例如基于角色的团队、跨职能团队等。在这种架构中，每个微服务都作为一个独立的应用程序工作。 因此，每个团队都应该具备足够的多才多艺来处理他们的操作。
让我们通过一个例子来理解这一点：
一个组织可以拥有基于角色的团队，如 UI/UX 开发人员、前端开发人员、后端开发人员、数据库管理员、QA、中间件开发人员等，他们独立工作，但每天通过会议进行互动——无论是面对面的 或使用各种通信工具，如 JIRA、Slack 等。
当我们考虑维护时，有时系统中也会出现小错误，有时甚至是大错误。 因此，SCRUM 可能是一种可能的解决方案。 它可以帮助每个团队成员缩短无意识的时间。 但是由于团队是根据角色组织的，因此在一个冲刺中集成一个更新可能会成为一项复杂的任务。 例如，如果 UI/UX 开发人员没有从服务器人员那里获得任何关于 API 更改的信息，那么新的 API 将毫无用处。
那么解决方案是什么？
建立职责明确的跨职能团队，帮助协调团队之间的工作。
一个负责整个微服务功能的跨职能团队可以为您的项目带来重大好处。 该团队应由来自所有基于角色的团队的成员组成，并负责协调应用程序的各个部分，即 UI、开发、数据库，甚至 QA。 如果应用程序有两个版本，即网络版和移动版，那么这两个团队的开发人员都应该出现在这个团队中。 这种团队的主要好处是可以轻松解决错误、开发新功能并将它们部署到生产环境中。
使用正确的工具和框架
至此，您可能已经将微服务设计为独立部署，现在您必须实现这些微服务的最佳价值。 为此，您需要使用一套好的 DevOps 工具来自动化构建和部署管理。
使用正确的工具、框架和库将大大有助于实现微服务架构。 如果您计划在 Java 中执行此操作，请考虑 Spring Boot 项目。 选择正确的工具和框架需要花费大量时间和精力，因此这里列出了“首选”、经过验证的工具和技术：
- 用于部署自动化的 Jenkins 和 Bamboo
- 用于容器化的 Docker
- 用于容器编排和部署的 Kubernetes
- 用于监控的 Logstash
- DevSecOps 管理软件开发生命周期的整个过程
- GitHub/GitLab 用于源代码管理和版本控制
- Ansible 用于管理您的配置
- 用于问题跟踪和项目管理的 Jira
保持微服务之间的异步通信
微服务之间有两种类型的通信：同步和异步。 让我们通过一个例子来理解这一点：
对于电子商务平台，同步通信意味着用户将被要求“保持在线”并通过一系列步骤（选择商品、添加送货地址、付款明细、订单验证）最终导致客户通知“谢谢 你为你的订单！ 我们将在下周交付”。
一旦处理了客户通知，就会发生一些异步通信，它们是订单“履行”阶段的一部分，例如：仓库通知、库存更新等。
在同步通信的情况下，一个服务变得依赖于另一个服务。 有时，使用多个微服务之间的同步通信来完成整个任务会变成一个耗时的过程。
另一方面，异步通信并不相互依赖。 因此，每个服务都可以花时间完成其任务。 因此，应该尽可能地尝试最大化微服务之间的异步通信。 它减少了依赖性并提高了应用程序的整体效率。
您可以在下面看到这样的示例：
采用 DevSecOps 模型并保护微服务
安全性在此架构中非常重要。 随着微服务架构在开发云原生应用程序方面的发展，越来越多地使用 DevSecOps 实践来确保持续集成和持续交付，同时增加安全措施。 使用微服务构建的应用程序可以分为以下代码类型：
- 应用代码（核心逻辑）
- 应用服务代码（网络连接、会话建立等）
- 基础设施（数据存储资源、网络、平台等）
- 监控（应用程序的连续可观察性）
DevSecOps 由三个概念组成：开发、安全和操作，并且已被证明是具有持续集成、持续交付和持续部署管道等原语的代码类型的促进范例。 这些管道是使用开发人员源代码进行开发、测试、部署和许多此类操作的工作流，这些操作由具有反馈机制的自动化工具支持。 此外，它还能让开发团队更快地交付更好、更安全的代码。 微服务架构中的 DevSecOps 实践提供了许多好处，例如：
- 高安全保障
- 减少代码漏洞
- 提高产品质量
- 提高生产力
- 提高操作速度
- 更快地交付更好、更高质量的软件
为每个微服务使用单独的数据存储
一个重要的做法是确保尽可能使用单独的数据库来存储数据，而不是像在单体架构中那样为多个微服务使用相同的数据库。 但是，更深入的分析可能表明一个微服务仅适用于数据库表的一个子集，而另一方面，另一个微服务仅适用于一个全新的表子集。 如果数据的两个子集是正交的，这就是将数据库分离为单独服务的情况。 因此，请确保为您的微服务提供单独的数据存储，以减少延迟并提高安全性。 这一点已经被多次提及，但重要的是要强调微服务应该尽可能少地相互依赖。
微服务架构的主要属性之一是每个服务的数据都是私有的，例如，每个服务一个数据库模式就是这种情况。
我们还可以使用一个共享数据库服务器，它可以被多个服务使用，并对其数据进行逻辑分离。
单独部署每个微服务
如果您单独部署每个微服务，您肯定会在维护或升级工作时节省大量与多个团队协调的时间。 此外，如果一个或多个微服务具有相同的资源，我们建议您使用专用基础设施来隔离每个微服务的故障，避免全面中断。
部署微服务的一些最常见和流行的模式是：
- 每个主机多个服务实例
- 每个容器的服务实例
- 每个主机的单个服务实例
- 每个虚拟机的服务实例
编排微服务
微服务的编排是在流程和工具方面取得成功的最有影响力的因素之一。 您可以使用 Docker 在虚拟机上运行容器，但它无法提供与容器编排平台相同级别的弹性。 在尝试采用微服务架构时，这样的决定很可能会对您的正常运行时间产生负面影响。
以下是一些经过验证的编排平台：
- K8s（Kubernetes）
- AKS（Azure Kubernetes 服务）
- ECS（亚马逊弹性容器服务）
- Azure 容器应用程序
这些平台有助于管理容器配置和部署、负载平衡、扩展、网络通信问题等。
使用有效的监控系统
微服务架构可帮助您对数千个模块化服务进行大规模扩展，并提供提高速度和有组织的监控方法的潜力。 但是，重要的是要确保检查所有微服务并定期检查它们是否按预期运行以及是否有效地使用了可用资源。 根据这些观察结果，如果没有达到预期，您可以采取适当的措施。
让我们分析一个示例情况，假设您应用了一种微服务架构模式，该模式不具备处理请求的能力，但它们仍在运行。 例如，如果数据库连接耗尽，监控系统应该能够在实例失败时生成警报，并且请求应该被路由到工作服务实例。
监控微服务并准确解释这些统计信息将帮助您改进决策并在需要时保持微服务可用。
让我们看一些微服务监控工具的例子。
AWS CloudWatch：一种监控、观察和管理服务，可收集和可视化实时日志，并为 AWS、混合和本地应用程序和基础设施资源提供可操作的见解。
Jaeger：旨在监控和解决微服务环境中复杂问题的软件。
Datagod：一个用于云规模应用程序的可观察性、安全性和分析平台，使用基于 SaaS 的数据分析平台为数据库、服务和工具提供全面的解决方案。
Graphite：顾名思义，它是一种开源软件，可以监控和绘制数字时间序列数据并提供对底层系统的深入洞察。
Prometheus：一个免费的开源软件工具，提供监控和修改解决方案。
总结
这就是这篇文章的内容。 我希望您觉得这篇文章有用，并且您将遵循这些微服务的最佳实践，最终得到一个独立的、松散耦合的系统，以便从这种架构中获益。
转载请注明来源：https://janrs.com/5s0t
发表回复