谈谈关于API网关和企业技术架构的改变-优快云博客

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

1.单体架构

计算机发展初期，又或者很多初创公司为了快速开发的时候，会将应用程序的业务处理与数据处理都放在一起，整体打包成应用程序，这就是单体架构。其优点在于足够简单、易于开发，而缺点也非常明显，在于耦合度非常高，不易维护。

2.MVC架构

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

优点：层次分明，结构简单，可分层测试。

缺点：扩展性不够强，随着模块的增加，应用会愈发臃肿，维护难度相应加大。

3.多应用架构

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

优点：资源分散，方便维护。

缺点：分割后的应用各自独立，共同业务的代码无法复用。

4.分布式架构

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

优点：应用解耦，不同团队负责不同模块，服务间可通信。

缺点：架构开始复杂。

5.微服务架构

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

优点：服务独立、易于开发测试、易于维护。

缺点：要进行微服务治理，包括服务注册发现、API监控、认证鉴权、负载均衡等。

随着云、容器、DevOps等技术/理论的发展，微服务构架已逐渐成为主流。要实现微服务，网关是必不可少的一环，网关承载着流量控制、监控告警、鉴权、参数校验、路由转发、缓存、负载均衡等工作。

目前在Github上面开源的API网关其实有不少，相信大部分的关注者都曾经去了解使用过，下面介绍的是一些从网上搜来的资料，类似Kong、Tyk、Orange的测评网上有非常多，也是非常优秀的接口网关产品，大家不妨多加了解。

Kong：Kong是一个可扩展的开放源码API Layer(也称为API网关或API中间件)。Kong 在任何RESTful API的前面运行，通过插件扩展，它提供了超越核心平台的额外功能和服务。

Tyk：Tyk是一个开放源码的API网关，它是快速、可扩展和现代的。Tyk提供了一个API管理平台，其中包括API网关、API分析、开发人员门户和API管理面板。Try 是一个基于Go实现的网关服务。

Orange：和Kong类似也是基于OpenResty的一个API网关程序。

Netflix zuul：Zuul是一种提供动态路由、监视、弹性、安全性等功能的边缘服务。Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。

apiaxle: Nodejs 实现的一个 API 网关。

api-umbrella: Ruby 实现的一个 API 网关。

而eoLinker从年前就一直在制作的GoKu-API-Gateway，其实就是属于Go语言开发的接口网关。我下面大概介绍下关于GoKu（悟空）的内容和特性。

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

在开源大后期以及发布企业版之后，整体策略和功能会比现在公布出来的LITE版更加丰富和强大，而在目前悟空还是开源初期，许多地方亟待改善，如果您有好的想法以及建议，欢迎加入悟空的讨论群：725853895，只要您有好的点，我们都非常乐意倾听与做出改变。

转载于:https://my.oschina.net/ProLinker/blog/1816722