有微服务难题?你需要强大的网关!

图灵奖获得者、美国国家科学院院士、计算机科学家巴特勒·兰普森(Butler Lampson)有句著名的格言:“计算机科学中的任何问题大都可以通过增加中间层解决(Any problem in computer science can be solved with another level of indirection)”,分层使我们有更多想象空间,实现了“不可能”到“可能”,从逻辑电路、硬件体系、汇编语言、高级语言,到操作系统、软件设计、软件架构、网络协议、网络设备等,都充分体现了分层的思想。分层不仅可以使彼此之间边界清晰、职责分离、共享复用,而且可以进行进一步的信息处理、流程控制、行为控制,还有助于后期的移植扩展、维护管理。最为常见的有交换机、路由器、计算机主板、缓存、队列、虚拟内存管理、CDN、CPU Cache、TCP、HTTP、HTTPS、HTTP2、WebSocket、Thrift、Protobuf、AOP、JIT、JVM、LVS、HAProxy、Envoy、Docker、CGroup、Ingress等。 

网关是上承后端服务下接前端用户的咽喉之地、关隘要道,是所有客户端请求响应出入流量的必经之路。它除了可以做最基础的反向代理之外,还可以处理通用的公共服务逻辑,如负载均衡、认证授权、动态路由、流量调度、数据缓存、限流限频、灰度发布、蓝绿发布、滚动发布、协议转换、请求转换、请求映射、服务编排、服务预热、服务降级、智能熔断、流量镜像、健康检查、跨域请求、监控报警、安全防御等,那么这些在我们日常工作中有哪些与之关联的业务场景,又是如何应用的呢?

时间:2021

地点:DW公司

人物:老板 Jack / IT总监 Justin

场景:SW 公司最新研发了一款 what-app,主打年轻人社交购物平台,致力于为全宇宙的用户网购带来全新省钱体验。

盈利模式:用户分享、发表自己用过的产品,并写出心得,网友点赞就会加分,然后此用户再次购买此商品时,根据点赞加分总和进行相应比例的商品打折,点赞越多折扣就越多(折多多)。同样,如果网友通过这个分享的贴子进行了商品链接的关联购买,也会有一定的优惠(惠多多)。而商家会向 what-app 平台返点,实现真正的“用户、平台、商家”共赢,一举多得(聚多多)。

 

背景:Jack,曾在某IT大厂任职,喜欢前沿事物,思维活跃,久经沙场,身经百战,现在出来创业。 

1. 负载均衡

JackJustin,通过我们最新的监控数据显示,what-app 仅仅上线 3 天,注册用户已突破 5 万人大关,新用户还在持续爆炸性增加,CPU/内存/带宽趋于上升,按此趋势,我们需要立即对系统资源进行容量评估,并适当增加扩容服务器资源,让我们的每台服务器可以平均承载分担请求压力,以避免影响用户的流畅体验,此时应该采用何种负载策略:轮询、随机还是哈希?

另外,随着公司的高速发展,后期我们还需要在重点城市进行多数据中心部署,采用公有云与私有云相结合的方式,需要有跨地域、跨机房的服务通信、就近访问、负载均衡、健康探测、失效备援、故障转移的服务能力。

2. 认证授权

JackJustin,我们现在的用户权限鉴权逻辑散落在每台服务器的站点服务中,是否可以将目前基于 RBAC 角色的认证逻辑和对外开放平台所使用的 OAuth 授权认证完全抽离出来,统一前置至网关或独立的代理进程中,你看可否可行?这既可以减少通用逻辑与业务模块之间的耦合和入侵,降低出错概率,也可以让开发人员专注于业务开发,快速响应用户需求,缩短交付周期,提高迭代效率。

 3. 动态路由

JackJustin,昨天我们站点服务中一个极为普通且不常用的功能出了问题,结果影响了整体站点的重要功能和流程正常运行,这得有个解决方案。最近不是流行基于微服务/服务网格的架构风格和中台战略嘛,我们的研发部门也尽快调研一下,现在后台站点服务太笨重了,所有的业务模块功能全都在一个进程中运行,牵一发而动全身,这种“巨石”“烟囱”“All in one”式的单体应用臃肿膨胀、无法复用、风险极高,如果按领域划分成不同的微服务后,需要考虑如何通过一个统一的主域名进行访问,然后根据子路径标识划分对应后面的微服务,将请求路由正确转发至相应的服务器,这样路由策略也可能会随着业务的变化,需要实时调整。在这个过程中,我们要求不能重启服务进程,以免影响或中断当前用户的任何正常请求。

