几十年来,应用程序一直使用单体架构构建。现在,许多应用程序正在转向微服务架构。微服务架构为我们提供了更快的开发速度、可伸缩性、可靠性,以及使用最佳技术栈开发每个组件的灵活性,等等。微服务架构依赖独立部署的微服务,每个微服务都有自己的业务逻辑和数据库,它们由特定的领域上下文组成。每个服务的测试、增强和伸缩都独立于其他微服务。
然而,微服务架构也有其自身的挑战和复杂性。为了解决最常见的挑战和问题,已经发展出了一些设计模式。在本文中,我们将研究其中的几个。
在一个典型的微服务架构中,要实现顺畅的开发,可采用的设计模式不止八种。在本节中,我们将详细地探究这些模式。我们根据应用程序类型将它们分为两个部分——新应用程序和遗留应用程序。
用于构建新应用程序的设计模式
当我们从零开始构建应用程序时,可以自由地应用所有最新的现代化的微服务架构设计模式。让我们深入了解其中的一些。
API 网关模式
将整个业务逻辑分解为多个微服务会带来各种问题:
如何处理横切关注点,如授权、速率限制、负载均衡、重试策略、服务发现等?
如何避免由于客户端和微服务之间的直接通信而导致过多的流量往返和紧密耦合?
如果客户端需要数据的子集,谁来进行数据过滤和映射?
如果客户端需要调用多个微服务来获取数据,谁来进行数据聚合?为了解决这些问题,我们在客户端应用程序和微服务之间部署了 API 网关。它带来了很多功能,如反向代理、请求聚合、网关卸载、服务发现等。它可以为每个客户端公开不同的 API。