N17
中文
中文
  • N17 白皮书
    • 项目介绍
    • 平台亮点
  • 交易模式
    • 铸造
    • 发行
    • 交易
    • 生态激励
  • 技术体系
    • N17多链混合架构
      • UTXO 模型与账户模型
      • 抽象账户合约层和虚拟机的集成
      • EVM集成与交易流程
    • API & WebSocket
    • SpringCloud微服务架构
      • Feign(接口调用)
      • Netflix eureka(注册发现)
      • Ribbon(负载均衡)
      • Hystrix(熔断器)
      • Zuul(微服务网关)
      • SpringCloud( 统一配置服务)
      • Sleuth+ZipKin(跟踪服务)
    • 撮合交易引擎
      • 撮合系统
      • 基准价格选取算法
    • Wallet接口与拓展性
    • SpringSecurity+Web3.0签名验证
    • Seata
      • AT模式(与XA模式在编程模型上保持完全一致)
        • 整体机制
        • 写隔离
        • 读隔离
        • 一阶段过程
        • 二阶段-回滚过程
        • 二阶段-提交过程
      • TCC模式
      • SAGA模式
    • Mongodb数据仓库
      • 数据逻辑结构与存储结构
      • MongoDB相比传统开源数据库优势
  • DAO社区
    • N17 DAO的使命
    • N17 DAO的服务体系
    • N17 DAO的治理流程
    • 全球开发者社区
  • 风险提示与免责声明
Powered by GitBook
On this page
  1. 技术体系
  2. SpringCloud微服务架构

Zuul(微服务网关)

不同的微服务一般会有不同的网络地址,而外部客户端可能需要调用多个服务的接口才能完成一个业务需求。例如一个电影购票的手机APP,可能调用多个微服务的接口才能完成一次购票的业务流程,如果让客户端直接与各个微服务通信,会有以下的问题:

(a)客户端会多次请求不同的微服务,增加了客户端的复杂性。

(b)存在跨域请求,在一定场景下处理相对复杂。

(c)认证复杂,每个服务都需要独立认证。

(d)难以重构。随着项目的迭代,可能需要重新划分微服务。例如,可能将多个服务合并成一个或者将一个服务拆分成多个。如果客户端直接与微服务通信,那么重构将很难实施。

(e)某些微服务可能使用了对防火墙/浏览器不友好的协议,直接访问时存在困难。

以上问题可利用微服务网关解决。微服务网关是介于客户端和服务器端之间的中间层,所有的外部请求都会先经过微服务网关。使用微服务网关后,微服务网关将封装应用程序的内部结构,客户端只用跟网关交互,而无须直接调用特定微服务的接口。这样,开发就可以得到简化。不仅如此,使用微服务网关还有以下优点:

a)易于监控。可在微服务网关收集监控数据并将其推送到外部系统进行分析。

(b)易于认证。可在微服务网关上进行认证,然后再将请求转发到后端的微服务,而无须在每个微服务中进行认证。

(c)减少了客户端与各个微服务之间的交互次数。

PreviousHystrix(熔断器)NextSpringCloud( 统一配置服务)

Last updated 2 years ago