4. 数据缓存

JackJustin,通过监控发现我们的数据库压力很大,存在很大瓶颈和风险,是不是需要考虑下读写分离、分库分表,或者将一些热数据进行本地缓存,或者将前置网关进行分布式缓存或队列处理?在这个过程中,还需要重点考虑缓存穿透、缓存击穿、缓存雪崩、缓存实时性、有效性、一致性等问题。

 5. 灰度发布

JackJustin,我们的 App 刚上了一个新功能“种草连连看”(有相同购买需求的人集结再团购),需要只放 5% 的用户流量请求过来,其他 95% 的用户无法用到此新功能,每天自动放 5% 的流量,连续放 10 天到达 50%,然后再一次性全部放开给所有用户。在此期间,我们也可以对新功能加以验证,尽早获取用户意见,完善产品功能,提升产品质量,并对性能和稳定性加以观测优化,提前发现问题、解决问题,尽可能缩小影响范围,最终使我们的升级过程顺利平滑过渡。后期还需要考虑,如何根据各种请求的变量参数等条件,进行更个性化的灰度发布(金丝雀)策略,比如只灰度指定地区的用户,或根据不同的移动设备类型/系统类型进行灰度。

6. 蓝绿发布

JackJustin,我们的线上“惠多多”版本是 V1.1.1 服务,新版本 V1.1.2 部署后,假如我们将所有用户一次性全切到新版本上,是否可行?如果发现问题,是否可以第一时间切回到原来的旧版本? 

7. 滚动发布

JackJustin,现在线上有 5 台 Web 服务器,发布新版本时,是否结合我们的 CI/CD 体系,实现自动滚动发布,即自动下线 1 台,更新 1 台,验证 1 台,上线 1 台……依次将 5 台机器按批次全部自动化发布,或者我们全面应用虚拟化、容器化,通过 Kubernetes 的管理技术来解决滚动发布?

 8. 信息转换

JackJustin,现在用户发布的帖子中,有时会携带着很多敏感信息,比如有可能是身份证号、手机号、银行账号等敏感非法关键字,这个我们是否可以在不改动任何后端业务服务的前提下,实现快速脱敏处理?即通过规则对敏感数据进行变形,在用户请求或响应内容给用户时,直接将这些关键信息的部分内容用***符号代替,以避免用户信息非法传播和泄露,保护用户数据的安全。

 9. 请求重写

Jack喂,Justin 在吗?现在有紧急事务,我们凌晨自动发给所有用户的重要邮件中超链接有错误,在不调整后端业务服务的前提下,需要快速将这个错误链接地址映射到正确的后端服务上,这马上就要天亮了……

10. 服务编排

JackJustin 何时出差回来,刚才前端人员反馈,他们根据一个订单 ID,需要调用请求N次才能拿到商品信息、用户信息、用户评价信息,效率太低,影响用户体验,他是否可以只发 1 个请求就拿到这 3 条信息的 JSON 聚合体或根据条件进行流程化调用?如果可以,最好能有个管理后台,可以以可视化的方式自由编排所需 API 功能,岂不妙哉?

 11. 服务预热

JackJustin,为什么我们每次凌晨升级上线后,第二天早上我们的用户反馈有些慢呢?尤其是一些特别重要的功能和流程,这严重影响了用户体验,这个问题需要优化下或有什么解决方案,让其可以在发布升级上线后,自动调用接口触发预热机制,热数据提前载入缓存?实例提前编译/初始化?长链接/池可以提前建立?让系统提前进入最佳运行状态?

 12. 限流限频

JackJustin,最近有两个问题我们亟待解决。第 1 个问题是,最近我们发现开放平台服务的某个 URL 接口被合作伙伴调用得太多了,需要针对这个特定的 URL 地址和合作伙伴 ID 进行调用频率的限制,比如限制每秒只能调用100 QPS,每天只能调用 1 万次。不然,会将我们的开放平台服务给拖垮,进而影响内部重要服务。你考虑一下采用哪种限流算法比较合适,令牌、漏斗?采用单机还是分布式限流?

还有双 11 即将来临,可能会出现流量大增,如果没有一定的过载保护策略机制,我们的服务也将面临重大考验。可以考虑当我们的 CPU 或内存资源达到 80% 指标,连续超负荷时、服务故障时、网络延迟高等状态不健康或超过阈值时,自动保护上游后端服务,触发限流限频或熔断机制,并即时报警,避免整个服务链条发生雪崩。

