系列文章:
微服务网关:Spring Cloud Gateway —— Zuul
微服务网关:Spring Cloud Config- 配置中心
一 摘要
基于前面的系列文章,我们对网关概念和相关的解决方案有了一定的理解,接下来我们需要做进一步的思考。
二 几个问题
通常我们在决定架构/技术方案之前,都需要明确几个问题,对于网关也是如此。我们真的需要网关吗?什么时候需要?需要什么功能,有哪些迫切解决的问题?最大的侧重点是什么?功能/性能/扩展/活跃度?....
在明确这些问题之后,面对众多的网关方案,是否足以支持我们做出最后的决定?我们对这些网关方案的理解真的足够深入了吗?在使用之后,可能遇到的问题,是否有足够的评估?是否有后续的扩展/定制化开发方案来支持未来的业务变化/数量级增长?如果不得已需要更换网关方案,那么对现有的整体架构影响有多大,是否可以快速切换而非推倒重来?
三 网关本身
3.1 定位与发展趋势
网关的作用和系统中的位置,在各网关方案中都有描述。简单来说,为微服务提供统一入口是API网关最主要的功能。除此之外,网关还可承担认证授权、访问控制、路由、负载均衡、缓存、日志、限流限额、转换、映射、过滤、熔断、注册、服务编排、API管理、监控、统计分析等非业务性的功能。
随着业务需求和网关自身的发展,服务治理、服务网格(Service Mesh)等也变得越来越重要,尤其是对容器的支持,都已经纳入必须包括的能力之中,更不必说天然在k8s体系内的etcd了。
3.2 从设计原理到部署实践
通过官方文档,我们能了解到网关的设计思想,核心优势,有些也会在文档中表明未来的开发方向。但了解这些还远远不够。了解架构设计,能够大概知道网关性能的理论上限,但真实的结果与实现紧密相关。尤其是适用场景、核心参数的调优方向,这些都是在实战中无法避开的问题,需要做到心中有数。
接下来在机器上验证,搭建环境,功能测试、压力测试,做一些扩展实践,摸清使用方式,同时也看是否能暴露一些问题。测试时,尽可能按照业务当前和未来的真实使用方式也是非常重要的一点,
3.3 从应用到定制开发
这也可以理解为从输血到造血的过程。在常规业务领域,业务量级有限的条件下,大部分技术方案只是使用就已经足够。但当业务到达一定量级,或者个性化较强的场景时,单纯的使用(包括既有的调优等)就不足以支撑了。而且,“使用”本身就是对外部的强依赖,熟练掌握的上限是达到某框架的理论上线,只有突破这个界限才有后续的无限可能。
四 后续
接下来,将选择几种典型的网关方案做深入研究,会到源码级别,并且尝试明确典型场景下的能力上限,这些都会在后续的工作中起到重要的作用。