社区微信群开通啦，扫一扫抢先加入社区官方微信群
社区微信群
图灵奖获得者、美国国家科学院院士、计算机科学家巴特勒·兰普森（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. 负载均衡
Jack：Justin，通过我们最新的监控数据显示，what-app 仅仅上线 3 天，注册用户已突破 5 万人大关，新用户还在持续爆炸性增加，CPU/内存/带宽趋于上升，按此趋势，我们需要立即对系统资源进行容量评估，并适当增加扩容服务器资源，让我们的每台服务器可以平均承载分担请求压力，以避免影响用户的流畅体验，此时应该采用何种负载策略：轮询、随机还是哈希?
另外，随着公司的高速发展，后期我们还需要在重点城市进行多数据中心部署，采用公有云与私有云相结合的方式，需要有跨地域、跨机房的服务通信、就近访问、负载均衡、健康探测、失效备援、故障转移的服务能力。
2. 认证授权
Jack：Justin，我们现在的用户权限鉴权逻辑散落在每台服务器的站点服务中，是否可以将目前基于 RBAC 角色的认证逻辑和对外开放平台所使用的 OAuth 授权认证完全抽离出来，统一前置至网关或独立的代理进程中，你看可否可行？这既可以减少通用逻辑与业务模块之间的耦合和入侵，降低出错概率，也可以让开发人员专注于业务开发，快速响应用户需求，缩短交付周期，提高迭代效率。
3. 动态路由
Jack：Justin，昨天我们站点服务中一个极为普通且不常用的功能出了问题，结果影响了整体站点的重要功能和流程正常运行，这得有个解决方案。最近不是流行基于微服务/服务网格的架构风格和中台战略嘛，我们的研发部门也尽快调研一下，现在后台站点服务太笨重了，所有的业务模块功能全都在一个进程中运行，牵一发而动全身，这种“巨石”“烟囱”“All in one”式的单体应用臃肿膨胀、无法复用、风险极高，如果按领域划分成不同的微服务后，需要考虑如何通过一个统一的主域名进行访问，然后根据子路径标识划分对应后面的微服务，将请求路由正确转发至相应的服务器，这样路由策略也可能会随着业务的变化，需要实时调整。在这个过程中，我们要求不能重启服务进程，以免影响或中断当前用户的任何正常请求。
4. 数据缓存
Jack：Justin，通过监控发现我们的数据库压力很大，存在很大瓶颈和风险，是不是需要考虑下读写分离、分库分表，或者将一些热数据进行本地缓存，或者将前置网关进行分布式缓存或队列处理？在这个过程中，还需要重点考虑缓存穿透、缓存击穿、缓存雪崩、缓存实时性、有效性、一致性等问题。
5. 灰度发布
Jack：Justin，我们的 App 刚上了一个新功能“种草连连看”（有相同购买需求的人集结再团购），需要只放 5% 的用户流量请求过来，其他 95% 的用户无法用到此新功能，每天自动放 5% 的流量，连续放 10 天到达 50%，然后再一次性全部放开给所有用户。在此期间，我们也可以对新功能加以验证，尽早获取用户意见，完善产品功能，提升产品质量，并对性能和稳定性加以观测优化，提前发现问题、解决问题，尽可能缩小影响范围，最终使我们的升级过程顺利平滑过渡。后期还需要考虑，如何根据各种请求的变量参数等条件，进行更个性化的灰度发布（金丝雀）策略，比如只灰度指定地区的用户，或根据不同的移动设备类型/系统类型进行灰度。
6. 蓝绿发布
Jack：Justin，我们的线上“惠多多”版本是 V1.1.1 服务，新版本 V1.1.2 部署后，假如我们将所有用户一次性全切到新版本上，是否可行？如果发现问题，是否可以第一时间切回到原来的旧版本？
7. 滚动发布
Jack：Justin，现在线上有 5 台 Web 服务器，发布新版本时，是否结合我们的 CI/CD 体系，实现自动滚动发布，即自动下线 1 台，更新 1 台，验证 1 台，上线 1 台……依次将 5 台机器按批次全部自动化发布，或者我们全面应用虚拟化、容器化，通过 Kubernetes 的管理技术来解决滚动发布？
8. 信息转换
Jack：Justin，现在用户发布的帖子中，有时会携带着很多敏感信息，比如有可能是身份证号、手机号、银行账号等敏感非法关键字，这个我们是否可以在不改动任何后端业务服务的前提下，实现快速脱敏处理？即通过规则对敏感数据进行变形，在用户请求或响应内容给用户时，直接将这些关键信息的部分内容用***符号代替，以避免用户信息非法传播和泄露，保护用户数据的安全。
9. 请求重写
Jack：喂，Justin 在吗？现在有紧急事务，我们凌晨自动发给所有用户的重要邮件中超链接有错误，在不调整后端业务服务的前提下，需要快速将这个错误链接地址映射到正确的后端服务上，这马上就要天亮了……
10. 服务编排
Jack：Justin 何时出差回来，刚才前端人员反馈，他们根据一个订单 ID，需要调用请求N次才能拿到商品信息、用户信息、用户评价信息，效率太低，影响用户体验，他是否可以只发 1 个请求就拿到这 3 条信息的 JSON 聚合体或根据条件进行流程化调用？如果可以，最好能有个管理后台，可以以可视化的方式自由编排所需 API 功能，岂不妙哉？
11. 服务预热
Jack：Justin，为什么我们每次凌晨升级上线后，第二天早上我们的用户反馈有些慢呢？尤其是一些特别重要的功能和流程，这严重影响了用户体验，这个问题需要优化下或有什么解决方案，让其可以在发布升级上线后，自动调用接口触发预热机制，热数据提前载入缓存？实例提前编译/初始化？长链接/池可以提前建立？让系统提前进入最佳运行状态?
12. 限流限频
Jack：Justin，最近有两个问题我们亟待解决。第 1 个问题是，最近我们发现开放平台服务的某个 URL 接口被合作伙伴调用得太多了，需要针对这个特定的 URL 地址和合作伙伴 ID 进行调用频率的限制，比如限制每秒只能调用100 QPS，每天只能调用 1 万次。不然，会将我们的开放平台服务给拖垮，进而影响内部重要服务。你考虑一下采用哪种限流算法比较合适，令牌、漏斗？采用单机还是分布式限流？
还有双 11 即将来临，可能会出现流量大增，如果没有一定的过载保护策略机制，我们的服务也将面临重大考验。可以考虑当我们的 CPU 或内存资源达到 80% 指标，连续超负荷时、服务故障时、网络延迟高等状态不健康或超过阈值时，自动保护上游后端服务，触发限流限频或熔断机制，并即时报警，避免整个服务链条发生雪崩。
第 2 个问题是，某些热帖中带了较大的附件，被大量用户集中下载，我们的运维同学经常会收到带宽报警，此时需要一定的方案策略以及规则，可以对每个用户的下载速度进行限制，比如每秒下载不能超过 800KB/s。总而言之，我们需要做好综合流量评估，提前进行系统测试和演练，制定好应急预案和计划。
13. 服务降级
Jack：Justin，最近接到用户反馈，用户页面上的内容有时无法正确加载出现白页，可能是某些服务接口响应过慢或出现错误导致。如果出现这样的现象，我们在记录错误的同时，可以考虑返回一些提前准备好的数据或友好信息，将之呈现给用户，而不是返回错误信息或无任何内容，不然这会给用户带来较差的体验，认为系统不稳定，造成用户黏度、信任度下降，进而发生用户流失，影响 what-app 的品牌形象和公众形象。
14. 流量镜像
Jack：Justin，最近商务部反馈说，商家反馈调用我们的系统接口时，偶尔会报错，是何情况？
Justin：Jack，这件事我们已经在追查之中，已在线下环境反复测试，当前还未找到问题所在，线上生产环境与线下所使用的服务版本均是一样的，推断极有可能是线上特定数据和环境等不同变量因素所引起，现在线上的数据量太大，有些还是核心数据，不方便迁移到线下环境，也无法完全模拟线上环境，所以我们准备采用请求流量镜像复制方案，在不影响用户正常前提下，在线上直接排查问题，具体操作流程和实现细节，我们还需要再调研，还请静候佳音。
15. 监控报警
Jack：Justin，如果我们的服务错误状态码在连续 1 分钟内超过 50 次，10 分钟内出入流量超过警戒阈值、CPU/内存等度量指标不正常时，是否可以向我们报警，将消息实时推送到微信、钉钉或短信，以使我们第一时间得知生产环境的最新消息，感知系统的运行状态。另外，我们是否可以通过视图报表看到 API 接口的平均响应时间、API 的正确率、高峰期调用数量、客户端设备类型、客户的地域分布、链路轨迹等信息，这些信息可以为我们后期的线上运维、产品服务、市场策略提供决策支持。
16. 安全防御
Jack：Justin，我们的服务用户反馈无法访问了，访问速度奇慢，好像被人攻击了，刚刚运维同学查到了有来自某地的 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年的图灵奖演讲中将这句话归因于大卫·惠勒。
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
