系列文章：

微服务架构：网关概念与 zuul

微服务网关：Spring Cloud Gateway —— Zuul

微服务网关：Spring Cloud Config- 配置中心

微服务网关方案：Kong & Nacos

一 摘要

基于前面的系列文章，我们对网关概念和相关的解决方案有了一定的理解，接下来我们需要做进一步的思考。

二 几个问题

通常我们在决定架构/技术方案之前，都需要明确几个问题，对于网关也是如此。我们真的需要网关吗？什么时候需要？需要什么功能，有哪些迫切解决的问题？最大的侧重点是什么？功能/性能/扩展/活跃度？....

在明确这些问题之后，面对众多的网关方案，是否足以支持我们做出最后的决定？我们对这些网关方案的理解真的足够深入了吗？在使用之后，可能遇到的问题，是否有足够的评估？是否有后续的扩展/定制化开发方案来支持未来的业务变化/数量级增长？如果不得已需要更换网关方案，那么对现有的整体架构影响有多大，是否可以快速切换而非推倒重来？

三 网关本身

3.1 定位与发展趋势

网关的作用和系统中的位置，在各网关方案中都有描述。简单来说，为微服务提供统一入口是 API 网关最主要的功能。除此之外，网关还可承担认证授权、访问控制、路由、负载均衡、缓存、日志、限流限额、转换、映射、过滤、熔断、注册、服务编排、API 管理、监控、统计分析等非业务性的功能。

随着业务需求和网关自身的发展，服务治理、服务网格（Service Mesh）等也变得越来越重要，尤其是对容器的支持，都已经纳入必须包括的能力之中，更不必说天然在 k8s 体系内的 etcd 了。

3.2 从设计原理到部署实践

通过官方文档，我们能了解到网关的设计思想，核心优势，有些也会在文档中表明未来的开发方向。但了解这些还远远不够。了解架构设计，能够大概知道网关性能的理论上限，但真实的结果与实现紧密相关。尤其是适用场景、核心参数的调优方向，这些都是在实战中无法避开的问题，需要做到心中有数。

接下来在机器上验证，搭建环境，功能测试、压力测试，做一些扩展实践，摸清使用方式，同时也看是否能暴露一些问题。测试时，尽可能按照业务当前和未来的真实使用方式也是非常重要的一点，

3.3 从应用到定制开发

这也可以理解为从输血到造血的过程。在常规业务领域，业务量级有限的条件下，大部分技术方案只是使用就已经足够。但当业务到达一定量级，或者个性化较强的场景时，单纯的使用（包括既有的调优等）就不足以支撑了。而且，“使用”本身就是对外部的强依赖，熟练掌握的上限是达到某框架的理论上线，只有突破这个界限才有后续的无限可能。

四 后续

接下来，将选择几种典型的网关方案做深入研究，会到源码级别，并且尝试明确典型场景下的能力上限，这些都会在后续的工作中起到重要的作用。