南京营销网站开发制作报价,wordpress插件中文版,常州市工程建设交易网,国内三大oa系统前言 又是很久没写博客了#xff0c;最近一段时间换了新工作#xff0c;比较忙#xff0c;所以没有抽出来太多的时间写给关注我的粉丝写一些干货了#xff0c;就有人问我怎么最近没有更新博客了#xff0c;在这里给大家抱歉。 那么#xff0c;在本篇文章中#xff0c;我… 前言 又是很久没写博客了最近一段时间换了新工作比较忙所以没有抽出来太多的时间写给关注我的粉丝写一些干货了就有人问我怎么最近没有更新博客了在这里给大家抱歉。 那么在本篇文章中我们就一起来探讨一下 API 网关在整个微服务分布式架构中的一个作用。 背景 我们知道在微服务架构风格中一个大应用被拆分成为了多个小的服务系统提供出来这些小的系统他们可以自成体系也就是说这些小系统可以拥有自己的数据库框架甚至语言等这些小系统通常以提供 Rest Api 风格的接口来被 H5, Android, IOS 以及第三方应用程序调用。 但是在UI上进行展示的时候我们通常需要在一个界面上展示很多数据这些数据可能来自于不同的微服务中举个例子。 在一个电商系统中查看一个商品详情页这个商品详情页包含商品的标题价格库存评论等这些数据对于后端来说可能是位于不同的微服务系统之中可能我后台的系统是这样来拆分我的服务的 产品服务 - 负责提供商品的标题描述规格等。 价格服务 - 负责对产品进行定价价格策略计算促销价等。 库存服务 - 负责产品库存。 评价服务 - 负责用户对商品的评论回复等。 现在商品详情页需要从这些微服务中拉取相应的信息问题来了 问题 由于我们使用的服务系统架构所以没办法像传统单体应用一样依靠数据库的 join 查询来得到最终结果那么如何才能访问各个服务呢 按照微服务设计的指导原则我们的微服务可能存在下面的问题 服务使用了多种协议因为不同的协议有不同的应场景用比如可能同时使用 HTTP, AMQP, gRPC 等。 服务的划分可能随着时间而变化。 服务的实例或者Host端口可能会动态的变化。 那么对于前端的UI需求也可能会有以下几种 粗粒度的API而微服务通常提供的细粒度的API对于UI来说如果要调用细粒度的api可能需要调用很多次这是个不小的问题。 不同的客户端设备可能需要不同的数据。Web,H5,APP 不同设备的网络性能对于多个api来说这个访问需要转移的服务端会快得多 以上就是我们构建微服务的过程中可能会遇到的问题。那么如何解决呢 这种情况下我们就需要一个今天要讲的这个东西 API 网关API Gataway。 API 网关 下面是百度上针对于 API 网关的介绍 API网关是一个服务器是系统的唯一入口。从面向对象设计的角度看它与外观模式类似。API网关封装了系统内部架构为每个客户端提供一个定制的API。它可能还具有其它职责如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。 API网关方式的核心要点是所有的客户端和消费端都通过统一的网关接入微服务在网关层处理所有的非业务功能。通常网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。 Chris Richardson 在他的博客中把 API 网关划分为以下两种 单节点 API 网关 Backends for frontends 网关 单节点网关 单节点的 API网关为每个客户端提供不同的API而不是提供一种万能风格的API。 这个网关和微软在 eShop 项目中推荐的网关是一致的。 更多详细信息我会在下文进行说明。 Backends for frontends 网关 这种模式是针对不同的客户端来实现一个不同的API网关。 落地方案 我一直在寻思一种最佳的 API 网关的落地方案以上两种 API 网关有什么问题呢 通常情况下 API 网关要做很多工作它作为一个系统的后端总入口承载着所有服务的组合路由转换等工作除此之外我们一般也会把安全限流缓存日志监控重试熔断等放到 API 网关来做那么可以试想在高并发的情况下这里可能会出现一个性能瓶颈。 另外如果没有开源项目的支撑前提下自己来做这样一套东西是非常大的一个工作量而且还要做 API 网关本身的高可用等如果一旦做不好有可能最先挂掉的不是你的其他服务而就是这个API网关。 这个时候通常我们会去找一些开源的 API 网关项目博主已经给你找好了目前社区的关于 API Gataway 的项目有以下这些 TykTyk是一个开放源码的API网关它是快速、可扩展和现代的。Tyk提供了一个API管理平台其中包括API网关、API分析、开发人员门户和API管理面板。Try 是一个基于Go实现的网关服务。 KongKong是一个可扩展的开放源码API Layer(也称为API网关或API中间件)。Kong 在任何RESTful API的前面运行通过插件扩展它提供了超越核心平台的额外功能和服务。 Orange和Kong类似也是基于OpenResty的一个API网关程序是由国人开发的学姐也是贡献者之一。 Netflix zuulZuul是一种提供动态路由、监视、弹性、安全性等功能的边缘服务。Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。 apiaxle: Nodejs 实现的一个 API 网关。 api-umbrella: Ruby 实现的一个 API 网关。 我们来说说上面的这些开源项目适不适合作为 API 网关来供我们使用。 拿单节点网关来说这种网关相当于是处于 Web 层和 Service 之间用来聚合服务的注意我们需要的是聚合服务而以上这些开源项目都不具备这个功能我说的聚合具体指的是开箱即用。我们要想使用这些服务需要来自己对API网关过一些扩展或者是开发一些插件这个时候问题就来了。扩展Tyk我需要会Go语言扩展Kong我需要会写lua脚本使用 zuul 还得会Java这对于开发人员来说是不太现实的那么这个时候怎么办 有些同学可能会说 ASP.NET Core 可以使用 Ocelot说得没错我们可以通过引入Ocelot来处理API聚合服务这一块的业务但是这中间有一个问题就像我在上面说的一样这很容易造成性能问题另外一方面Ocelot的功能相比上面的那些开源项目来说功能要弱很多具体体现在哪些方面呢 除了最重要的高性能的IO模型和集群方案外 比如会经常使用的 Dashboard 功能这个对于运维来说是非常重要的另外还有日志监控安全服务发现版本控制等。 小编注比如说dashboard https://github.com/dbarkwell/Ocelot.ConfigEditor 很多想法还在探讨中大家可以通过Issue 参与或者直接贡献相关代码自己撸。超时熔断重试这些功能ocelot都已经具备。 但是上面的这些 API 网关缺少什么功能呢 比如超时熔断重试聚合查询等。 注意以下内容的这些想法全是我个人对于 API 网关的理解而诞生的如有错误还请指正。 聪明的同学可能想出来了怎么办呢 我们可以充分来结合两者的优势来在我们的 ASP.NET Core 应用程序中实现一个“双重网关”。 下面是我画的一个 API 网关在微服务架构中的一个作用图 应该大部分同学都可以看懂我就简单解释一下。 OpenResty Api Gateway 从左至右 HTTP 请求先由DNS在拿到第一手流量后负载均衡到基于 OpenResty 的 API Gataway 网关集群在这个流程我们可以使用像 Kong,Orage,Tyk 这些开源的支持高并发高访问量 API 网关程序在做第一层流量的防护在这一级我们可以做一些像身份认证安全监控日志流控等策略。除了这些我们还可以做一些服务的发现和注册这个要看不同网关的支持程度接口的版本控制路由重写等。 Aggr Api Gateway 然后再由这些 API 网关把请求再负载到不同的 Aggr Api Gateway在这里我们做聚合服务这个操作具体体现也就是图中的黄色区域是需要由各个语言的开发人员来需要写代码实现的。具体流程也就是我们可以引入像 Ocelot 这种和语言相关的 API 网关开源项目然后通过 NuGet 包引入之后通过 Json配置聚合代码的方式来整合后端的各个微服务提供聚合查询等操作。这期间对于有需求的接口我们可以应用超时缓存熔断重试等策略。 从 Aggr Api Gateway 到后端微服务集群这中间就属于内部的通讯了我们可以使用对内部友好的通讯协议比如 gRPC 或者 AMQP 等然后进行 RPC调用提高通讯性能。 注意Aggr Api Gateway 这个网关对于一些接口来说的话并不是必须的也可以由后端微服务直接提供REST API给第一层网关使用。 以上就是我理解的 API 网关在整个微服务架构中的一个地位承上启下还是非常的重要。 广告 我们知道在 API 网关的后端是微服务的集群那么除了聚合查询之外有时候我们有时候需要做一些跨不同服务的操作比如一次电商系统的下单操作可以会设计到产品、价格、库存等一系列跨微服务操作在中间我们一般会采用集成事件(EventBus)来进行通讯这种解决方案在这个过程中我们不仅仅的是需要通讯那么这些操作还需要保证事务一致性而一般分布式系统中的事务我们追求的是最终一致性。 如果是在 .NET Core 中我们可以使用博主开源的 EventBus 分布式事务 解决方案 CAP。 GitHubhttps://github.com/dotnetcore/CAP CAP 介绍 http://www.cnblogs.com/savorboard/p/cap.html 有关分布式事务可以查看我的这篇文章。 感兴趣的同学可以给CAP一个 Star 以表支持偷偷告诉你 Ocelot的作者也Star了哦。 :) 总结 通过本文我们了解到了什么是 API 网关以及API网关的作用和其在微服务架构中所处的地位。然后我们了解到了 API 网关的一些开源项目以及博主介绍的落地方案在实际的实践中还是多希望大家能够多多思考总结这样我们才能够变得更加强大。 相关文章 Ocelot——初识基于.Net Core的API网关 Ocelot API网关的实现剖析 微服务网关Ocelot API网关Ocelot 使用Polly 处理部分失败问题 .NET Core 事件总线,分布式事务解决方案CAP CAP 介绍及使用【视频】 分布式事务,EventBus 解决方案:CAP【中文文档】 原文http://www.cnblogs.com/savorboard/p/api-gateway.html .NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
