一. 导读
微服务架构 (Microservice Architecture) 成为近几年最为流行的技术架构术语之一,从传统IT企业到互联网公司,纷纷围绕企业的业务支撑系统进行着微服务化的改造。
从业务的角度,企业为了赢得在市场中的竞争,相应的需要后台系统能够适应前端快速的需求变更以及敏捷的服务交付,其次公司从经营效益的角度对IT部门提出了降本增效的诉求,另外还存在业务融合及业务重复建设和冲突等等问题,软件作为提升业务工作效率的工具在所有这些极端情况下反而成为业务发展的羁绊,工程师将大部分精力投入到了问题排查,沟通低效,软件维护的成本大幅度增加,而互联网公司最求的“唯快不破”的目标也越来越远,传统的系统架构方式的弊端日益凸显,严重制约了业务的快速创新和交付。
从技术的角度,单体架构在业务系统建设初期为了实现快速交互,简单的堆积代码成为服务快速交付用户的一大优势。然而随着系统复杂度的增加,大量模块堆积,局部模块的代码耦合导致系统牵一发动全局;更大的痛点是模块之前的相互影响,故障难以隔离,一个局部模块的问题可能导致整个系统的崩溃。SOA分布式化的架构演进,将单体拆分为可复用的服务提供系统调用,一定程度上提高了系统的开发效率和可运维性,然而依然存在服务粒度过大,服务内部界限模糊,服务之间耦合性高,服务治理机制欠缺,架构中心化及ESB总线性能瓶颈等等问题。
正是因为综上所述的因素成为了微服务架构兴起的时代大背景。从Heroku 于 2012 年提出微服务12因子到业界微服务楷模Netflix基于AWS云平台落地的PASS微服务架构再到Pivotal打造的SpingCloud微服务生态, 可以说微服务已经成为目前企业软件发展的主流架构模式。
二.SpringCloud微服务网关的演进
在微服务架构广泛使用的大背景下,众所周知,对于JAVA开发人员来说,SpringCloud 已经成为JVM虚拟机平台上对微服务架构在技术栈层面上支持最为全面同时也是最为成熟的技术框架和平台。从SpringCloud1.0版本开始对Netflix的OSS框架友好的集成,到目前的SpringCloud2.0版本基于Reactor响应式编程模型,SpringCloud技术生态逐渐实现了微服务API网关、服务发现注册、配置中心、链路追踪、负载均衡器、熔断、消息中间件等微服务基础设施的核心模块开发和技术演进。而在众多技术组件和模块中尤以API微服务网关最为关键和复杂,它可以结合Eureka、Ribbon、Hystrix等等组件实现云平台上的动态路由、弹性、安全、监控等等公共业务单元的边缘服务。
SpringCloud1.0版本实现了对Netflix-ZUUL 的整合和增强,Zuul1.0本质上是基于SpringMVC框架开发的一个Web Servlet应用,ZUUL1的核心模块主要是一系列Filter过滤器,使用阻塞式的IO,通过线程池技术实现请求的并发处理,每个请求都对应独立的线程处理后端的业务逻辑。Zuul1的开源时间很早,Netflix等大公司都已经在生产环境中使用,自身经受了实践考验,是生产级的API网关产品。下图是ZUUL的架构图:
SpringCloud2.0版本实现了社区生态下的Spring Cloud Gateway(简称SCG)微服务网关。Spring Cloud Gateway 是Spring Cloud的一个全新的API网关项目,目的是替换掉ZUUL。SCG同样可以与Eureka,Ribbon,Hystrix等组件配合使用, SCG基于Spring5的Reactor和Springboot2构建,使用Netty作为底层通讯框架,支持异步非阻塞编程模型及WebFlux响应式编程框架,解决了ZUUL框架的IO阻塞问题和线程收敛问题,高并发场景下系统资源占用还有性能方面都有了极大的提升。下图是SCG的架构图: