浅谈微服务与接口网关

互联网技术日新月异,项目架构不断升级优化。随着企业微服务的兴起和第三方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参数。
……
GoKu刚开源不久,很多地方有待完善,欢迎大家加入我们的用户讨论群:725853895,给我们提意见,跟我们交流想法。

项目地址:

    原文作者:eoLinker
    原文地址: https://segmentfault.com/a/1190000015015697
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