微服务与网关技术

一. 背景

软件架构，总是在不断的演进中...

把时间退回到二十年之前，当时企业级领域研发主要推崇的还是 C/S 模式，PB、Delphi 这样的开发软件是企业应用开发的主流。随着时间不断的推移，基于浏览器的的 B/S 架构开始渐渐流行了起来。初期，Web 开发 ASP 还占据了不少优势，但 JSP 的预编译模式让性能有了很大的提升，随后基于 JAVA 语言的 J2EE 架构变的越来越流行。

早期软件架构基本都是单体架构，系统之间往往不需要进行交互，这也导致数据孤岛和 ETL 工具的发展。随着企业应用越来多，相互的关系也越来密切。应用之间也迫切需要进行实时交互访问，随后基于 XML 的异构系统集成和数据交互技术开始被很多公司采用，SOA 的概念被提了出来，web service 逐渐流行起来。

互联网时代，很多公司为了适应更加灵活的业务需求，基于 HTTP 协议和 Restful 的架构风格及简洁和结构清晰的 JSON 语言成为企业开发的最佳实践，在 SOA 架构中，企业服务总线技术 ESB 所暴露的集中式架构的劣势让开发者明白基于注册和发现的分布式架构才是解决问题的关键办法。由此，微服务架构逐渐流行起来。

在《微服务设计》中如何界定一个微服务，就是使用松耦合 & 高内聚原则，把因相同因素变化的事情聚集在一起，把因不同因素变化的事情区隔开来。

二. 微服务架构特性

微服务，其实是一种架构风格...

异构

服务不同最适合的技术方案不同，微服务可以帮助我们轻松采用不同的技术，并且理解这些新技术的好处，尝试新技术通常伴随着风险。但对于微服务系统而言，总会存在一些地方让你可以尝试新技术，可以选择一个风险最小的服务采用新技术，并降低风险。

隔离

微服务架构将系统分解为独立运行单元给系统带来更好的隔离性，独立的微服务在发生异常时更容易定位和隔离问题，隔离性也是服务扩展性的基础。

扩展

庞大的单体服务只能作为一个整体进行扩展，即使系统中只有一小部分模块存在性能问题，也需要对整个系统进行扩展。而微服务架构可以根据性能需要对不同的模块进行水平扩展，微服务的弹性也可以很好的处理服务不可用和功能降级问题。

部署简单

在微服务架构中，各个服务的部署是独立的，这样就可以更快的对特定部分的代码进行部署。服务出现问题也更容易快速回滚，同时敏捷的交付和部署带来了更好的业务需求响应体验。

灵活

在微服务架构中，系统会开放很多接口供外部使用。当情况发生改变时，可以使用不同的方式构建应用，而整体化的应用程序只能提供有一个非常粗粒度的接口供外部使用。把单体应用分解成多个微服务，可以达到可复用，可组合的目的。

三. 微服务与网关技术

下图是一个典型的微服务架构，仅供参考

什么是微服务网关

微服务网关是微服务架构中的一个关键的角色，用来保护、增强和控制对于微服务的访问，微服务网关是一个处于应用程序或服务之前的系统，用来管理授权、访问控制和流量限制等，这样微服务就会被微服务网关保护起来，对所有的调用者透明。因此，隐藏在微服务网关后面的业务系统就可以更加专注于业务本身。

微服务网关的分类

常见的微服务网关根据使用特性大致被分成流量网关和业务网关。两种网关分别有不同关注点，下面是总结的两种网关类型特性：

微服务网关的作用

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

四. 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 部署包的方式将网关的服务下沉到容器中实现和执行，从而在时间和空间上做到了系统的弹性和灵活交付。同时中心化的管理能力又给使用网关的具有不同权限的用户可以同时维护各自所属网关组下的网关节点带来了便利。

上图展示的是 SIA-GateWay 去中心化的网关架构。当然除了微服务网关模式， 目前下一代微服务架构 ServiceMesh 技术也是典型的去中心化架构，ServiceMesh 是从 SideCar 边车模式演进而来，是一种通过将服务治理能力下沉到业务节点的方式，通过控制面（control plane）和数据面（data plane）的处理解耦分离实现服务通信更加快速，便捷，智能。

然而目前来看， 从技术上及各大公司的实践中，ServiceMesh 在落地上还存在诸多复杂性及不可控性，这种模式会给运维带来极大的成本，如果贸然使用会给本就复杂的分布式系统带来更多的复杂和难度。所以从目前来讲，GateWay 网关的模式在组织粒度上可以调整，在实现方式上更加简单可控，是目前的微服务架构中比较适合采用的模式。

网关如何保证高可用

