微服务

微服务是什么?

微服务,又称微服务架构,是一种架构风格,它将应用程序构建为以业务领域为模型的小型自治服务集合。

微服务的优势

优势说明
独立开发所有微服务都可以根据各自的功能轻松开发
独立部署根据他们所提供的服务,可以在任何应用中单独部署
故障隔离即使应用的一个服务不起作用,系统仍然我可以继续运行
混合技术栈可以用不同的语言和技术来构建同一应用程序的不同服务
粒度缩放各个组件可根据需要进行扩展,无需将所有组件融合到一起

微服务又哪些特点

特点说明
解耦系统内的服务很大程度上是分离的,因此整个应用程序可以秦颂构建更改和扩展
组件化微服务被视为可以秦颂更换和升级的独立组件
业务能力微服务非常简单,专注单一功能
自治开发人员和团队可以彼此独立工作,从而提高效率
持续交付通过软件创建,测试和批准的系统自动化,允许频繁发布软件
责任微服务不关注应用程序作为项目。相反他们将应用程序视为他们负责的产品
分散治理重点是使用正确的工具来做正确的工作。这意味着没有标准化模式或者任何技术模式。开发人员可以自由选择最优用的工具来解决他们的问题
敏捷微服务支持敏捷开发。任何新功能都可以快速开发并再次丢弃。

微服务架构的优缺点

优点缺点
自由使用不同的技术增加故障排除难度
每个微服务都侧重于单一功能由于远程调用而增加延迟
支持单个可部署单元增加了配置和其他操作的工作量
允许经常发布软件难以保持交易安全
确保每项服务的安全性难以跨越各种便捷跟踪数据
多个服务是并行开发和部署的难以在服务之间进行编码

微服务设计最佳实践

1.单一职责原则

这对任何软件开发人员来说都不陌生,作为学习SOLID 设计原则的一部分,我们每个人都熟悉这一点,但这也适用于微服务。 根据 SRP 或单一职责原则,每个微服务都应该有一个单一的、定义明确的职责,并且应该只与其他微服务通信以完成任务。 例如,一个微服务可以处理用户身份验证,而另一个微服务可以处理支付处理。但是你不应该创建一个同时进行用户身份验证和支付处理的微服务,这将违反 SRP。

2.分散的数据管理

根据分散数据管理原则,每个微服务都应该管理自己的数据,而不依赖于其他微服务,以确保可扩展性和可靠性。 例如,每个微服务都可以有自己的数据库来存储数据。 与其他微服务共享数据库违反了这一原则,应该避免,因为这会使故障排除变得困难,并可能导致数据不一致。 这个设计原则将帮助您更好地管理您的数据库,它也是每个微服务设计模式的基础,这是一个基本的微服务设计原则。

如果您正在考虑另一个微服务如何访问相同的数据,因为另一个服务很可能确实需要它?好吧,您应该始终为此创建 API,正如我们将在下一个微服务设计原则中看到的那样。

  1. API 驱动设计

根据这一原则,微服务应该围绕 API进行设计,每个服务都公开一组定义良好的 API,以便与其他服务进行通信。

例如,微服务可以公开用于检索客户信息的 API,其他微服务可以使用该 API 来访问该信息。

这个原则也和之前提倡微服务不共享数据库的设计原则一致。您必须为需要访问数据的其他服务创建 API,然后这将驱动您自己的微服务设计。

  1. 无状态

根据这个原则,微服务应该是无状态的,这意味着它们不应该在请求之间维护任何特定于客户端的状态。

例如,如果微服务处理用户的购物车,它不应该在请求之间存储任何关于用户购物车的信息,而是应该在每次处理请求时从数据库中检索购物车信息。

5.松耦合

这是另一个同样适用于微服务的软件设计原则。在面向对象的设计中,我们的目标是失去对我们的类、包和模块的耦合,我们可以将相同的规则应用于微服务。

