浅谈微服务与接口网关

互联网技术日新月异，项目架构不断升级优化。随着企业微服务的兴起和第三方API的发展，API网关这一作为微服务核心组件的产品也逐渐被越来越多的人认识。微服务如何演变而来？网关在微服务中如何发挥作用？本文将以此作为话题，聊聊API网关如何影响企业技术架构的演变。

一、互联网架构的演变

1. 单体架构

计算机发展初期，又或者很多初创公司为了快速开发的时候，会将应用程序的业务处理与数据处理都放在一起，整体打包成应用程序，这就是单体架构。

优点：足够简单、易于开发。
缺点：耦合度非常高，不易维护。

2. MVC架构

Web应用的兴起，让界面部分在浏览器展示，数据处理在服务器进行，两个地方使用的语言也不同，前后端分离应运而生。项目里也可以分为表现层、业务层、持久层、数据库等，演变为我们常说的MVC架构。

优点：层次分明，结构简单，可分层测试。
缺点：扩展性不够强，随着模块的增加，应用会愈发臃肿，维护难度相应加大。

3. 多应用架构

随着业务量与用户规模增大，一台主机上提供的资源是有限的，于是渐渐把应用和数据分离开，把原来的一个应用按照业务特点拆分成多个应用，它们之间各自独立，不互相调用。像是一个电商系统通常会分为用户系统、商品系统、订单系统等。

优点：资源分散，方便维护。
缺点：分割后的应用各自独立，共同业务的代码无法复用。

4. 分布式架构

多应用存在代码难以复用的问题，此时可以考虑将公共服务提取出来，独立部署，这样一来，模块也更容易拓展与维护。系统从多个应用变成一个个模块化的服务组件，这就是分布式架构。

优点：应用解耦，不同团队负责不同模块，服务间可通信。
缺点：架构开始复杂。

5. 微服务架构

当一个服务组件的粒度细化到API级别，通过一个或一组API提供完整功能，就演变成现在的微服务架构。微服务之间相互独立，使用者无需配置环境，直接调用API即可完成开发。

优点：服务独立、易于开发测试、易于维护。
缺点：要进行微服务治理，包括服务注册发现、API监控、认证鉴权、负载均衡等。

二、微服务的实现

要实现微服务，网关是必不可少的一环，网关承载着流量控制、监控告警、鉴权、参数校验、路由转发、缓存、负载均衡等工作。

网关是一个要求高并发、高可用、高性能的项目，在没有开源项目的支撑下，自己开发网关是一个非常大的工作量。

秉承着开源精神，eoLinker推出国内首款企业级开源的Go语言网关—— GoKu Gateway。eoLinker拥有全面的API管理产品，Goku Gateway作为eoLinker旗下的开源API网关，能够帮助企业整理内部API资源，进行API服务治理与维护，实现诸如鉴权、请求过滤、流控等需求。

一个GoKu可以新建多个网关，每个网关下包含策略组、API与后端服务，其中策略组包含了网关大多数的处理操作，包括鉴权、限流、IP黑白名单等。

GoKu特性：

部署简单：基于golang，仅需一个go环境即可运行使用。
多种鉴权方式：支持Basic认证、API Key认证、IP认证等方式。
权限管理：针对不同策略组设置流控控制策略，包括QPS、访问总次数、访问IP、访问时间段等。
IP黑白名单：支持全局IP白名单、也可自定义某个接口的IP白名单。
数据整形：支持参数的转换与绑定，支持formdata、raw、json、file参数。
……

欢迎大家加入我们的用户讨论群：725853895，给我们提意见，跟我们交流想法。

项目地址：

• github：https://github.com/eolinker/goku-api-gateway