我们先从 Nginx 说起,了解为什么需要微服务。最初的服务化解决方案是给相同服务提供一个统一的域名,然后服务调用者向这个域发送 HTTP 请求,由 Nginx 负责请求的分发和跳转。
这种架构存在很多问题:Nginx 作为中间层,在配置文件中耦合了服务调用的逻辑,这削弱了微服务的完整性,也使得 Nginx 在一定程度上变成了一个重量级的 ESB。图 1 标识出了 Nginx 的转发信息流走向。
图 1 Nginx 转发的信息流
服务的信息分散在各个系统,无法统一管理和维护。每一次的服务调用都是一次尝试,服务消费方并不知道有哪些实例在给他们提供服务。这带来了一些问题:
- 无法直观地看到服务提供方和服务消费方当前的运行状况与通信频率;
- 消费方的失败重发、负载均衡等都没有统一策略,这加大了开发每个服务的难度,不利于快速演化。
为了解决上面的问题,我们需要一个现成的中心组件对服务进行整合,将每个服务的信息汇总,包括服务的组件名称、地址、数量等。
服务的调用方在请求某项服务时首先通过中心组件获取提供服务的实例信息(IP、端口等),再通过默认或自定义的策略选择该服务的某一提供方直接进行访问,所以考虑引入 Dubbo。
Dubbo 是阿里开源的一个 SOA 服务治理解决方案,文档丰富,在国内的使用度非常高。图 2 为 Dubbo 的基本架构图,使用 Dubbo 构建的微服务已经可以较好地解决上面提到的问题。</