根据这个原则,微服务应该是松散耦合的,这意味着它们不应该相互依赖,以确保可扩展性和易于部署。

例如,如果一个微服务宕机,其他微服务应该仍能正常运行。

  1. 智能端点和哑管道

根据这一原则,数据处理逻辑应位于微服务本身,而不是集中式中心,以确保可扩展性和可靠性。如果您想知道端点和管道在这里意味着什么,端点是 API 或 URL,而管道是数据库队列。

该模式建议端点(例如用户界面或 API)应该设计得更智能,处理所有表示和业务逻辑,而管道(例如队列或数据库)应该设计得更笨,仅执行简单的数据传输和存储功能。

例如,微服务可以负责处理客户订单,而不是让一个集中式中心处理所有订单处理。

使用此模式的主要好处是,它使开发团队能够创建具有松散耦合组件的应用程序,这些组件可以独立开发和部署,从而实现更好的可扩展性和更轻松的维护。

这种模式还有助于简化开发过程,因为开发人员可以专注于在其智能端点中实现特定功能,而不用担心底层通信和数据存储系统。

但是,这种模式的一个缺点是它会使调试变得更加困难,因为错误可能会出现在多个组件中。此外,智能端点可能需要更多资源和处理能力,这会增加运行应用程序的成本。

7.自动缩放

当我们想到微服务时,我们会想到缩放,这是处理它的原则。根据此最佳实践和原则,每个微服务都应设计为自动扩展或缩减以响应需求变化,以确保应用程序保持响应性和可用性。

例如,如果访问微服务的用户数量增加,该微服务可以自动启动额外的实例来处理增加的需求。

在现实世界中,像 Kubernetes 这样的工具可以通过创建微服务的新实例并在不再需要时销毁它们来自动扩大和缩小规模。

如果您的微服务不是为自动扩展而设计的,那么它就无法充分利用云和 Kubernetes 等工具,因此您必须确保它们是为扩展而设计的。

  1. 监控和日志记录

在拥有数百个微服务的项目中工作的主要问题之一是调试非常困难。很难找到请求失败的原因,因为日志是分散的。

您可能会看到用户身份验证错误,认为用户凭据有问题,但由于服务超时,您只能通过查看多个服务的日志来了解真正的原因。

按照这个原则。微服务应该有强大的监控和日志记录机制来帮助诊断问题和跟踪性能。

例如,每个微服务都可以记录有关其性能和使用情况的信息,这些信息可用于识别和诊断问题。这肯定会帮助您长期和日常支持工作。

  1. 持续部署与集成

根据这一原则,任何微服务都应该是可持续部署的,这意味着它们应该通过小的、增量的更改(如错误修复、小的增强等)经常更新。 例如,可以更新微服务以修复错误或添加新功能,而不会影响应用程序的其余部分。

持续部署是通过多种技术的组合来实现的,例如构建和部署过程的自动化、测试以及与版本控制系统、问题跟踪系统和监控工具等其他工具的集成。

通过自动化部署过程,团队可以确保快速、一致地部署新的更改,同时最大限度地减少人工干预。

这种做法还有助于减少停机时间并最大限度地降低错误风险,因为新更改在部署到生产环境之前会经过全面测试。此外,它允许组织更频繁地发布新功能和错误修复,从而增加创新并加快上市时间。

10.基础设施自动化

这是 DevOps 的东西,但作为开发人员,我们也应该熟悉它。根据这一原则,微服务的部署和管理应该自动化,以确保一致性和效率。

微服务架构组件构成

组件说明
客服端来自不同设备的不同用户发送请求
身份鉴权模块验证用户或者客服身份并颁发安全令牌
API网关模块处理客户端请求
静态内容容纳系统的所有内容
管理模块在节点平衡服务并识别故障
服务发现模块查找微服务之间通信路径指南
网络代理服务器及其数据中心的分布式网络
远程服务启用驻留在IT设备网络上面的远程访问信息