主页

索引

模块索引

搜索页面

API网关

作用:

1. 认证鉴权
2. 不同协议
3. 负载均衡
4. 请求转发(包括服务发现)
    a. 减少客户端和微服务之间的通信次数: 同时请求所有需要的服务,然后将结果组合发回给客户端
    b. 判断服务的主从节点,实现读写分离
    c. 记录服务实例每个节点的基础响应时间,优先处理高优先级的 API 调用
5. 晌应转换
    根据客户端(app, 网站)的不同,访问不同的内部服务
6. 断路器

The API Gateway encapsulates the internal system architecture and provides an API that is tailored to each client.
It might have other responsibilities such as authentication, monitoring, load balancing, caching, request shaping and management, and static response handling.
The API Gateway is responsible for request routing, composition, and protocol translation.

优点如下:

1. 微服务可以专注于业务逻辑本身:
2. 客户端可以通过一次请求得到所有需要的数据
3. 可以通过 API 网关来做认证、日志和监控
4. 可以解决客户端和微服务使用完全不同协议的问题
5. 可以根据客户端需要对结果进行一些裁剪
6. 可以处理局部失败问题。

劣势如下:

1. 如果 API 网关做的事情过多,可能会影响性能
2. 要想使用 API 网关必须先有服务发现
3. 有些时候,API 网关会成为单点失败的风险点,因为它承载了所有 API 的入口
4. 需要额外增加管理路由的任务量
5. 增加了额外的网络请求,也就是说先从 API 网关走了 一道
6. 总的来说,API 网关增加了系统复杂性
7. 在API网关中实现太多逻辑的话,会导致一些依赖问题

orchestration(编制):

指管弦乐编曲,编审这种模式是从管弦乐队的指挥这种角色衍生而来的
    挥舞指挥棒来控制每个音乐家什么时候演奏,最终完成一次完整的演出
微服务中需要一个调度服务来扮演管弦乐队 (这里类比的是多个微服务组成的集群)中指挥的角色
    指挥的工作是通过一些标志来安排各个微服务的工作,每个微服务会相应地做出回应
    一般来说,这种模式中个体微服务是不会相互通信的

优势:
    这种模式下修改工作流会比较简单
挑战在于:
    这种模式下调度服务的权力过于集中,所有服务的启动都始自这个中心调度服务
    运行和维护这样一个调度服务是有很高成本的。
    另外一个问题是,这种调度服务自然而然就成了整个架构中单点故障的隐患

choreography(编排):

指舞蹈团编排,每个人按照预先定义好的步骤跳舞即可,某些时候舞者需要相互配合,某些时候大家都是同步的

在编制模式中,由调度服务负责调遣所有的服务,
而在编排模式中,各个微服务都是相互协同工作的,在交互中会涉及每一个微服务
与编制模式不同的是,编排模式中,每个组件按照各自预先定义的任务来相互协作。

编排模式中倾向于使用异步通信方式,因为没有中心调度服务的存在
    每个组件只需在完成各自任务时广播事件即可,此方式下各个服务间实现了解耦和独立
    每个组件只需监听一个特殊的事件或者消息,然后在其他组件发出这种事件或消息时做出响应
在编排模式中,服务之间通过「消息」、「订阅渠道」或者「主题」来观察其系统环境

优势:
    使用编排方式时,对微服务进行解耦以及添加新服务和移除老服务都非常简单
挑战:
    编排模式增加了系统的复杂性,每个服务都在运行时产生和消费消息
    因此,没有太好的办法能识别事务的确切状态
    服务需要有其自己的专门实现才能观察到整个系统的当前状态
1. 基于消息的异步通信
2. 基于事件的异步通信
区别:
    a. 基于消息的通信是点对点边信的,而基于事件的通信通常是一种发布/订阅模式
    b. 在消息驱动型通信中,聚合是通过预定义的消息队列或者通道来完成的。
        而在事件驱动或者基于命令的通信方式中,预先定义的格式应该是所有服务共享的。
    c. 消息驱动模式,服务 A 向预定义的队列发布了一条消息,
        也就是说,逻辑上来讲服务 A 此时是知道服务 B 的存在的,
        服务 A 知道服务 B 会监听这个队列中的消息然后根据消息内容进行后续动作
    而在事件驱动的通信方式中,服务 A 发出一个事件之后,就可以忘记该事件了。
        这个发布出来的事件可能会被服务 B 使用,也可能被服务 D 使用

代理和网关有什么区别

代理:

代理(英语:Proxy)也称网络代理,是一种特殊的网络服务,
    允许一个网络终端(一般为客户端)通过这个服务与另一个网络终端(一般为服务器)进行非直接的连接。

备注

一般认为代理服务有利于保障网络终端的隐私或安全,防止攻击。

网关:

在计算机网络中,网关(英语:Gateway)是转发其他服务器通信数据的服务器,
    接收从客户端发送来的请求时,它就像自己拥有资源的源服务器一样对请求进行处理。
    有时客户端可能都不会察觉,自己的通信目标是一个网关。

网关也经常指把一种协议转成另一种协议的设备,比如语音网关。

备注

现在的网关很多情况下都是对外提供 HTTP 协议进行通信,内部是非 HTTP 协议通信。

这里的区别都是严格意义上来说的:

代理服务器可以做任何信息过滤,但是网关不会。
代理的协议不会转变,但是网关一般都会转换协议,所以网关也相对安全。

根据 RFC2616 标准,对 HTTP 协议来说:

1. 代理是被视为通信的参与方,是对双方透明的一个中间方而且可以改写用户 / 服务器所发出的请求 / 回复。
2. 而网关则是一个回复用户请求的服务端代理人,对用户来说是完全不透明的,
    可能的职责之一是将用户的请求翻译成其他协议理解的形式,比如说 nginx->Apache。
3. 隧道是一个盲目转发的代理(不改变任何请求 / 回复内容),
   在启用后对 HTTP 协议来说完全不透明,标准中指出隧道的使用是为了跨越防火墙或者其他障碍。
   一个关键的区别在于隧道不允许缓存用户请求和服务器回复。

备注

网关做协议转换,比如 http 到 grpc 的转换。通常的做法是制定标准,然后按照标准转化,网关不应该理解实际的接口含义。

主页

索引

模块索引

搜索页面