简单介绍 Husky 框架的初衷

形成Husky框架的初衷

前端请求过来之后后端服务网关根据调用的服务类型，分别调用对应类型的服务。

调用 Dubbo 服务，需要将原本前端基于 HTTP 协议的请求转换为基于 Dubbo 协议的 RPC 请求，从而调用到后台服务。

调用 HTTP 服务，需要将原本前端基于 HTTP 协议的请求直接通过该服务网关反向代理至对应的后台服务，从而完成 RPC 请求。

注意：此时的反向代理是在我们的 well-web 上完成！！

如下图所示：

说明：

• 当前架构体系中，Dubbo 服务提供者会自动注册自身的信息到 Zookeeper 注册中心，Dubbo 服务消费者（也就是我们的后端服务网关）会自动从注册中心拉取信息，并从中选择合适的 Dubbo 服务提供者进行 RPC 调用。也就是说，我们系统目前只支持 Dubbo 微服务，而且可以简单通过 Dubbo 的配置完成微服务的分布式调用。

• 由于我们需要部署 well-designer 后台服务，目前的系统架构做细微的调整，如上图所示，增加基于 HTTP 服务的微服务 RPC 过程。此时，需要完成的工作如下：

  1. 后端服务网关的反向代理，使用 HTTP-Proxy-Servlet 或者 Charon（推荐）；
  2. HTTP 服务向 Zookeeper 注册中心同步注册提供者信息；
  3. 后端服务网关从 Zookeeper 注册中心同步拉取 HTTP 服务提供者信息；
  4. 后端服务网关的反向代理中配置的目标地址根据所拉取的 HTTP 服务提供者信息做实时的更新；
  5. 后端服务网关的反向代理需要根据多个目标地址做负载均衡；
  6. 经过以上五步处理之后，well-designer 就可以纳入到系统的整体微服务中正常运行；

仓库地址： https://github.com/HweiH/husky