.Net微服务架构:API网关

本人建立了个人技术、工作经验的分享×××号,计划后续公众号同步更新分享,比在此更多具体。欢迎有兴趣的同学一起加入相互学习。基于上篇微服务架构分享,今天分享其中一个重要的基础组件“API网关”。

一、引言

  随着互联网的快速发展,当前以步入移动互联、物联网时代。用户访问系统入口也变得多种方式,由原来单一的PC客户端,变化到PC客户端、各种浏览器、手机移动端及智能终端等。同时系统之间大部分都不是单独运行,经常会涉及与其他系统对接、共享数据的需求。所以系统需要升级框架满足日新月异需求变化,支持业务发展,并将框架升级为微服务架构。“API网关”核心组件是架构用于满足此些需求。

  很多互联网平台已基于网关的设计思路,构建自身平台的API网关,国内主要有京东、携程、唯品会等,国外主要有Netflix、Amazon等。

二、业界相关网关框架

  业界为了满足这些需求,已有相关的网关框架。

  1、基于nginx平台实现的网关有:KONG、API Umbrella

  2、自研发的网关有:apigee、Zuul

三、API网关设计

  API网关是微服务架构(Microservices Architecture)标准化服务的模式。API网关定位为应用系统服务接口的网关,区别于网络技术的网关,但是原理则是一样。API网关统一服务入口,可方便实现对平台众多服务接口进行管控,对访问服务的身份认证、防报文重放与防数据篡改、功能调用的业务鉴权、响应数据的脱敏、流量与并发控制,甚至基于API调用的计量或者计费等等。组件设计如下:

                                                    图1- API网关功能结构示意图

  多种客户端程序,例如:移动APP、PC端和智能终端设备等。客户端程序通过互联网或者专网访问API网关,由API网关统一接收请求后,通过一系列模块定位具体处理的微服务机,并将其转发至目标服务处理,网关与微服务之间通信是内部局域网。API网关统一规范平台对外的服务,同时充当了平台的PaaS层。如上图所示,API网关功能结构基于管道模型和支持可插拔式的设计开发,提供统一基于http协议的WebAPI访问接口,内部每个模块各自实现功能,包括:黑白名单、日志、协议适配、身份认证、计流限流及路由。并且依赖“访问认证中心、服务发布管理中心”分别实现API网关访问权限控制和定位目标微服务。各模块功能说明如下:

  1、黑白名单:实现通过IP地址控制禁止访问网关功能,此功能是应用层面控制实现,再往前也可以通过网络传输方面进行控制访问。

  2、日志:实现访问日志的记录,可用于分析访问、处理性能指标,同时将分析结果支持其他模块功能应用。

  3、协议适配:实现通信协议校验、适配转换的功能。

  4、身份认证:负责网关访问身份认证验证,此模块与“访问认证中心”通信,实际认证业务逻辑交移“访问认证中心”处理。

  5、计流限流:实现微服务访问流量计算,基于流量计算分析进行限流,可以定义多种限流规则。

  6、路由:路由是API网关很核心的模块功能,此模块实现根据请求,锁定目标微服务并将请求进行转发。此模块需要与“服务发布管理中心”通信。“服务发布管理中心”实现微服务发布注册管理功能,与其通信获得目标微服务信息。

四、API网关部署

  API网关是一个公共基础组件,无状态,可支持多套分布式部署。如下图所示:

                                                     图2- API网关部署示意图

五、API网关实现技术

  1、技术:框架整体基于.NET平台构建,所以API网关也暂定基于.NET4.6平台和ASP.NET WebAPI2.0框架实现。具体软件架构就用上一篇所介绍的。

  2、性能:部署于IIS7.0,1000个并发查询请求,平均响应90ms。

  可能在IIS7.0和.Net4.6平台,在大并发性能处理上会更不上,后续将考虑基于.net core进行升级开发,并部署于Linux平台。

  API网关主要原理是相通,不同平台结合本身平台整体框架设计,可选用不同的技术实现,目前有些基于Spring MVC、node.js、Erlang技术进行研发。

六、结语

  以上是对API网关概要进行设计,还有其他方面的内容此篇文章未讨论,例如:安全性、高并发、扩展性等特性设计,同时作为平台其中一个组件,也涉及与其他组件一并协同运行。此块内容会后续分享。

作者:刘蔡涛

公众号:【51dotnet】

原文地址:http://blog.51cto.com/11415636/2175693

时间: 2024-10-29 04:42:13

.Net微服务架构:API网关的相关文章

买单侠微服务的API网关演化之路

伴随着买单侠业务的快速发展,能够支持独立开发.独立部署.独立扩展的微服务在秦苍得到了广泛应用和蓬勃发展,短短3年左右时间,已经发展到了300+个微服务,并且还在快速增长中. 研发逐渐意识到伴随着微服务规模化的增长,必需要重视微服务的基础设施建设(API网关.服务注册中心.调用链跟踪等)才能保持开发效率和产品的质量. API网关作为访问微服务的大门, 是访问后台服务的入口,作为最常用的基础服务之一,其重要性不言而喻.在买单侠微服务的发展道路上,经过了以下摸索发展阶段,希望能给规模化应用微服务的攻城

.net core 微服务之Api网关(Api Gateway)

