在monolithic单体应用程序中,不同的组件之间通过编程语言级别的方法或函数调用相互调用。 相反,基于微服务的应用程序是在多台计算机上运行的分布式系统。 每个服务实例通常是一个进程。 因此,如下图所示,服务必须使用进程间通信(IPC)机制进行交互。
交互方式
为服务选择IPC机制时,首先考虑服务如何交互是必要的。 客户端⇔服务交互方式多种多样。 它们可以沿两个维度进行分类。 第一个维度是互动是一对一还是一对多:
- 一对一–每个客户端请求仅由一个服务实例处理。
- 一对多–每个请求由多个服务实例处理。
第二个维度是交互是同步还是异步:
- 同步–客户端期望服务及时响应,甚至在等待时可能会阻塞。
- 异步-客户端在等待响应时不会阻塞,并且响应(如果有的话)不一定会立即发送。
下表显示了各种交互样式。
One-to-One | One-to-Many | |
---|---|---|
Synchronous | Request/response | — |
Asynchronous | Notification | Publish/subscribe |
Request/async response | Publish/async responses |
存在以下类型的一对一交互:
- Request/response–客户端向服务发出请求并等待响应。客户希望响应能够及时到达。在基于线程的应用程序中,发出请求的线程甚至可能在等待时阻塞。
- Notification (也称为单向one‑way 请求)–客户端向服务发送请求,但不希望或未发送答复。
- Request/async response–客户端将请求发送到服务,该服务以异步方式答复。客户端在等待时不会阻塞,并假设响应可能不会在一段时间内到达。
一对多互动有以下几种:
- Publish/subscribe–客户端发布通知消息,该消息由零个或更多感兴趣的服务使用。
- Publish/async responses –客户端发布请求消息,然后等待一定时间以等待感兴趣的服务的响应。
每个服务通常使用这些交互样式的组合。对于某些服务,单个IPC机制就足够了。其他服务可能需要结合使用IPC机制。下图显示了当用户请求一个旅行时,出租车服务应用程序中的服务如何交互。
服务使用notifications, request/response, 和publish/