第 2 个问题是,某些热帖中带了较大的附件,被大量用户集中下载,我们的运维同学经常会收到带宽报警,此时需要一定的方案策略以及规则,可以对每个用户的下载速度进行限制,比如每秒下载不能超过 800KB/s。总而言之,我们需要做好综合流量评估,提前进行系统测试和演练,制定好应急预案和计划。

 13. 服务降级

JackJustin,最近接到用户反馈,用户页面上的内容有时无法正确加载出现白页,可能是某些服务接口响应过慢或出现错误导致。如果出现这样的现象,我们在记录错误的同时,可以考虑返回一些提前准备好的数据或友好信息,将之呈现给用户,而不是返回错误信息或无任何内容,不然这会给用户带来较差的体验,认为系统不稳定,造成用户黏度、信任度下降,进而发生用户流失,影响 what-app 的品牌形象和公众形象。

 14. 流量镜像

JackJustin,最近商务部反馈说,商家反馈调用我们的系统接口时,偶尔会报错,是何情况?

JustinJack,这件事我们已经在追查之中,已在线下环境反复测试,当前还未找到问题所在,线上生产环境与线下所使用的服务版本均是一样的,推断极有可能是线上特定数据和环境等不同变量因素所引起,现在线上的数据量太大,有些还是核心数据,不方便迁移到线下环境,也无法完全模拟线上环境,所以我们准备采用请求流量镜像复制方案,在不影响用户正常前提下,在线上直接排查问题,具体操作流程和实现细节,我们还需要再调研,还请静候佳音。

15. 监控报警

JackJustin,如果我们的服务错误状态码在连续 1 分钟内超过 50 次,10 分钟内出入流量超过警戒阈值、CPU/内存等度量指标不正常时,是否可以向我们报警,将消息实时推送到微信、钉钉或短信,以使我们第一时间得知生产环境的最新消息,感知系统的运行状态。另外,我们是否可以通过视图报表看到 API 接口的平均响应时间、API 的正确率、高峰期调用数量、客户端设备类型、客户的地域分布、链路轨迹等信息,这些信息可以为我们后期的线上运维、产品服务、市场策略提供决策支持。

 16.  安全防御

JackJustin,我们的服务用户反馈无法访问了,访问速度奇慢,好像被人攻击了,刚刚运维同学查到了有来自某地的 6 个 IP,正在疯狂非法地抓取我们的信息,我们需要立即禁止屏蔽掉这些 IP 来源的非法访问,请和运维同学立即采取措施进行制止。另外,我们需要重点考虑,如何才能自动识别这些异常行为和数据?是否可以通过 WAF 防火墙等方案进行非人工、全自动防御和禁止。

面对这些问题,Justin 如何应对呢?《Kong 入门与实战》这本书给你答案。

本书是 Kong 项目贡献者倾力打造的、国内第 1 本微服务网关书,里面详细介绍了 GitHub 28.3k+ 加星项目 Kong,并由多位业内大咖联袂推荐。

Kong 是一个全新的支持亿级流量、低延迟的云原生网关平台,本书可以帮助读者手把手快速构建、打造具有分布式、高可用、可伸缩、可扩展、高并发、高性能、可观测、可运维等特点的高度可扩展微服务网关。它可供选择的开源插件多达百个,支持公有云、私有云、混合云等多种部署环境和云平台。

本书适合软件开发人员、测试人员、运维人员、安全人员、架构师、技术经理等IT资深人士阅读。

 本书结构

 图书特色

  • 内容全面:几乎涵盖 Kong 网关的所有知识点,内容丰富翔实。

  • 实例演示:每个知识点都配有相应的实战示例,从理论到实战,一应俱全。

  • 深入浅出:从安装到配置、应用到管理、设计到开发,环环相扣、逐层递进。

  • 案例经典:9 大新颖场景案例,既巩固理论又增强实战,使读者可以学以致用。

  • 图文并茂:图解知识、双色印刷、层次分明、重点突出,读者阅读体验更佳。 

众多大咖联袂推荐

  • 网易研究院云计算首席架构师刘超

  • 美团研究员/技术总监刘生权

  • 新浪微博平台研发技术专家周晶

  • 阿里巴巴集团高德架构师张开涛

  • 京东架构师王新栋

  • 蚂蚁金服云原生布道师、ServiceMesher 社区和云原生社区联合创始人宋净超

  • 北森云计算 PaaS 平台数据服务架构师马树东

  • 北森云计算 PaaS 平台微服务架构师王磊

  • 北森云计算 PaaS 平台基础体系部副总裁冷昊

  • 北森云计算高级副总裁孙江

  • 蓝鸟云联合创始人徐东

  •  Kong 公司官方核心技术负责人戴冠兰