作为一个微服务网关系统， 因为所有流量都会经过网关， 网关必须成为一个高可用的中间件服务，网关系统的稳定性及可用性直接决定了所用下游服务的稳定性。因此 SIA-GateWay 在架构设计上主要做了如下几点：

集群化

在生产环境中，所用网关节点至少保证有 2 个节点组成集群同时提供服务，目前 SIA-GateWay 在公司内部主要使用容器化部署， 避免单点故障。

健康检查

在容器环境下，SIA-GateWay 会暴露一个 HTTP 健康检查接口，通过 Kubernetes 的健康检查机制，定期检查 HTTP 访问是否可用， 如果不可用，利用 Kubernetes 的服务编排能力可以做容器的切换；在 Zstack 环境下， 通过后台启动一个 Crontab 作为守护进程检查进程的状态，保证网关的稳定可用和进程重启机制。

备份机制

SIA-GateWay 提供了一种备份网关机制，在 Zstack 上会启动一个备份网关 API-GATEWAY-CORE，所有在容器环境（Kubernetes ）中启动的网关节点，都会将自己的路由信息同步到备份网关中，另外， 利用 Nginx 的高可用性和健康检查机制， 当 Kubernetes 集群出现问题时所有容器流量无法响应时， 会将 Nginx 上的流量自动切换到 API-GATEWAY-CORE 备份节点。API-GATEWAY-CORE 在工作时也会触发预警，提示目前有不可用的 K8s 网关节点。

提供机制而不是策略

Unix 编程哲学里，一个重要的概念就是：“提到机制而不是策略”，通俗的讲“机制”就是接口， “策略”就是具体的实现。SIA-GateWay 提供的组件集成能力正是基于这样的理念。SIA-GateWay 将架构的可扩展性作为重要的对外输出能力，第三方插件机制主要支持 JAVA 语言的 Filter 组件动态加载机制。Filter 机制是 JAVA 工程师最为熟悉的标准组件，所以对于业务方集成自己的业务逻辑提供了极大的便利，第三方业务组件加载到网关平台大体有如下几个步骤：

根据 SIA-GateWay 提供的模板类及注解， 实现动态业务逻辑；

将实现好的动态组件通过 Maven 打包；

在组件管理界面，通过组件上传按钮将组件上传到 Admin- 组件管理器；

组件管理器执行文件存储逻辑；

组件管理器执行组件下发操作，将组件分发到对应网关组；

网关节点通过 ClassLoader 反射解析组件并动态加载到内存；

网关节点通过异步信号量机制响应组件加载状态；

组件管理器同步插件 Plugin 状态。

下图是 SIA-GateWay 组件加载机制的执行逻辑图：

强化可视化和微服务治理能力

俗话说流水的架构， 铁打的监控， 任何架构都需要软件监控。微服务应用本身 RPC 的交互方式和带来了对监控系统了解系统运行状态的难题。SIA-GateWay 对微服务监控主要做了如下方面增强：

全局的集群状态查看和容器状态 DashBoard 统计

实时的路由拓扑和网关拓扑调用关系及状态展示, 实时的路由拓扑图如下：

网关集群拓扑管理界面，包含实时日志，实时 Hystix 监控，JVM 配置等

可视化的组件管理界面：

日志回溯，利用 EKK 架构实现日志归集到日志查看功能

熔断管理的分类及错误 Stacktrace 查看

URL 细粒度的监控统计功能（默认不打开，需要路由绑定监控组件）, 包括 URL 的延迟统计，调用计数等指标。

五. 总结

软件工程没有银弹，软件系统的不确定性和复杂性贯穿软件工程的整个生命周期，微服务架构本质上是通过分层和解耦来降低系统的复杂性，这里组织的沟通方式、企业文化、团队技术学习能力都会对微服务架构的落地产生重要的影响。

对业务系统的核心能力洞察和业务边界的识别是系统微服务架构落地的重要环节；微服务基础设施的技术选型应该考虑到业务系统所使用的技术体系，选择成熟的生态体系和合适的技术方案有利于微服务架构的推广和持续的技术演进；SIA-GATEWAY 作为微服务基础设施充分考虑到了与业务系统的兼容性和相关技术生态的成熟度。

最后在微服务架构下，随着微服务规模的扩大，必然带来分布式事务一致性、网络响应、容错等等问题， 所以微服务治理是微服务架构的难点，保障微服务架构的高可用和高可扩展性需要在基础设施层面增加更多的技术投入和技术保障， 这样才能让业务更好的专注于业务实现，敏捷的开发，持续快速的服务交付。

SIA 相关开源产品链接：

微服务任务调度框架

https://github.com/siaorg/sia-task

微服务路由网关

https://github.com/siaorg/sia-gateway

Rabbitmq 队列服务 PLUS

https://github.com/siaorg/sia-rabbitmq-plus