随着微服务架构不断兴起，以前的一个大的单体应用根据不同的业务域拆分为不同的微服务系统进行维护和部署。因此各个微服务对外提供的服务接口API会呈现出爆发式的增长，如何对于各个应用服务的接口进行统一管理成为了不可回避的问题。
外部的请求想要访问内部的应用服务必须经过一系列的校验、鉴权等操作，如果吧这些操作都放到每个服务中去做明显不合理。不仅造成重复代码同时各个服务也增加了和自身业务逻辑无关的模块变得更重了，一旦增加新的校验规则，每个服务都需要进行修改，明显这不是好的设计。
因此，我们需要将这些服务的通用操作进行抽象，所有的关于请求的前置处理，都抽象到一个专门完成此业务的中间中去实现。而这个中间件就是我们所说的网关。
API网关作为外部请求与内部微服务的沟通桥梁，承担了流量入口的重要职责，实现了对外部请求的的协议转换、请求鉴权、参数校验、流量控制、数据统计以及API上线与下线等通用能力的沉淀。
实际上对于API网关来说，已经有不少的开源的解决方案，比如Zuul、Kong等开源网关实现。但是这些开源网关解决方案并不完备，比如不能没有强大的监控能力，不能很好的支持Open API平台，同时在扩展方面由于开源的一些限制，扩展方面不能与业务更好的匹配。
而如果自主进行网关的迭代开发，这样维护性更强，发现问题可以及时修改，不必要等待开源框架进行修复，同时可以通过插件化的设计更加契合自身业务。另外我们可以借鉴各个开源解决方案的优秀设计，摒弃一些不好的设计实现，为实现更加适合业务的网关奠定设计架构基础。
基于以上的几点的分析，我们需要自研一套高扩展、高性能、高可用的API网关解决方案满足自身业务。
价值分析1、提升API网关自主开发以及扩展能力，在使用过程中有什么问题以及建议可以直接提给网关维护团队，问题解决效率更高，业务开发同学可以专注于业务实现；
2、降低前后端沟通成本，通过后端服务API的统一管控，可以将需要联调的测试接口发布到网关中，包括接口url、请求参数、响应信息等，万前端同学可以方便查看，提升前后端接口联调测试的效率；
总结本文作为自研高性能网关系列的第一篇，主要给同学们阐述了网关在分布式系统中的重要作用以及核心功能，同时分析了进行网关自研的目的以及价值，后续的文章将从需求分析、架构设计以及落地实现等方面继续为大家拆解自研网关。