大咖推荐

2021年3月

随着微服务的不断兴起,微服务网关和服务网格已经是必不可少的服务治理基础设施了。本书从 Kong 的基本原理出发,由浅入深地介绍了 Kong 的方方面面。本书最后还专门设计了非常实用的实战章节,如果你在工作中遇到了相关场景,可以直接借鉴和参考这里面的例子。总而言之,这本书将是你入门和实践 Kong 的利器。

——刘超,网易研究院云计算首席架构师

本书凝结了作者在工作中的实战经验,从概念、原理、安装部署、使用、管理,再到监控报警、插件开发、案例实践,向读者完整地呈现了 Kong 的整个画像。

——刘生权,美团研究员/技术总监

这本书由浅入深,从基本概念到应用实战,对 Kong 进行了庖丁解牛、细致入微的分析和讲解,从而让读者对 Kong 有了一个更全面、更体系化的认识。此书值得大家拥有,我相信你一定能从中得到不少的收获。

——周晶,新浪微博平台研发技术专家

本书系统介绍了 Kong 的用法,如果你有面向 API 的通用切面问题,本书会给你答案。

——张开涛,阿里巴巴集团高德架构师

Kong 提供了诸如 HTTP 路由认证、请求限流、请求转换、指标监控、自定义开发等一系列 HTTP 网关所必备的基础功能,可以为你提供一站式的解决方案。本书对 Kong 进行了全家桶式的详解,会给网关新手和实践者带来不一样的启发,让你应用和实施 Kong 时可以事半功倍。

——王新栋,京东架构师

作为开源的 API 网关,Kong 在云原生领域得到了广泛的应用,它支持跨平台和异构环境,甚至支持边车代理模式的控制平面和数据平面的部署方式。本书将会成为你了解和应用 API 网关并踏向服务网格领域的阶梯。

——宋净超,蚂蚁金服云原生布道师

ServiceMesher 社区和云原生社区联合创始人

本书既可以作为让你快速入门的书,也可以作为进阶学习的参考资料。换言之,一书在手,用 Kong 无忧。

——马树东,北森云计算 PaaS 平台数据服务架构师

本书是国内第一本对 Kong 做了详尽介绍的书,是作者在实践中的经验总结。书中不仅深入讲解了 Kong 的各个方面(包括部署、运维、调优),还结合实践案例,讲述了如何在 Kong 上扩展定制自己的业务,让读者对 Kong 的能力和使用有一个更深的认识。如果你对 API 网关感兴趣,本书将是一个不错的选择。

——王磊,北森云计算 PaaS 平台微服务架构师

作为国内第一本介绍 Kong 的书,本书的编写完全基于作者在实战中积累的丰富经验,既有详细的功能介绍,也有翔实的案例分析,具备非常强的实战价值。

——冷昊,北森云计算 PaaS 平台基础体系部副总裁

Kong 以其自身的独特优势成了微服务的最佳拍档,而如何学习和用好 Kong 就成为时下一个重要的问题。在此,作者将自身的实战经验总结成册,从 Kong 的引入到 Kong 的核心业务实战案例,详细介绍了每一个细节,其目的是让每一位读者都能够快速了解和掌握 Kong 的核心知识。

——孙江,北森云计算高级副总裁

本书中,Kong 的着眼点落在了目前大热的服务网格/微服务体系上,除此之外,Kong 在运维基础设施中还可以发挥更大的作用。最后,相信读者能够参考并结合本书的经典实战案例,在生产环境中发挥出更大的价值。

——徐东,蓝鸟云联合创始人

能够看到一本系统介绍 Kong 的中文书面世,尤其是其中还涵盖了 2.0 版本的最新功能,我感到由衷的高兴。本书深入浅出、内容全面、案例实用。

——戴冠兰,Kong 公司官方核心技术负责人

作 者 简 介

闫观涛,架构师,Kong 项目贡献者,拥有多年 IT 行业从业经验,目前就职于北森云计算股份有限公司,专注于云原生分布式 SaaS/PaaS 系统的架构和研发,拥有多项国家发明专利。

限时 5 折最后一天

京东传送门

 

1. 图1和图3来自www.freepik.com,图2来自https://www.msra.cn/zh-cn/。

2. 兰普森的那句格言经常被引述为:“计算机科学中的任何问题都可以通过另一种间接解决方案来解决”,但兰普森本人在1993年的图灵奖演讲中将这句话归因于大卫·惠勒。

  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 扫一扫,分享海报

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值