左耳听风
陈皓
网名“左耳朵耗子”,资深技术专家,骨灰级程序员
立即订阅
40357 人已学习
课程目录
已完结 108 讲
0/6登录后,你可以任选6讲全文学习。
开篇词 | 洞悉技术的本质,享受科技的乐趣
免费
01 | 程序员如何用技术变现(上)
02 | 程序员如何用技术变现(下)
03 | Equifax信息泄露始末
04 | 从Equifax信息泄露看数据安全
05 | 何为技术领导力?
06 | 如何才能拥有技术领导力?
07 | 推荐阅读:每个程序员都该知道的知识
08 | Go语言,Docker和新技术
09 | 答疑解惑:渴望、热情和选择
10 | 如何成为一个大家愿意追随的Leader?
11 | 程序中的错误处理:错误返回码和异常捕捉
12 | 程序中的错误处理:异步编程以及我的最佳实践
13 | 魔数 0x5f3759df
14 | 推荐阅读:机器学习101
15 | 时间管理:同扭曲时间的事儿抗争
16 | 时间管理:如何利用好自己的时间?
17 | 故障处理最佳实践:应对故障
18 | 故障处理最佳实践:故障改进
19 | 答疑解惑:我们应该能够识别的表象和本质
20 | Git协同工作流,你该怎么选?
21 | 分布式系统架构的冰与火
22 | 从亚马逊的实践,谈分布式系统的难点
23 | 分布式系统的技术栈
24 | 分布式系统关键技术:全栈监控
25 | 分布式系统关键技术:服务调度
26 | 分布式系统关键技术:流量与数据调度
27 | 洞悉PaaS平台的本质
28 | 推荐阅读:分布式系统架构经典资料
29 | 推荐阅读:分布式数据调度相关论文
30 | 编程范式游记(1)- 起源
31 | 编程范式游记(2)- 泛型编程
32 | 编程范式游记(3) - 类型系统和泛型的本质
33 | 编程范式游记(4)- 函数式编程
34 | 编程范式游记(5)- 修饰器模式
35 | 编程范式游记(6)- 面向对象编程
36 | 编程范式游记(7)- 基于原型的编程范式
37 | 编程范式游记(8)- Go 语言的委托模式
38 | 编程范式游记(9)- 编程的本质
39 | 编程范式游记(10)- 逻辑编程范式
40 | 编程范式游记(11)- 程序世界里的编程范式
41 | 弹力设计篇之“认识故障和弹力设计”
42 | 弹力设计篇之“隔离设计”
43 | 弹力设计篇之“异步通讯设计”
44 | 弹力设计篇之“幂等性设计”
45 | 弹力设计篇之“服务的状态”
46 | 弹力设计篇之“补偿事务”
47 | 弹力设计篇之“重试设计”
48 | 弹力设计篇之“熔断设计”
49 | 弹力设计篇之“限流设计”
50 | 弹力设计篇之“降级设计”
51 | 弹力设计篇之“弹力设计总结”
52 | 管理设计篇之“分布式锁”
53 | 管理设计篇之“配置中心”
54 | 管理设计篇之“边车模式”
55 | 管理设计篇之“服务网格”
56 | 管理设计篇之“网关模式”
57 | 管理设计篇之“部署升级策略”
58 | 性能设计篇之“缓存”
59 | 性能设计篇之“异步处理”
60 | 性能设计篇之“数据库扩展”
61 | 性能设计篇之“秒杀”
62 | 性能设计篇之“边缘计算”
63 | 区块链技术的本质
64 | 区块链技术细节:哈希算法
65 | 区块链技术细节:加密和挖矿
66 | 区块链技术细节:去中心化的共识机制
67 | 区块链技术细节:智能合约
68 | 区块链技术 - 传统金融和虚拟货币
69 | 程序员练级攻略:开篇词
70 | 程序员练级攻略:零基础启蒙
71 | 程序员练级攻略:正式入门
72 | 程序员练级攻略:程序员修养
73 | 程序员练级攻略:编程语言
74 | 程序员练级攻略:理论学科
75 | 程序员练级攻略:系统知识
76 | 程序员练级攻略:软件设计
77 | 程序员练级攻略:Linux系统、内存和网络
78 | 程序员练级攻略:异步I/O模型和Lock-Free编程
79 | 程序员练级攻略:Java底层知识
80 | 程序员练级攻略:数据库
81 | 程序员练级攻略:分布式架构入门
82 | 程序员练级攻略:分布式架构经典图书和论文
83 | 程序员练级攻略:分布式架构工程设计
84 | 程序员练级攻略:微服务
85 | 程序员练级攻略:容器化和自动化运维
86 | 程序员练级攻略:机器学习和人工智能
87 | 程序员练级攻略:前端基础和底层原理
88 | 程序员练级攻略:前端性能优化和框架
89 | 程序员练级攻略:UI/UX设计
90 | 程序员练级攻略:技术资源集散地
91 | 程序员面试攻略:面试前的准备
92 | 程序员面试攻略:面试中的技巧
93 | 程序员面试攻略:面试风格
94 | 程序员面试攻略:实力才是王中王
95 | 高效学习:端正学习态度
96 | 高效学习:源头、原理和知识地图
97 | 高效学习:深度,归纳和坚持实践
98 | 高效学习:如何学习和阅读代码
99 | 高效学习:面对枯燥和量大的知识
左耳听风
登录|注册