原文:.net core 微服务之Api网关(Api Gateway) 微服务网关目录 1. 微服务引子 2.使用Nginx作为api网关 3.自创api网关(重复轮子) 3.1.构建初始化 3.2.构建中间件 4.结语 引用链接 1. 微服务引子 首先恭喜你,进入微服务的开发世界.微服务属于架构演进中的一种阶段,其特点是根据业务模块水平划分服务种类,每个服务可以独立部署并互相隔离,并对外提供轻量的Api调用,服务具有高可用特性. 微服务应遵循的设计原则: 单一职责原则: 每个微服务只需要实现自

微服务之API网关 kong 使用场景之路由功能

API网关,在介绍spring cloud的时候我们也曾提到过zuul,并使用zuul做了一个简单的实验证明zuul是可以实现网关的路由功能的,在这篇文章中,我们会同样使用类似简单的例子来验证kong在此种场景下的使用. spring cloud之zuul的类似实现 spring cloud的zuul的类似功能和实现,可参看下文: spring cloud之api网关 https://blog.csdn.net/liumiaocn/article/details/53941354 场景说明 项目

Net分布式系统之六:微服务之API网关

本人建立了个人技术.工作经验的分享微信号,计划后续公众号同步更新分享,比在此更多具体.欢迎有兴趣的同学一起加入相互学习.基于上篇微服务架构分享,今天分享其中一个重要的基础组件“API网关”. 一.引言 随着互联网的快速发展,当前以步入移动互联.物联网时代.用户访问系统入口也变得多种方式,由原来单一的PC客户端,变化到PC客户端.各种浏览器.手机移动端及智能终端等.同时系统之间大部分都不是单独运行,经常会涉及与其他系统对接.共享数据的需求.所以系统需要升级框架满足日新月异需求变化,支持业务发展,并

基于spring-cloud的微服务(4)API网关zuul

API网关是微服务架构中的很重要的一个部分,内部有多个不同的服务提供给外部来使用,API网关可以对外做统一的入口,也可以在网关上做协议转换,权限控制和请求统计和限流等其他的工作 spring-cloud封装了Netflix提供的开源的API网关实现zuul,我们可以很方便地启动一个zuul网关的实例,并支持向eureka进行注册,并对在eureka上已经注册的服务进行代理 使用IDEA的spring initializer来创建一个zuul项目 填写相关的group类型等信息,选择使用gradl

基于.NET CORE微服务框架 -Api网关服务管理

1.前言 经过10多天的努力,surging 网关已经有了大致的雏形,后面还会持续更新完善,请大家持续关注研发的动态 最近也更新了surging新的版本 更新内容: 1. 扩展Zookeeper封装2. 增加服务元数据3. 增加API网关 开源地址:https://github.com/dotnetcore/surging 2.软件环境 IDE:Visual Studio 2017 15.3 Preview ,vscode 框架:.NET core 2.0 依赖程序:Zookeepe.Rabbi

SOA和微服务架构的区别?

知乎用户 289 人赞同了该回答 谢多人邀请,其实前面几位的回答已经差不多了,在这里仅谈下自己的简单总结. 微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用.这些小应用之间通过服务完成交互和集成.每个小应用从前端web ui,到控制层,逻辑层,数据库访问,数据库都完全是独立的一套.在这里我们不用组件而用小应用这个词更加合适,每个小应用除了完成自身本身的业务功能外,重点就是还需要消费外部其它应用暴露的服务,同时自身

从 0 开始的微服务架构:(五)代码给你,看如何用Docker支撑微服务

很好的一篇文章,全面.系统. 虽然已经红了很久,但是"微服务架构"正变得越来越重要,也将继续火下去.各个公司与技术人员都在分享微服务架构的相关知识与实践经验,但我们发现,目前网上的这些相关文章中,要么上来就是很有借鉴意义的干货,要么就是以高端的专业术语来讲述何为微服务架构.就是没有一个做到成熟地将技术传播出来,同时完美地照顾"初入微服务领域人员",从 0 开始,采用通俗易懂的语言去讲解微服务架构的系列.所以,我们邀请青柳云的苏槐与 InfoQ 一起共建微服务架构专题

SOA和微服务架构的区别

微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用.这些小应用之间通过服务完成交互和集成.每个小应用从前端web ui,到控制层,逻辑层,数据库访问,数据库都完全是独立的一套.在这里我们不用组件而用小应用这个词更加合适,每个小应用除了完成自身本身的业务功能外,重点就是还需要消费外部其它应用暴露的服务,同时自身也将自身的能力朝外部发布为服务. 如果一句话来谈SOA和微服务的区别,即微服务不再强调传统SOA架构里面比较

微服务架构的设计原则

微服务架构的设计原则如下:¶ 高内聚.低耦合. 无缝的 API 集成. 为每一项服务分配唯一的资源标识. 实时流量管理. 最小化数据表,以优化加载. 通过内/外部 API,执行持续监控. 为每个微服务隔离数据的存储.这对于限制数据的访问和避免“服务的耦合”是非常有用的. 例如:基于用户的分类数据,我们可以实施命令查询的责任分离(Command Query Responsibility Segregation,CQRS). 去中心化.设计微服务架构的首要原则是:将单体结构分解成独立的多个实体,而这