zoukankan      html  css  js  c++  java
  • 架构模式: 客户端服务发现

    模式: 客户端服务发现

    背景

    不同服务之间通常需要相互调用。在单体应用程序当中,服务间通过语言层级的方法或者过程实现相互调用。在传统的分布式系统部署下,服务在固定并且已知的位置(主机与端口)运行,从而确保各服务可利用HTTP/REST或者某种RPC机制进行相互调用。然而,现代化微服务应用程序中通常在虚拟化或者容器化环境中运行,在这样的环境中服务的实例数量和位置是动态变化的。

    因此,要想实现客户端向动态变化的一组服务端实例发送请求,我们必须采用新的机制。

    问题

    服务的客户端——包括API网关或者其它服务——如何才能获取服务端实例的位置?

    需求

    • 每一服务实例都会在特定位置(主机与端口)通过HTTP/REST或者Thrift等方式发布一个远程API。
    • 服务端实例的具体数量及位置会发生动态变化。
    • 虚拟机与容器通常会被分配动态IP地址。
    • 服务实例的数量会发生动态变化。例如,EC自动伸缩组会根据负载情况随时调整实例数量。

    方案

    在向某一服务发送请求时,客户端会通过查询 Service Registry,即服务注册表,以获取该服务实例的位置。该注册表中包含全部服务的位置。

    以下示意图展现了这种模式的结构:

    而这正是微服务基底框架的典型处理方式。

    例子

    Netflix OSS 正是客户端发现机制的典型代表:

    • Eureka 充当其中的服务注册表
    • Ribbon Client 是一套HTTP客户端,负责向 Eureka 发出查询任务并将 HTTP 请求路由至可用的服务实例。

    结果

    客户端发现机制拥有以下优势:

    • 相较于服务器端服务发现,其活动部件与网络中转数量更少。

    客户端发现机制亦存在着以下弊端:

    • 这一模式使客户端与服务注册表相耦合。
    • 需要为应用程序中使用的每种编程语言/框架建立客户端服务发现逻辑,例如Java/Scala以及JavaScript/Node JS。举例来说,Netflix Prana 就为非 JVM 客户端提供了一套基于HTTP代理的服务发现方案。

    相关模式

    • 服务注册表 - 服务发现的基础
    • 微服务的基底 - 客户端服务发现是微服务基底模块的职责之一
    • 服务器端服务发现 是另一种可选的方案
  • 相关阅读:
    接口框架项目示例
    接口框架开发流程总结
    requests库的简单使用
    使用flask创建简单的接口
    session和token
    解决log函数生成重复log的问题
    自定义封装logging参考
    织梦dedecms做的网站首页标题篡改跳转赌博网站解决方案
    织梦网站安全查杀
    织梦重置密码的方法和织梦网站后台登陆账号修改方法
  • 原文地址:https://www.cnblogs.com/paxlyf/p/11289539.html
Copyright © 2011-2022 走看看