56 | 管理设计篇之“网关模式”

陈皓 2018-04-12
前面,我们讲了 Sidecar 和 Service Mesh 这两种设计模式,它们都是在不侵入业务逻辑的情况下,把控制面(control plane)和数据面(data plane)的处理解耦分离。但是这两种模式都让我们的运维成本变得特别大,因为每个服务都需要一个 Sidecar,这让本来就复杂的分布式系统的架构就更为复杂和难以管理了。
在谈 Service Mesh 的时候,我们提到了 Gateway。我个人觉得并不需要为每个服务的实例都配置上一个 Sidecar。其实,一个服务集群配上一个 Gateway 就可以了,或是一组类似的服务配置上一个 Gateway。
这样一来,Gateway 方式下的架构,可以细到为每一个服务的实例配置一个自己的 Gateway,也可以粗到为一组服务配置一个,甚至可以粗到为整个架构配置一个接入的 Gateway。于是,整个系统架构的复杂度就会变得简单可控起来。
这张图展示了一个多层 Gateway 架构,其中有一个总的 Gateway 接入所有的流量,并分发给不同的子系统,还有第二级 Gateway 用于做各个子系统的接入 Gateway。可以看到,网关所管理的服务粒度可粗可细。通过网关,我们可以把分布式架构组织成一个星型架构,由网络对服务的请求进行路由和分发,也可以架构成像 Servcie Mesh 那样的网格架构,或者只是为了适配某些服务的 Sidecar……
但是,我们也可以看到,这样一来,Sidecar 就不再那么轻量了,而且很有可能会变得比较重了。
总的来说,Gateway 是一个服务器,也可以说是进入系统的唯一节点。这跟面向对象设计模式中的 Facade 模式很像。Gateway 封装内部系统的架构,并且提供 API 给各个客户端。它还可能有其他功能,如授权、监控、负载均衡、缓存、熔断、降级、限流、请求分片和管理、静态响应处理,等等。
下面,我们来谈谈一个好的网关应该有哪些设计功能。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《左耳听风》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(14)

  • microshaoft
    微服务之间的"内部"互相调用是否经过gateway
    2018-05-03
    2
    9
  • nut
    分享一下我们用到的网关,工作中内网微服务主要是HSF,而网关对我们来说,是服务对外开放给外部用户的渠道,他帮我们实现了软件商的资格审核备案,API调用权限管理,用户和软件商的三方授权,调用健康度管理,用户纬度的限流熔断,API内部协议和外部协议之间的转换,全球网络专线的优化,API纬度的监控告警。

    大家工作中的网关都是什么用途呢?
    2018-05-15
    4
  • 约书亚


    关于网关看了很多资料,也有项目实践,但始终很困惑,请点播一二
    从我收集的资料来看,微服务网关一般有如下作用:路由/流控,鉴权,协议转换,服务聚合/编排,监控,日志,熔断,限流...
    我现在的架构,前面nginx只做路由,下游接“不同大业务块的网关”,这个网关简单理解就是人工编码的应用,未采用zuul,kong一类开源组件,做以上所有工作,我一直觉得以上设计和其他文章中对网关的定义差异很大,仿佛他们的网关能通过一个统一框架实现所有事情,除了聚合/编排
    我的疑问是,能不能说鉴权算不算一种业务逻辑?因为有的鉴权比较复杂,聚合和编排是否更涉及到了业务逻辑?如果整个系统只有在用户-系统的边界有一/几个网关,如果其中包含了大量的鉴权和聚合/编排,那就太臃肿了?既然网关的功能这么复杂,现在的主流框架主要还是解决性能和路由的问题,那还要他们干什么呢?随便一个高效的web框架不是也可以么?(只考虑7层)
    那在我们设计系统中,在思考“网关到底要承载哪些功能”时,什么样的参数是要重点考虑的呢?有什
    建议极客时间的所有课程增加定期答疑的环节
    2018-05-03
    1
    3
  • 陈硕在知乎上说:epoll是同步的
    2018-09-21
    1
    2
  • Ken
    一直对服务聚合有比较多的疑问,聚合可能包括以下三种情况,假设后端服务A和B。第一种:简单的A+B的返回,第二种:A+B返回还需进一步数据转换再返回,第三种:需要先访问A,依赖A的结果再调用B。以上三种方式,哪些适合在网关层聚合处理?网关聚合处理有什么比较好的参考实现?
    2018-05-03
    2
  • 邓志国
    感觉网关应该分两种,一种对内,基本不变,和业务逻辑无关。一种对外,实现api组合鉴权等。这两部分诉求不同,放一起是否很难做?
    2018-05-03
    2
  • cornor
    我们线上的服务分布式,用的是云平台上的负载均衡。模式类似于网关,不过缺少网关的流量控制,弹力设计等。接下来准备用go实现一个网关,把我们的架构升级一下
    2018-05-03
    2
  • 👻wusir 👻
    耗叔,我正在做一个接入层的网关,看了你的这篇文章有个疑问,我在实现token bucket的时候发现:既然网关需要集群化,那么限流这样一个需要对api集中计算速率的事情,怎么在网关集群的多节点中共享这种高并发的调用纪录呢?我现在采用redis+lua脚本实现全局限流的,但是我也不想依赖于redis这样一个三方缓存系统,请问有什么好的建议么?盼复。另外如果可以的话,读者群是否可以pick一下我,谢谢!
    2018-06-14
    1
    1
  • 尘埃观世界
    而且 Gateway 只负责进入的请求,不像 Sidecar 还需要负责对外的请求?

    不是很明白这句的意思.还望解释下.
    2019-11-12
  • edisonhuang
    网关是进入系统的唯一入口,需要完成服务路由,服务注册,负载均衡,可弹力伸缩,并且保证安全性。需要是高性能,高可用和高扩展的。实施过程也要避免和业务层面有耦合,而应专注在通讯层面的内容
    2019-07-19
  • 靠人品去赢
    这篇文章只看文章原文,会有一个内容很少的错觉,但是看一眼音频的长度,知道这并不简单。
    2019-06-24
  • 宝爷
    我这边的Gateway设计包含了权限验证,协议路由,防刷等功能,这里的观点在服务间都是tcp长连接的应用场景下是比较合适的【游戏业务,需要有一些服务端主动推送给客户端的高实时性需求】。
    协议路由这块我是用一个配置来规划每个协议应该发往哪里,发送的路由规则也是可配置的,Gateway后端的服务之间的通讯都是通过Gateway转发,通过一套内部协议进行转发,服务间的调用相当于调用一个sendToServer(serverid, msg, ...)。
    个人认为这样的好处是简化了业务服务的处理,只需要关注Gateway,而不需要知道其他服务的更详细的信息,完全屏蔽了其他服务的部署情况。且简化了网络结构,如果后面的服务直接需要互联那么这个只有一两层的树状结构就会变成网状结构,他们之间的异常处理,重连等等就会变得复杂难以维护。
    如果是基于http的微服务,那我认为通过注册中心获取服务,然后直接调用也是可以的,但经过Gateway去做这件事情可以有更大的控制力。
    2019-01-31
  • 沫沫(美丽人生)
    老师晚上好,我们最近想开发一个这样的SaaS软件,用户可以绑定不同的邮件帐号(如QQ和163等),可以在我们的邮箱里接收邮件,也可以发送邮件,并且用户的邮件也需要存储在我们的服务器上(数据安全及数据同步策略),这方面有有一些开源的项目可以做二次开发吗?如果没有,能否讲讲邮件服务器开发方面的核心技术及思路呢?如果有相关的资料,也可以推荐给我。万分感谢,盼复!
    2018-05-07
  • Ken
    一直纠结是否要在网关层做业务参数校验,看了文中的说明,大概了解了处理的原则,感谢!
    2018-05-03
收起评论
14
返回
顶部