浅谈微服务与接口网关

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

1、互联网架构的演变

1. 单体架构

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

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

2. MVC架构

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

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

3. 多应用架构

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

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

4. 分布式架构

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

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

5. 微服务架构

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

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

2、微服务的实现

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

网关是一个要求高并发、高可用、高性能的项目，在没有开源项目的支撑下，本身开发网关是一个很是大的工做量。

秉承着开源精神，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参数。
……
GoKu刚开源不久，不少地方有待完善，欢迎你们加入咱们的用户讨论群：725853895，给咱们提意见，跟咱们交流想法。

项目地址：

• github：https://github.com/eolinker/G...
• gitee: https://gitee.com/eoLinker-AP...