体验微服务架构和通信

2025-06-04

体验微服务架构和通信

在单体架构中构建应用程序包括发出请求的客户端、服务器(包含路由器、授权中间件、一些功能和业务逻辑)以及数据库。整个应用程序可以通过这些组件部署到位。构建的工件是一个单独的可执行文件,托管在单个虚拟机上,并采用一致的技术栈。

在微服务中,这些服务仅为应用提供单一功能。它们彼此独立运行,不直接依赖彼此的数据库。即使任何一项服务宕机,应用仍可正常运行。这些服务规模小、自主,并且可以独立部署。

单片架构与微服务架构

单体架构 vs. 微服务架构

单片架构对于小型应用程序来说效果很好,但即使一行代码的更改也意味着停机,并且不能轻松地水平扩展(添加新服务),只能垂直扩展(意味着更多的处理能力)。

微服务的好处

  1. 小型服务可以由团队拥有,更容易理解和重写。
  2. 技术选择采用新技术,使用正确的工具,在有意义的地方进行标准化。
  3. 单独部署它具有较低的应用程序故障风险,无停机时间,频繁更新
  4. 扩展它可以轻松扩展服务,经济高效

为什么要花费大量精力创建许多不同的代码库并使用异构技术来创建应用程序?

微服务也面临诸多挑战,例如服务间的通信。由于服务间请求密集,交互非常复杂,如果不加以避免,效率会非常低下。
在微服务中,我们严格遵循两条规则:

  1. 每个服务都有自己的数据库(如果需要的话)这称为每个服务数据库模式,我们这样做是因为如果我们只使用单个数据库,并且该数据库关闭,则整个应用程序就会关闭,需要避免单点故障,其次是可扩展性,根据每个服务的需要增加数据库的容量和吞吐量要容易得多。
  2. 服务永远不会进入另一个服务的数据库,如果依赖服务的数据库出现任何问题,其他服务也会丢失,其次,如果一个数据库的模式发生改变,则两个服务都需要更新。我们还可以使用最适合特定需求的不同类型的数据库。

让我们试着想象一下它是如何工作的,并找到解决所面临的挑战的解决方案,
下面是具有这 3 个功能的应用程序示例:

  1. 用户可以注册
  2. 用户可以提交帖子
  3. 用户可以对每篇帖子发表评论基本应用程序示例

但是现在如果我们想添加另一个代码来列出特定用户的帖子的评论:

  1. 我们需要来自用户集合的用户
  2. 我们需要找到该用户的帖子
  3. 我们需要获取该帖子的评论

在单体服务器中,我们可以访问每个数据库并获取所需信息。它看起来是这样的: 但这种模式效率很低,我们稍后会看到。 通过微服务中的“每个服务一个数据库”模式,我们可以添加另一个服务来为我们完成这项工作:
单片服务器

服务D

它该如何连接三个不同服务的独立数据库?这在“每个服务一个数据库”模式中是不允许的。为了解决这个问题,我们需要了解如何在服务之间建立通信。

建立服务之间的通信策略有两种通用策略:

  1. 同步通信服务使用直接请求相互通信
  2. 异步通信服务使用事件相互通信

注意:这些与 JavaScript 对这些术语的定义不同。

同步通信示例:

同步通信

一个服务可以使用直接请求与另一个服务通信,这不一定是 HTTP 请求,可以是任何类型的请求。在我们的例子中,为了请求用户帖子的评论,服务 D 会向其他三个服务分别发出 3 个不同的请求。

优点:

  1. 易于推理并直接添加新服务
  2. 新服务不需要数据库

缺点:

  1. 整个请求的速度取决于其最慢的请求。例如:如果请求 1 需要 10 毫秒,请求 2 需要 10 毫秒,而请求 3 需要 100 毫秒,则响应时间将超过 100 毫秒
  2. 使服务相互依赖,如果任何服务发生故障,整个服务都会发生故障
  3. 由于存在多个嵌套请求,因此很难跟踪请求。

异步通信示例:

这种类型的通信需要一个可以发出和接收事件的事件总线,该事件总线将连接到应用程序中的每个服务。

这将服务彼此解耦。它们不再进行一对一通信,而是通过消息代理相互通信。如果其他服务宕机,第一个服务仍然可以工作,第二个服务稍后会自行恢复。消息有两种类型:命令(“请执行此操作”)和事件(“过去发生了某事”)。

异步通信

现在,在我们的案例中,服务 D 首先会向其他所有服务广播一个事件(UserQuery)。这些服务会根据需要处理该事件,并可以再次发布该事件的结果。服务 D 会根据收到的用户信息,再次发送一个 PostsQuery 事件,最后根据这些 Posts 事件,向事件总线发送另一个事件 CommentsQuery。现在,事件总线会将每个事件广播到所有服务,直到服务 D 收到结果为止。

这种方法非常糟糕,具有同步通信的所有缺点以及它自身的许多缺点。

更好的方法是添加一个可以提供所需信息的数据库。其他服务将发出事件并填充此数据库,现在该数据库将准备好立即处理请求。

异步通信

优点:

  1. 服务 D 具有零依赖性
  2. 查询非常快

缺点:

  1. 难以理解和编码
  2. 数据重复
  3. 额外的存储成本(但便宜!)

感谢您读到这篇文章的结尾,太棒了!
您刚刚迈出了从高层次视角看待应用程序架构的第一步。网上有很多关于这方面的信息可以学习。别忘了留下您的想法。这些信息是我从 Stephen Grider 的精彩课程中学到的,这是非附属链接 ( https://www.udemy.com/share/102VKE/ )。
如果您觉得有用,请分享,或者在Twitter上跟我打个招呼:)

-- 编辑
跟进阅读 -

文章来源:https://dev.to/dpkahuja/get-a-taste-of-microservice-architecture-and-communication-53n3
PREV
10 个面试错误,让你显得资历浅……并错失良机
NEXT
使用 Go 语言实现 Google 的 Oauth2