.Net Core 微服务–入门

许多开发人员都听说过微服务,这是一件好事。但是我跟很多开发人员交谈的时候发现微服务只是像DevOps这样的流行词。我做微服务的不同项目已经有一年多了,在这篇文章中,将讨论一下微服务概念的理论和思想。在下一篇文章中,将展示如何使用ASP .Net core 3.1实现微服务。

什么是微服务?

顾名思义,微服务非常小。关于大小的意见各不相同。有人说不超过一百行,有人说应该用来做一件事。我的观点是,微服务应该在相同的上下文中进行操作。这也可以是几种方法。以客户服务为例。该服务可以提供进行注册,登录和更改用户密码的方法。

对于大家的应用程序,得需要组成所需功能的微服务。例如,如果你有一家网上商店,则可以使用微服务来显示产品,搜索,购物车,客户和订单。

为什么微服务如此受欢迎?

微服务最重要的方面是它完全独立地工作。意味着微服务拥有自己的数据库(或其他存储方式)。这个非常重要,因为这样可以确保其他服务中的更改不会破坏微服务。在开始时,微服务本身就是一个小型应用程序,尤其是带有自己的数据库的应用程序,这听起来可能很奇怪,但这使更改或部署新功能变得更加容易。在编程中,这与KISSSRP相同。这两个原则都努力使做事情变得简单。

微服务如此流行的一个重要原因是它有助于实现应用程序的高可用性。为了实现这种高可用性,您不得将服务耦合在一起,并保持连接松动。可以使用RabbitMQ,Azure Queue或Azure Service Bus等消息系统来实现这种松散的连接。一个服务将消息发送到队列,其他服务可以处理该消息。如果服务处于脱机状态,则该消息将保留在队列中,并且该服务一旦恢复在线状态,便可以处理所有消息。这种方法的缺点是导致更多的复杂性和诸如延迟,一致性和调试之类的问题。将在后面的“微服务的缺点”部分中进一步讨论这一点。

微服务的优势

使用微服务架构可以带来以下优势:

  • 易于构建和维护
  • 易于部署
  • 新功能可以快速实施
  • 不同技术的运用
  • 团队可以专注并专注于一项任务
  • 更好的可扩展性和资源使用

微服务易于构建和维护

微服务应该很小。因此,可以轻松构建,维护和理解它们。测试不那么复杂,新团队成员可以更快地学习该功能。

微服务可以轻松部署

由于微服务很小,并且不依赖于其他项目,因此易于部署。微服务通常可以在Dockerfile中用几行来部署。

新功能可以快速实施

如前所述,微服务的规模很小,比整体服务更易于理解。因此,实现和部署新功能也更加轻松快捷。

不同技术的运用

另一个很大的优势(尤其是在较大的项目中),您可以为每种服务使用不同的技术。微服务通常使用HTTP动词通过HTTP相互通信。因此,每个服务都可以用不同的语言编写,例如,一个服务可以是.net核心,一个可以是Java,第三个可以是Go。

团队可以专注并专注于一项任务

微服务还帮助团队专注于他们的任务,因为他们不必关心无关的服务。例如,为在线商店提供搜索服务的团队只需专注于搜索功能。他们不必关心商店如何显示产品或处理订单。这也有助于团队专注于高级搜索技术,这可以带来更好的产品。

更好的可扩展性和资源使用

微服务很小,通常在Kubernetes集群的Docker容器中运行。如果您拥有一家庞大的在线商店,并且它想在双11促销活动,那么无论功能是否已被广泛使用或完全不使用,都必须扩展整个应用程序。通过微服务架构,您可以扩展需求量很大的服务。例如,如果有很多人在下订单,则可以扩展订单服务,但不必扩展客户服务。这有助于节省资源,从而降低运行应用程序的成本。小型服务的另一个优点是,您可以将它们更好地放置在服务器上,从而提高利用率,这也有助于降低成本。

.Net Core 微服务–入门

微服务的缺点

当使用微服务架构时,虽然说是一件好事,但它也有一些缺点,如:

  • 复杂性增加
  • 潜伏
  • 资料一致性
  • 调试更困难
  • 将问题层叠到其他服务
  • 处理队列中的消息

复杂性增加

上面有提到,微服务很小且易于理解。但是,当您的应用程序包含成百上千个微服务时,应用程序将变得非常复杂。尤其是当服务彼此需要连接交互数据时。

潜伏

每次调用另一个服务都会增加一些延迟,并且用户必须等待更长的时间,直到获得结果为止。微服务只能调用真正需要的其他服务,并且服务应尽可能靠近放置。

资料一致性

微服务通常异步交换数据,也有自己的数据存储。这可能导致数据不一致,例如,客户服务更新了客户,但订单服务尚未更新客户。

调试更困难

调试可能会更加困难,尤其是当您遇到仅在生产中出现的问题时。

将问题层叠到其他服务

服务失败会导致许多其他服务中断。例如,如果产品服务出现问题并超时,则调用该产品服务的每个服务都必须等待,直到返回错误消息为止。调用产品服务的服务可能会被另一个服务调用,很快您就会受到很多受影响的服务的影响。为了防止整个系统发生故障,您应该实施一个断路器。

处理队列中的消息

服务之间的消息通常通过队列发送,因此即使服务在发布时处于脱机状态,也可以处理消息。如果无法处理,队列中的消息可能会出现问题。服务接受它,无法对其进行处理,然后将其放回到队列中。这花费了资源和时间。您可以设置生存时间,并在到达该时间时从队列中删除消息。

结论

今天简要介绍了微服务的理论。有谈到优点,也有谈到一些缺点。没有完美的解决方案,应该根据项目的需求,然后决定是否采用微服务。建议大家从一个小项目开始,先获得一些运行它们的经验。

这篇文章从理论上讲都是关于微服务的,在后面的文章中,将使用ASP .Net Core,CQRS,Mediator, RabbitMQ和Docker来实现两个微服务。

相关文章: