56 | 管理设计：网关模式
陈皓
该思维导图由 AI 生成，仅供参考
你好，我是陈皓，网名左耳朵耗子。
前面，我们讲了 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/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
分布式系统设计模式中的“网关模式”是一种旨在简化分布式系统架构复杂性的管理设计。相比于Sidecar和Service Mesh，网关模式通过集中式的网关管理服务集群，实现了对系统架构的简化和可控性。网关模式具备请求路由、服务注册、负载均衡、弹力设计、安全功能等多种设计功能，同时还能实现灰度发布、API聚合、API编排等有趣的功能。在技术设计上，网关需要具备高性能、高可用和高扩展性，同时需要考虑运维、架构和安全等方面的设计原则。总的来说，网关模式为分布式系统架构提供了一种更加简单、可控的管理设计方式。文章还提到了网关模式的设计重点、运维原则和架构注意事项，以及安全方面的考虑。总体而言，网关模式在分布式系统中具有重要的作用，能够有效简化系统架构、降低运维成本，并提供弹性设计和安全保障。 文章还提到了网关模式的设计重点、运维原则和架构注意事项，以及安全方面的考虑。总体而言，网关模式在分布式系统中具有重要的作用，能够有效简化系统架构、降低运维成本，并提供弹性设计和安全保障。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《左耳听风》，新⼈⾸单¥98
《左耳听风》，新⼈⾸单¥98
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(21)
- 最新
- 精选
于斯人也微服务之间的"内部"互相调用是否经过gateway2018-05-03817
nut分享一下我们用到的网关，工作中内网微服务主要是HSF，而网关对我们来说，是服务对外开放给外部用户的渠道，他帮我们实现了软件商的资格审核备案，API调用权限管理，用户和软件商的三方授权，调用健康度管理，用户纬度的限流熔断，API内部协议和外部协议之间的转换，全球网络专线的优化，API纬度的监控告警。 大家工作中的网关都是什么用途呢？2018-05-15213
约书亚关于网关看了很多资料，也有项目实践，但始终很困惑，请点播一二 从我收集的资料来看，微服务网关一般有如下作用：路由/流控，鉴权，协议转换，服务聚合/编排，监控，日志，熔断，限流... 我现在的架构，前面nginx只做路由，下游接“不同大业务块的网关”，这个网关简单理解就是人工编码的应用，未采用zuul，kong一类开源组件，做以上所有工作，我一直觉得以上设计和其他文章中对网关的定义差异很大，仿佛他们的网关能通过一个统一框架实现所有事情，除了聚合/编排 我的疑问是，能不能说鉴权算不算一种业务逻辑？因为有的鉴权比较复杂，聚合和编排是否更涉及到了业务逻辑？如果整个系统只有在用户-系统的边界有一/几个网关，如果其中包含了大量的鉴权和聚合/编排，那就太臃肿了？既然网关的功能这么复杂，现在的主流框架主要还是解决性能和路由的问题，那还要他们干什么呢？随便一个高效的web框架不是也可以么？（只考虑7层） 那在我们设计系统中，在思考“网关到底要承载哪些功能”时，什么样的参数是要重点考虑的呢？有什 建议极客时间的所有课程增加定期答疑的环节2018-05-0347
👻wusir 👻耗叔，我正在做一个接入层的网关，看了你的这篇文章有个疑问，我在实现token bucket的时候发现：既然网关需要集群化，那么限流这样一个需要对api集中计算速率的事情，怎么在网关集群的多节点中共享这种高并发的调用纪录呢？我现在采用redis+lua脚本实现全局限流的，但是我也不想依赖于redis这样一个三方缓存系统，请问有什么好的建议么？盼复。另外如果可以的话，读者群是否可以pick一下我，谢谢！2018-06-1414- Ken一直对服务聚合有比较多的疑问，聚合可能包括以下三种情况，假设后端服务A和B。第一种：简单的A+B的返回，第二种：A+B返回还需进一步数据转换再返回，第三种：需要先访问A，依赖A的结果再调用B。以上三种方式，哪些适合在网关层聚合处理？网关聚合处理有什么比较好的参考实现？2018-05-0314
宝爷我这边的Gateway设计包含了权限验证，协议路由，防刷等功能，这里的观点在服务间都是tcp长连接的应用场景下是比较合适的【游戏业务，需要有一些服务端主动推送给客户端的高实时性需求】。 协议路由这块我是用一个配置来规划每个协议应该发往哪里，发送的路由规则也是可配置的，Gateway后端的服务之间的通讯都是通过Gateway转发，通过一套内部协议进行转发，服务间的调用相当于调用一个sendToServer(serverid, msg, ...)。 个人认为这样的好处是简化了业务服务的处理，只需要关注Gateway，而不需要知道其他服务的更详细的信息，完全屏蔽了其他服务的部署情况。且简化了网络结构，如果后面的服务直接需要互联那么这个只有一两层的树状结构就会变成网状结构，他们之间的异常处理，重连等等就会变得复杂难以维护。 如果是基于http的微服务，那我认为通过注册中心获取服务，然后直接调用也是可以的，但经过Gateway去做这件事情可以有更大的控制力。2019-01-3113
cornor我们线上的服务分布式，用的是云平台上的负载均衡。模式类似于网关，不过缺少网关的流量控制，弹力设计等。接下来准备用go实现一个网关，把我们的架构升级一下2018-05-033
文刂 氵共 超坚持学习，学习笔记 https://mubu.com/colla/72fdck5DY002020-01-052
邹陈硕在知乎上说：epoll是同步的2018-09-2132
邓志国感觉网关应该分两种，一种对内，基本不变，和业务逻辑无关。一种对外，实现api组合鉴权等。这两部分诉求不同，放一起是否很难做？2018-05-032
收起评论
