一篇文章读懂微服务与网关技术( 二 ) _小知识

微服务网关作为连接服务的消费方和服务提供方的中间件系统，将各自的业务系统的演进和发展做了天然的隔离，使业务系统更加专注于业务服务本身，同时微服务网关还可以为服务提供和沉淀更多附加功能，下面是总结的微服务网关主要作用：

文章插图

四. SIA-GateWay
SIA-GATEWAY 是基于 SpringCloud 微服务生态体系下开发的一个分布式微服务网关系统。具备简单易用、可视化、高可扩展、高可用性等特征，提供云原生、完整及成熟的接入服务解决方案。
关键特性
简单易用, 支持基于 Docker 容器的快速部署及交付。
兼容性良好, 兼容 SpringBoot 微服务及传统 HTTP-URL 的负载均衡及路由服务。

高可扩展性, 支持基于 Java 语言的第三方插件扩展特性及动态加载机制。
支持多租户，多用户角色下的网关拆分管理。
可视化管理，提供实时路由拓扑、网关集群拓扑展示功能。
服务治理，支持网关集群 Dashboard、实时日志、历史日志查询、熔断管理、预警管理等功能。
多注册中心支持，提供分布式网关集群下对多注册中心集群的切换管理功能。
动态路由组件绑定机制，提供包括 URL 统计、日志、灰度发布、限流、安全等公共服务组件。

下图是 SIA-GATEWAY 的整体架构图，架构由 CORE 和 Admin Cluster 组成，其中：

CORE 承载网关 HTTP 请求的主要服务节点， CORE 节点可以根据所属的网关组信息自动注册到 Admin 管理端。
Admin 是网关集群的管理后台，由 Admin、Service、Stream、Monitor 等服务组成。

文章插图

下图是网关的整体部署架构图：

文章插图

面向业务系统的微服务网关
微服务网关系统是一个处于应用程序或服务（提供 REST API 接口服务）之前的中间件系统，所以 SIA-GateWay 在建设初期做技术选型时就充分考虑到所使用的技术方案应该兼容后端代理业务系统所使用的技术栈和技术体系，所以我们使用了 Netflix 的 ZUUL 作为我们网关系统技术栈，单纯的脱离使用场景谈某一种网关功能如何强大的做法，后续都会给业务方的使用带来更多的麻烦。更明确的说如果目前大部分业务系统采用的技术栈是 JAVA 系统，那么不建议使用 Nginx, Kong 或者 OpenResty 等网关系统，这里主要是处于软件工程性方面考虑。举个例子，业务方需要将一个公共组件以 Plugin 机制集成到微服务网关，如果使用 Lua 脚本文件或者其他脚本语言，那么引入一种新的语言技术栈所带来的复杂度会给业务系统带来更多的不确定性，系统后期维护成本和运维的难度都会呈指数级的提升。
基于组件模块化的设计
微服务网关的一个很重要的作用就是可以将微服务的 API 聚合后提供一个统一的 EntryPoint 作为业务使用方的一个统一入口以及屏蔽和隐藏业务内部逻辑。下面是 SIA-GateWay 提供的公共组件类型及分类。
目前 SIA-GateWay 通过组件管理的机制实现了 5 个大类 8 个子类的公共服务组件供业务方使用，其中提供的路由组件绑定机制可以让业务方灵活的决定是否要在运行时执行相关组件逻辑。

文章插图

去中心化的网关架构设计
微服务架构的一个重要的特性就是去中心化的架构设计思路， SIA-GateWay 在软件设计层面上增加了一个“网关组”的抽象概念，一个网关组对应就是一个独立的业务领域。网关组的概念也契合了微服务架构中的一些理念：业务系统依赖微服务网关提供明确清晰的服务边界；业务系统通过微服务网关对外暴露业务的标准服务接口。
从实现层面， SIA-GateWay 充分利用并结合了容器自动化的部署技术，在解决最后一公里的问题上，将网关以云端容器资源的方式交付给不同业务方，通过共享网关 SDK 部署包的方式将网关的服务下沉到容器中实现和执行，从而在时间和空间上做到了系统的弹性和灵活交付。同时中心化的管理能力又给使用网关的具有不同权限的用户可以同时维护各自所属网关组下的网关节点带来了便利。