精华内容
下载资源
问答
  • 对内 DDD,对外 API 是去哪儿网机票目的地事业群业务研发团队2020年 Q3 重点推出的业务重塑架构设计理念。在2020年 Q3,去哪儿网在过往的基础上,在 API 标准化这个领域做出了一些进步,这篇文章主要就是把这方面的...
    李征(去哪儿网工程师)

    2017年2月加入去哪儿网。目前专注于领域服务治理、基于API治理的领域能力标准化。致力于通过领域化、模型化、可感知来解决业务复杂度。期望用DDD驱动,降低系统复杂度,提升团队效能。


    前言

    对内 DDD,对外 API 是去哪儿网机票目的地事业群业务研发团队2020年 Q3 重点推出的业务重塑架构设计理念。在2020年 Q3,去哪儿网在过往的基础上,在 API 标准化这个领域做出了一些进步,这篇文章主要就是把这方面的经验和大家分享一下。

    什么是对内 DDD,对外 API 呢,这个是我们业务研发领域内使用 DDD 作为领域设计、微服务设计的理念的实践原则,领域间使用 API 进行交互的一种通俗易懂的说法。


    1. 去哪儿网 API 发展的历史简述

    去哪儿网在 API 领域其实有不少成熟的工具,常用主要包括 wiki、YAPI 和 swagger。

    wiki 是去哪儿网最为传统的 API 承载工具,公司较早出现的公共平台,如支付中心,所提供的标准 API 就全部是通过 wiki 的方式呈现出来的。wiki 的优点是自由度相对较高,不受到各种规范的约束,修改也比较随意,可以非常个性化的去满足某些接口阅读者的诉求,天然的安全性较好,非公司内员工没有权限进行访问。缺点就要更多一些,例如因为没有一定的接口规范进行约束,接口的定义方式五花八门,有各种非常个性化的约定方式,相同的约定方式,呈现方式也不一样,有的倾向于给出嵌套式的呈现,有的则倾向于给出模块化的呈现,接口定义与接口之间的同步全部依赖规范和工程师的自觉,极易出现 wiki 与代码不匹配的情况。

    正因为如此,我们可以说从提供 API 的角度看,wiki 可以提供可读性较好的 API 但是 wiki 不能提供可信、可靠的 API。

    在去哪儿网起到支撑作用的第二个解决方案是 YAPI,YAPI 兴起的背景是从2016年开始的前后端分离架构。前后端分离使得前端工程变得更加独立。YAPI 也在2018年成为了去哪儿网的开源项目。YAPI 作为前端同学开发的接口平台直到现在仍然是去哪儿网 API 解决方案中的基石之一。YAPI 的作用用一句话来表述就是“共同维护一份接口定义,并连接前后端”。

    YAPI 与 wiki 的区别可以用下图来表示:
    在这里插入图片描述
    从上图可以看出,YAPI 通过支持打桩测试这个抓手,通过运行 API 接口,测试能否得到预期中的结果来倒逼文档与接口定义一致。这个实现方式十分的巧妙,但是也十分依赖测试环境的完善以及对 API 测试的硬性要求,如果这两者得不到保障,那么这么巧妙的一个模式最终造成的结果仍然是接口与接口文档的分类和不同步。与用 wiki 差别不大,只是 YAPI 拥有着更加符合 RestFul API 规范的接口管理平台,这点与 wiki 相比对 API 的定义是一种约束。

    为了防止接口定义与接口不同步(文档与代码不同步),后端同学引入了用于与代码使用 annotation 方式绑定在一起的 swagger,并且在 swagger 的基础之上做了一些基于 maven 的扩展,使得通过 swagger 编写的规范能够通过 maven 命令和发布等工程状态变化将接口的变化更新到 YAPI 平台,解决接口文档与接口实现不匹配的问题。

    swagger -> YAPI 取得了一定的效果,但是因为使用 swagger 来编写 API 文档的工程比较少,并且少有人知道有 swagger -> YAPI 这个工具,使得 swagger -> YAPI 这种方式并没有在公司内部推广开来使用。


    2. 去哪儿网推进 API 标准化建设的原因

    2020年因为疫情的原因,去哪儿网开始了轰轰烈烈的“练内功”行动,这其中就包括核心业务领域的业务 DDD 重塑、硬件成本节约、API 内部实现重构等。

    做这几件事情的时候我们面临了一些困难:

    1. DDD 重构需要与领域外通过接口进行调用,那么一个领域与外部领域之间提供多少接口比较合适呢?10个?30个?50个?如果提供的 API 过多,是否意味着 API 不够标准,质量不够高呢?

    2. 硬件成本中包括实体机&虚拟机节点成本和离线日志、实时日志成本,那么实体机虚拟机节点多少是比较合适的?系统的离线日志、实时日志产出多少又是合适的?这部分很依赖系统 API 的数量以及 API 访问量的提供。

    3. API 内部功能重构后,哪些下游访问了这个 API?在使用诸如 QueryDiff 等工具对接口本身进行回归之后,出于保险起见需要对哪些下游系统进行回归测试呢?这方面就很依赖于 API 的上下游关系的治理,而想实现基于治理结果的自动化测试则依赖 API 的标准化。

    通过上面几个例子我们看到,API 重新成为重要的技术改进点是整体上对内 DDD,对外 API 系统架构理念的需要,是硬件成本管理的需要,是平台化服务重构的需要。
    在这里插入图片描述


    3. API 标准化的理论基础

    API 标准化的理论基础来自于 Jeff Bezos 2002年提出的系统间接口化理念,后续这个理念被逐步充实成为了一种称为 SOA 成熟度的理念。

    Bezos 是这样表述 Amazon 系统接口化的理念的:

    2002年,贝索斯突然向全公司发布了一道指令。
    -从今天起,所有的团队都要以服务接口的方式,提供数据和各种功能。
    -团队之间必须通过接口来通信。
    -不允许任何其他形式的互操作:不允许直接链接,不允许直接读其他团队的数据,不允许共享内存,不允许任何形式的后门。唯一许可的通信方式,就是通过网络调用服务。
    -具体的实现技术不做规定,HTTP、Corba、PubSub、自定义协议皆可。
    -所有的服务接口,必须从一开始就以可以公开作为设计导向,没有例外。这就是说,在设计接口的时候,就默认这个接口可以对外部人员开放,没有讨价还价的余地。
    -不遵守上面规定,就开除。

    在这里插入图片描述
    而从上面 Jeff Bezos 的决策发展出来的 SOA 成熟度模型则对于 API 的标准化有着较为明确的要求,包括:

    • 定义接口、方法、参数、类型及描述的详细规范

    • 定义评判标准 、

    • 开发工具插件支持:IDEA、eclipse 插件对规范的识别

    • 发布系统对 API 的支持

    从上面的一系列对 API 的要求总结下来,我们需要 API 具有如下特点:

    1. 规范易理解

    2. 组件易接入

    3. 语法易使用

    4. 执行易管理

    5. 平台易应用

    还有一个总的原则:所有功能基于已有的去哪儿网基建,不重复造轮子。
    在这里插入图片描述
    由此得到了去哪儿网 API 标准化整体解决方案:

    其中,API 存储平台 YAPI 是现成的,稍加改造即可支持本次 service api 标准化的诉求,应用树管理平台也是现成的,去哪儿网的现有系统叫做 Portal,应用域管理平台 qtracer 也是现成的,只是针对本次需求对功能做了扩展,网关和开放平台也是现成的,这次做了二者的系统集成。可以说,只有 QDoc-annotation 和 QDoc-maven-plugin 是新创建的插件、工具。


    4. API 标准化的具体实施过程

    4.1 规范易理解

    首先我们要做的就是制定一套 API 书写规范,这套书写规范主要是限定我们针对 API 说明的注解或者注释如何进行组织,相当于一个业务系统 Domain 维度的实体对象关系设计。我们对于 API 大致设计了如下这些元素:

    通过规范制定委员会规范了如下一些术语:

    领域(domain/group)

    针对某一项业务的总体系统边界,一个领域(domain)会包含多个应用(appcode),一个领域对外暴露的接口是通过 appcode 来暴露的,属于对外开放部分。注:领域可以映射到应用树的三级节点 / 四级节点。

    应用(appcode)

    应用特指 Qunar 体系下的 appcode,一个 appcode 即一个应用。存在一种特殊情况,一套代码(一个 git 工程)部署多个 appcode,我们认为是多个应用。

    服务(service)

    同一个 appcode 下,可以提供多个服务(service)。对于不同服务实现(dubbo / http)会有不同的表现形式。

    • 对于 dubbo,很好理解,一个 service interface 就对应一个 service。

    • 对于 http,基于 Spring MVC(restful)的思路,每个 service 对应一个 controller。(这样就要求不同的 controller 来区分一个功能组)。

    接口(interface)

    这是一个最细粒度的功能维度,是 service 的一个真子集。对于不同服务实现(dubbo/http)会有不同的表现形式。

    • 对于 dubbo,就是一个 service 下提供的方法(method)。

    • 对于 http,就是一个 controller 下提供的 RequestMapping(method)。

    参数(parameter)

    参数是接口的重要组成部分。对于不同服务实现(dubbo / http)会有不同的表现形式。

    • 对于 dubbo,很好理解,基于 java 的方法签名的入参即可,同时包括 RpcContext 中的内容(除特殊情况,等同于 QTraceContext)。

    • 对于 http,参数包含四部分,第一部分是由 URL 中的参数列表传递的,第二部分是放到 POST 的 http 数据中的。通常这两部分基于 Spring MVC,都是可以通过 @RequestParam 定义的。第三部分是 cookie 信息(request header),第四部分等同于 QTraceContext。

    类型(type)

    无论对于入参和出参而言,都需要用类型进行标识。类型是一个可描述的结构定义。对于不同服务实现(dubbo / http)会有不同的表现形式。

    • 对于 dubbo,显而易见的,Java 的类型定义,即为这里的 type。同时需要说明一种特殊情况 Object,对于 Object 而言,其代表任意结构,这在 type 里是不允许的,必须标识出对应 Object 的实际类型(具体的类定义,或 json schema定义)。

    • 对于 http,入参一般是基本类型、或类 JSON 类型(包括集合等,都以 json 描述),出参都以 json 描述。http 是一个弱类型定义系统,对于文档是不友好的,因此我们规定入出参类型以 json schema 方式定义。

    规范术语后,我们开始制定与术语相对应的注解和注释,一期我们先规范了对应的注解:

    领域(@QDomainDoc)
    应用(@QAppcodeDoc)
    服务(@QServiceDoc)
    接口(@QInterfaceDoc) 这里面存在参数注解和返回值是否可以删除
    参数(@QParamDocs)
    参数(@QParamDoc)
    Model参数(@QParamModel)
    Model属性的注解 (@QParamModelProperty)类型(@QTypeDoc)等同于 @RequestParam。目前未实现,后续支持
    返回值状态码的描述(@QResponses)
    返回值状态码的描述(@QResponse)
    返回值数据描述说明
    返回值数据(@QResponseDocs)
    返回值数据(@QResponseDoc)
    异常(@QExceptionDoc)
    扩展(@QExtensionDoc)

    相应的每一个注解我们也都会给出对应 annotation 参数使用说明:

    **服务(@QServiceDoc)**描述 service 的用途:
    在这里插入图片描述
    大家可以看到,QDoc 给出的规范术语和 annotation 充分考虑到了去哪儿同学通常使用的工程上下文语境,例如 Domain、AppCode,都是去哪儿网工程语境中的常用词汇,一看到这些词就能想到是做什么用的,这些贴近工程师常用词汇的术语使得工程师对于 QDoc 规范的理解很顺畅,不需要看大段的说明就可以理解个大概,学习成本低,上手使用很快。这点是去哪儿网制定的规范与 swagger2.0,swagger3.0,smart-doc 等第三方 API 工具的很主要的区别,也是我们在支持 OpenAPI3.0 规范的前提下,采用自定义 API 术语的一个很重要的原因。

    当完成了基于 annotation 的 API 规范化组件定义后,下一步就是对应工具、插件的开发以及工具的接入工作。

    4.2 组件易接入

    QDoc 为了方便业务线工程师的接入,最大限度的不让业务线开发工程师在接入 QDoc 的过程中有额外的开发量,采用了 jar 包加 maven 插件的方式,接入步骤十分简单:

    服务接入步骤

    1. 接入 qdoc 服务需要在 pom 中引入对应的 maven 插件,来完成 qdoc 的发布;

    2. 如需采用 Annotation 方式撰写 API 文档,则,需要 qdoc-annotation 包以便完成编写;

    3. 具体依赖引入:(Maven Plugin)

    <plugin>
        <groupId>com.qunar.fd</groupId>
        <artifactId>qdoc-maven-plugin</artifactId>
        <version>${qdoc.maven.version}</version>
    </plugin>
    QDoc Annotation
     
    <dependency>
        <groupId>com.qunar.fd</groupId>
        <artifactId>qdoc-annotation</artifactId>
        <version>${qdoc.annotation.version}</version>
        <scope>provided</scope>
    </dependency>
    

    4.3 语法易使用

    QDoc 的语法分为两部分:一部分是 git 工程侧语法,一部分是代码 API 侧语法,两部分共同构成了去哪儿网标准化的 API。

    Git 工程侧语法如下,QDomainDoc 和 QAppcodeDoc 都采用这种方式进行应用。

    除 QDomainDoc 和 QAppcodeDoc 外的其他注解与 API 代码结合但非入侵式应用:

      @QInterfaceDoc(
                type = "dubbo",
                define = "给用户发送短信验证码,dubbo接口",
                desc = "校验手机号是否为用户所有,给用户发送短信验证码",
                scene = "给用户发送短信验证码",
                notice = "内网使用",
                since = "发送短信验证码,产品需求引入",
                authors = "fanrong.zhao",
                url = "dubbo_send"
        )
        @QParamDocs({
                @QParamDoc(name = "paramV1", value = "第一个参数", paramType = "form", dataType = "String", notice = "必须是string类型的", paramExample = "username"),
                @QParamDoc(name = "paramV2", value = "第二个参数", required = false, paramType = "form", dataType = "Boolean", notice = "必须是boolean类型的", paramExample = "true")
        })
        @QResponses({
                @QResponse(code = -1, message = "系统异常"),
                @QResponse(code = 200, message = "成功")
        })
        @QResponseDocs({
                @QResponseDoc(bindValueName = "data", description = "第一个参数", bindValueType = "object", propertys = {
                        @QProperty(type = "String", name = "name", desc = "描述1"),
                        @QProperty(type = "int", name = "age", desc = "描述2"),
                        @QProperty(type = "com.qunar.fd.qdoc.qdocexample.vo.ExampleResultVO",name = "food",desc = "描述3")
                }),
        })
        public ApiResponseV2<Food> example0(@RequestParam String paramV1,@RequestParam boolean paramV2) {
            return null;
        }
    

    通过目前已经在使用的去哪儿网工程师同学们反馈,一个中等复杂度的 API,通过注解方式书写 API 只需要5分钟的时间。

    4.4 执行易管理

    去哪儿网 QDoc 工具在 API 同步方面主要支持两种方式,maven 命令同步与发布系统同步。maven 命令同步一方面可以满足 Design2doc 的诉求,另一方面也更为灵活,也继承了去哪儿网在 swagger-YAPI 方面的积累,通过发布系统同步是本次 QDoc 的主要工作。这方面的工作解决了接口与 Master 版本不同步的所有问题,包括接口创建、更新、回滚等。

    我们可以看到:

    服务开通步骤

    1. 发布系统开通展示

    在去哪儿网应用树中,对应 appcode 下有服务列表,服务列表中【QDoc】,点击开通,即可完成应用树的集成开通。

    1. CM 发布集成

    在去哪儿网发布系统中,对应 appcode 下通过服务集市进行开通。

    开通后,Portal 发布线上后,会自动触发文档的更新操作,这时,就可以在应用树中看到我们的文档了。
    在这里插入图片描述
    通过简单的3步,我们就完成了 QDoc 与发布系统的集成。

    4.5 平台易应用

    前面的工作完成得再好,如果没有交互良好的展示平台进行支撑,那么对于使用者来说也是十分痛苦的,应用费力度高的系统也是很难进行普及的。我们最终的选择是,YAPI 嵌入到 App 管理平台,与 Appcode 管理相绑定,给与团队管理者一站式的管理体验。

    YAPI 可以参考开源版本 https://hellosean1025.github.io/yapi/

    但是,只有 appcode 维度的 API 管理只能方便工程师团队进行 API 的一站式管理,不能对 DDD 业务重塑中十分重要的 Domain 维度的 API 管理产生正向的帮助。目前我们正在对 Domain 维度的 API 管理平台做着不断的优化:
    在这里插入图片描述
    当然,我们建立了 Domain 维度的 API 管理体系后,顺带可以做的就是通过去哪儿网成熟的网关体系来外放我们的 API:
    在这里插入图片描述
    介绍到这里,去哪儿网通过 QDoc 工具,从代码中的 API 注解到开放平台的领域 API 的全流程就介绍完毕了。

    那么在项目中我们遇到了哪些难点呢?


    5. API 标准化的实施难点

    5.1. 开发资源从哪里来

    这个项目是去哪儿网机票目的地事业群业务研发 TC 发起的项目,没有直接的团队进行资源支持,所需要的资源跨 CM、YAPI 平台、工具开发、业务试点项目接入开发几大块,几乎涉及到了公司所有团队的工程师,项目采用了公司内开源项目管理的方式,成立项目组,单独立项,跨团队联合各个团队的资源完成项目,项目的完成对于项目管理人员也是不小的挑战。

    5.2. Design First or Code First

    作为项目的初始阶段,同时支持 Design First 和 Code First 两种方式是不可能的,我们通过调研发现,Design First 更加适合非 Domain 维度接口的制定,例如一个前后端联调接口,这类支撑类接口不具有通用性,会随着页面的变化而重新进行开发,通常不复用。Code First 更适合帮助 Domain 维度的长期维护支持的接口保持高质量。而我们这次做 API 标准化工作的初衷就是要帮助 DDD 业务重塑做好 Domain 维度接口的规范化维护工作。所以我们选择首先支持 Code First 的接口提供方式。

    5.3. Annotation or Comments

    在我们做 QDoc之前,在公司内有一定使用度的 API 标准化工具包括 swagger2.0,swagger3.0,smart-doc , 在这点上我们通过调研发现,使用注解方式的 swagger 相关工具的工程师要明显多于使用 smart-doc 类注释方式的工程师,尽管 annotation 的方式存在 API 代码上方 annotation 堆积过多,会产生代码不美观的问题,但是既然使用 annotation 注解方式的用户明显更多,我们决定 QDoc 优先支持注解方式。这并不代表之后 QDoc 不会支持注释方式。

    5.4. 支持完整的 OpenAPI3.0规范 or 支持 OpenAPI3.0规范的子集

    这个问题来自于我们已经有了2018年开源的已经相当成熟的 YAPI 平台,那么我们是否满足 YAPI 的接口要求就已足够?是否不必完全满足 OpenAPI3.0规范的要求,我们的回答是否定的。平台是在不断发展的,YAPI 也会有老去的一天,当 YAPI 老去的时候我们也会在支持 OpenAPI3.0规范的其他平台中作出选择,目前看 knife4j 就是一个在我们视线之内的 API 平台。


    6. 项目的成果

    DDD 与 API 最终会师。核心域、支撑域、通用域 API 均已接入。

    1. 核心域 API 标准化有效保护了领域不被入侵
    2. 通用域 API 化有利于实现通用域的平台化
    3. 支撑域 API 化降低了开发量
      在这里插入图片描述
      没有重复造轮子,一切因势就形:
      在这里插入图片描述

    7. 总结与项目的后续计划

    在这里插入图片描述
    从之前的介绍我们可以看到,去哪儿网的 API 建设是有层次的,最内层是 AppCode 维度的 API,外一层是业务接口维度,再外一层是领域维度,通过网关将可以开放的接口配置到开放平台,形成不同维度的接口管理与接口用用。

    后续在 AppCode 维度的接口管理方面还要做以下几件事情:

    • 完成 IDEA 接口合规插件;
    • 支持注释模式;
    • 支持客户端/服务端代码生成;
    • 领域接口维度要调研:是否有比 YAPI 更好的替代方案,knife4j 一直在视野中;
    • 还有更重要的一件事情就是通过 API 标准化的发展,反向促进 DDD 的思想在各业务领域产生全面的更加深入的认知。




    在这里插入图片描述

    展开全文
  • 2015年初,百亿房企俱乐部成员奥园地产...在移动互联网布局方面,奥园集团采用金蝶云之家搭建生活O2O平台,连接员工业务。 本文来自2015中国管理全球论坛·云之家分论坛的奥园集团副总裁张永虎演讲实录,略有删减。

    张永虎 奥园集团副总裁

    2015年初,百亿房企俱乐部成员奥园地产集团宣布互联网发展战略,通过搭建O2O技术平台,开启相关跨界升级产品开发等模式打造新一代文化、旅游、养生、商业复合地产项目,引起业界广泛关注。在移动互联网布局方面,奥园集团采用金蝶云之家搭建生活O2O平台,连接员工和业务。

    本文来自2015中国管理全球论坛·云之家分论坛的奥园集团副总裁张永虎演讲实录,略有删减。

    在移动互联网连接一切,重构行业格局时代大背景下,各大房企纷纷争抢白银时代的入场券。奥园地产也在进行“互联网+”转型,但这不仅仅是平台、工具的变化,更重要的是思维的改变。

    基于以上的想法,我们树立了以“以客户为中心”的对外服务平台,以及“连接员工”内部管理策略,并为此选择了云之家移动工作平台。

    首先,奥园集团希望通过移动互联网连接客户,构建客户服务平台。地产不同于快消品,有可能一辈子就买一次。房子买了、社区建起来之后,客户还会有商业服务、文化、健康养生等方面的需求。我们要改变客户对我们认知的渠道,在移动互联网时代,通过AO公寓、AO社区、AO商街等一系列产品,打造客户服务平台。

    其次,奥园集团希望能够建立沟通移动化、业务移动化,通过一个工作平台实现员工与业务、员工与员工之间的连接。奥园基于云之家构建的移动工作平台名称是“AoOffice”,希望通过这个平台增强集团内部、员工间的交流互动分享,主要解决集团内部业务移动化、人际工作协作、业务流程审批等问题。

    目前,在实现业务移动化方面,我们通过信息通知、业务自助、管理报表集成提升业务效率。譬如集团新闻、公告自动推送,信息到人;在平台轻应用集成的人事、销售、成本等报表信息,随时随地产看;此外,还实现业务集成,轻应用连接出纳、资金系统,即时查询账户资金余额。

    在人际工作协作方面,奥园云之家“AoOffice”集成了集团通讯录,能快速找到组织中的工作伙伴进行业务协作;此外,通过创建任务、会议管理等功能实现高效协同工作;还支持文档云端存储,随时随地浏览分享。

    在业务流程审批方面,“AoOffice”与CRM、HR、OA等系统集成,实现流程移动化。轻应用连接EAS系统,如今只需手机就能实现移动审批;此外,通过轻应用连接OA系统,实现OA审批移动化,目前已上线的OA系统共有200多个。

    奥园理解的“互联网+”并不是什么高大上的东西,而是要提高效率、了解客户需求、加快市场反应速度。房地产行业是一个资金密集型企业,动辄上亿的资金。市场瞬息万变,客户需求也在变化,“互联网+”就是要快速跟上市场步伐。此外,“创新、高效率”,是我们对互联网的理解,创新要求我们转变观念,从客户需求出发,重构产品和商业逻辑。无论在思维方式上、内部的构建上、组织结构上都要适应互联网创新,高效率就是要实现自动化和运营的无缝连接。

    【关于云之家】

    云之家,金蝶出品的移动工作平台,提供企业通讯录、语音会议、消息、签到、文件等免费办公应用,并可通过开放API连接企业现有业务(ERP),帮助企业/团队打破部门与地域限制,提高沟通与协作效率。截止2015年9月,云之家企业数突破70万,用户数突破600万,知名用户包括万科、海尔、中石油、国资委等,荣膺赛迪网2014最佳商务办公APP、雷锋网2014年度十佳应用。


    http://help.3g.163.com/0406/15/1113/12/B8A50HOD0406002E.html


    展开全文
  • API 网关 ( API gateway )

    千次阅读 2021-04-16 15:01:50
    网关来接收从千百个终端发出的请求,它实现对外统一接口,对内进行负载均衡的功能。极大的方便了 API系统 的开发与维护。如果有需要,API 网关也可以根据各终端使用的不同通信协议来进行协议适配,从而方便应用层...

    img.png

    前言

    在 IOT ( 物联网 )中,当我们的一些设备。例如( 监控、传感器等 )需要将收集到的数据和信息进行汇总时,我们就需要一个 API
    网关来接收从千百个终端发出的请求,它实现对外统一接口,对内进行负载均衡的功能。极大的方便了 API系统 的开发与维护。如果有需要,API
    网关也可以根据各终端使用的不同通信协议来进行协议适配,从而方便应用层进行数据采集和分析。

    什么是 API 网关?

    在想了解什么是API 网关 ( API Gateway ),首先我们需要了解什么是微服务。

    微服务

    img_4.png

    微服务是一种用于构建应用的架构方案。微服务架构有别于更为传统的单体式方案,可将应用拆分成多个核心功能。每个功能都被称为一项服务,可以单独构建和部署,这意味着各项服务在工作(和出现故障)时不会相互影响。

    我们依靠下面几个阶段来简单的了解一下,什么是微服务。

    一、单机阶段 ( 所有服务一把梭 )

    img_6.png

    在一个项目的起步阶段,我们可能会把所有的功能放在一个项目内( 例如商城系统 )这样方便快速开发与迭代。

    二、拓展阶段 ( 水平、垂直拓展 )

    img_7.png

    随着你公司的业务越来越大,服务越来越广,你将开始考虑进行水平或垂直拓展了。

    • 水平拓展:简单说就是将服务放到多台机器上进行负载均衡。

    • 垂直拓展:简单说就是提升单台服务器的性能( 俗称氪金 )

    三、微服务阶段 ( 对服务进行拆分 )

    当你的公司变得更大,开发人员也变得多而杂。项目也随着时间变得特别臃肿的时候。你就需要将服务进行拆分,人员按照服务类型进行分组。

    例如商城系统,可以分为 用户系统、交易系统、商品系统等等。

    为什么要有API 网关?

    我们已经了解了什么是微服务。那么为什么微服务要有API 网关呢?

    疯狂的客户端 ( Mad client )

    哈哈,开个玩笑的标题。

    如果不使用 API 网关,那么你将会立马面临一个棘手的问题。

    img_2.png

    如图所示,当你有三个服务( 服务1、服务2、服务3 )时,如果没有API 网关,你的客户端就需要记住每个微服务的地址。例如:服务1 ( http://xxx.com )、服务2 ( http://yyy.com )、服务3 (
    http://zzz.com )。

    当你有几十个微服务时,相信我,你的前端一定会把你杀了的。

    当然,Api 网关可不仅仅有路由的功能。

    API 网关可以干什么?

    下面我们来简单捋一捋 API 网关都可以做啥吧。

    • 统一入口 : 也就是刚才说的路由功能,API 网关可以通过内部维护路由表来进行反向代理。

      img_9.png

      什么是反向代理,什么是正向代理。

      • 场景1 ( 正向代理 ) :你们公司有内部网络限制,但是你想登陆公司内部网站处理一些业务。由于你无法直接登陆,所以你需要一个中继代理,通过一个中继的代理服务器来转发你的请求到内部服务器。进行信息交流。

      • 场景2 ( 反向代理 ):你想访问一个网站,例如 “www.moudu.com”,当你输入这个网址时,某度的网关会将你的请求进行路由到别的服务器上处理。

      由此可见一个简单的规则就是:当你知道中继服务器和最终目的的地址时为正向代理,当你知道中继服务地址而不知道目的服务的地址时为反向代理。

    • 安全 : 由于统一个入口,你可以将所有服务的权限、黑名单等涉及身份验证的部分放在网关统一处理。

    • 限流 : 可以基于流量计算分析和限流规则对访问微服务的请求进行限流。

    • 缓存 : 对一些静态数据等进行缓存。

    • 日志 : 可以通过日志系统对所有的请求和响应进行记录,便于日后分析。

    • 监控 : 基于日志系统获取的请求响应数据、时间等进行实时性能监控。

    • 重试 : 对于异常请求进行重试。

    • 熔断 : 对一些故障服务进行服务降级。

      img_8.png

      什么是服务降级?

      当服务器接受到剧烈的压力或者服务出现故障时,根据实时的流量对一些服务和页面进行不处理或简单处理的方式 ( 如上图 )。用以保证核心服务的正常运行。

    一些常见的解决方案

    我们大致了解了 API 网关的功能,接下来我们来讨论一下一些常见的解决方案

    • Nginx

      img_10.png

      由 C 编写的异步的网页服务器可用作反向代理、负载均衡等。C 语言 与 "epoll and queue"模式 为 Nginx 带来超高的性能与低内存开销的优势。使得接下来的很多 API 网关都基于 Nginx 进行实现。

    • Kong

      img_11.png

      基于 Nginx 与 OpenResty 的API 网关,其插件体系结构使得 Kong 获得了强大的扩展能力。它的总体分为三部分:

      • Nginx 提供进程管理和请求的处理。
      • OpenResty 提供 Lua 脚本 ( 一个高性能的脚本 ) 的集成与 nginx 的扩展。
      • kong 集成上述两部分并提供一些持久化配置。
    • Apache APISIX

      img_12.png

      基于云原生设计的 API 网关,使用 etcd ( 一个分布式的强一致性 K-V 数据库 )与 高性能的 lua 脚本 和 Nginx 为 Apache APISIX 提供了强大的容器化能力。

    • Spring Cloud Zuul

      img_13.png

      Spring Cloud Netflix 子项目的核心组件之一,基于Java语言开发、过滤器模式设计。并需要集成其他子项目实现 API 网关功能:

      • Hystix: 用于流量控制,实现流量限制。
      • Ribbon:提供负载均衡能力,并可以提供网络性能和错误的信息。
      • Turbine: 实时收集一些指标,用于监控服务与网络流量。
      • Archaius:提供动态配置的能力。

    总结

    本编文章讲解了一下什么是 API 网关、API 网关 可以解决什么问题。并对一些常见的解决方案进行了简单分析。下面将对如何选型进行一些简单建议:

    • Nginx:如果公司业务小、所需要的功能较少可以使用 Nginx 来快速搭建。

    • Kong:社区活跃度较高,基于它的插件体系结构,如果对功能和扩展性要求较高可以选择。

    • Apache APISIX :云原声和多协议支持( MQTT、Dubbo等)对 IOT ( 物联网 )的服务比较友好。

    • Spring Cloud Zuul: 基于Spring cloud 的实现方案,对于 Java 微服务较为友好。

    展开全文
  • 本文将详细讲解API网关的基础概念,使用场景核心功能,以及基于API网关核心引擎做的API全生命周期管理功能扩展等,最后介绍当前主流的开源API网关引擎。 API网关概述 在微服务架构体系里面,我们一般会使用到...

    本文将详细讲解API网关的基础概念,使用场景和核心功能,以及基于API网关核心引擎做的API全生命周期管理功能扩展等,最后介绍当前主流的开源API网关引擎。

    API网关概述

    在微服务架构体系里面,我们一般会使用到微服务网关或叫API网关。

    大家都比较清楚,在微服务架构体系下本身是去中心化的架构,通过服务注册中心来实现服务注册发现和消费调用,那么为何又需要使用API网关?

    在传统的ESB总线进行服务集成的时候我们就经常谈到一个概念就是位置透明,即需要屏蔽底层业务模块提供API接口服务地址信息,并实现多个微服务API接口的统一出口。即类似设计模式里面经常谈到的门面模式。

    如何给API网关一个定义?

    简单来说API网关就是将所有的微服务提供的API接口服务能力全部汇聚进来,统一接入进行管理,也正是通过统一拦截,就可以通过网关实现对API接口的安全,日志,限流熔断等共性需求。如果再简单说下,通过网关实现了几个关键能力。

    • 内部的微服务对外部访问来说位置透明,外部应用只需和网关交互
    • 统一拦截接口服务,实现安全,日志,限流熔断等需求

    从这里,我们就可以看到API网关和传统架构里面的ESB总线是类似的,这些关键能力本身也是ESB服务总线的能力,但是ESB服务总线由于要考虑遗留系统的接入,因此增加了:

    • 大量适配器实现对遗留系统的遗留接口适配,多协议转换能力
    • 进行数据的复制映射,路由等能力

    对于两者,我原来做过一个简单的对比,大家可以参考。

    这个概念理解后,我们再回到微服务架构里面。

    对于微服务架构大家经常说的最多的就是去中心化的架构,认为ESB中心化架构模式已经过时。而实际上经过上面分析你可以看到。在微服务架构里面的API网关仍然是中心化的架构模式,所有的API接口都要经过网关这个点。

    • 非中心化架构-》走微服务里面的服务注册中心进行接口交互
    • 中心化架构-》走网关进行接口服务暴露和共享交互

    对于微服务架构里面有无去中心化的架构?当然是有的,即我们常说的微服务模块之间可以通过服务注册中心来实现服务发现查找,服务间的点对点调用即使去中心化的。

    如果一个单体拆分为微服务后,完全不需要和外部应用打交道,也不需要共享自己的接口能力,那么这个微服务体系里面就不需要用API网关,仅仅使用服务注册中心即可。通过服务注册中心实现完全的去中心化和接口调用更高的性能。

    什么时候需要使用API网关?

    如果一个微服务架构下,虽然不会外部的其它应用进行交互和集成,但是整个应用本身存在APP应用端,而APP应用端通过前后端分析开发,同时需要通过互联网访问。本身存在需要一个统一访问API访问入口,同时也需要考虑和内部微服务模块进一步进行安全隔离。

    当我们谈到这里的时候,你会发现我们常说的API网关的服务代理或透传能力,实际和我们常说的Ngnix反向代理或路由是一个意思。

    如果你仅仅是为了统一API接口的访问出口,并考虑类似DMZ区的安全隔离,那么在你架构前期完全不需要马上实施API网关,直接采用Ngnix进行服务路由代理即可。因为在这种架构下,API接口消费端,提供端全部是一个开发团队开发,各种问题分析排查都相当方便,类似API接口安全访问等也可以通过JWT,Auth2.0等统一实现,而且这个过程也并不复杂。

    能力开放或多应用外部集成对API管控治理需要

    但是当我们面临是和多个外部应用集成,或者说将自己的API接口服务能力开放给外部多个合作伙伴使用的时候,这个时候对于API接口的管控治理要求自然增加。

    即在常规的服务代理路由基础上,需要增加类似负载均衡,安全,日志,限流熔断等各种能力,而且我们不希望这些能力在API接口开发的时候考虑,而是希望这些能力是在API接入到网关的时候统一灵活配置来实现管控。

    那么这个时候使用API网关作用就体现出来。

    API网关核心功能说明

    对于API网关实际上前面已经多次强调,可以看做是ESB总线的轻量化实现,不再需要复杂的协议转换,适配和数据映射等能力,但是提升了流量控制和安全,实时监控等方面的能力。对于API网关引擎部分提供的核心功能,再简单总结如下:

    实现统一服务代理和服务统一出口

    这点是网关和常规点对点服务注册中心最大的一个区别点,就是位置透明,消费端只需要和网关打交道,具体网关如何和后台的微服务模块打交道,后台微服务模块的部署逻辑,模块提供服务的IP地址等都不用关心。

    由于实现了位置透明,带来一点就是数据流必须通过网关,那么网关本身又成为了去中心的微服务架构中的中心化节点,那么就必须考虑网关节点的性能,可靠性和弹性扩展能力。

    网关要实现位置透明,延伸出来对应的网关必须提供的能力就包括了:

    • 提供服务注册和服务接入的能力
    • 提供服务代理和服务路由能力,能够将服务路由到具体的原始服务上
    • 提供负载均衡能力(该点并不是必须具备)

    在这里准备重点强调下负载均衡能力,实际上对于API网关往往并不是必须具备负载均衡能力。

    • 其一是提供API接口服务的模块本身进行了负载均衡,再提供地址
    • 其二是类似容器化集成和部署,已经可以通过Kubernetes实现了负载均衡

    我们可以看下对于注册和接入到API网关服务的三种场景,只有场景一需要由API网关来提供负载均衡能力。

    注意API网关是否需要具备负载均衡能力,是必须考虑的一个点,即如果底层微服务模块提供的API接口服务本身能够提供负载均衡后的地址,那么网关不需要进行负载均衡。如果底层模块不具备这个能力,那么网关必须具备负载均衡能力。

    微服务模块本身可以基于容器化资源池提供的能力进行动态扩展,因此这个地方本身又有两层负载均衡,一个是kubernetes提供的集群能力,一个是多个API网关本身提供的集群能力。当然API网关本身也具备负载均衡功能,可以和Kubernete进行衔接。

    通过网关的拦截能力来实现所有共性能力抽取和实现

    刚才已经谈到启用网关后就承载了数据流,因此可以通过对接口访问输入和输出的拦截来实现所有共性可复用能力的抽取和实现。这些共性能力可以理解为网关实现的一个个拦截插件,本身可插拔,灵活可配置。

    这些插件能力中最核心的就是安全,日志,流控。

    其中安全可以实现访问安全,传输安全,数据安全等,其中访问安全本身又可以实现类似Token,IP,用户名密码等多种安全控制策略。包括对Auth2.0等标准规范的支持等。

    对于日志也是网关提供的一个关键能力,即可以实现对服务消费日志,详细的输入和输出报文的查询能力,这个在各开源网关往往并不具备这个能力,也无法面向业务系统人员去使用,因此这块能力提升往往都需要在开源网关基础上做大量扩展。

    流控是我们谈的另外一个关键能力,包括了服务限流和服务熔断。对于服务限流主要是实现对服务消费前线程数控制,资源分配实现消费前等待。而对于服务熔断,即直接对服务进行下线或禁用,以避免大并发服务消费调用对网关造成的影响或带来的服务雪崩等。

    一个网关来说,流控能力相对关键,因为网关是中心化节点,必须保证网关的高可靠运行。因此网关流控能力强弱直接影响到网关的高可靠性和性能,而判断流控能力强弱的关键则在于灵活的流量控制策略配置,只有这样才能够做到既实现流控,又不影响到关键业务和接口服务的访问。

    满足前后端分离的需求

    注意,如果一个企业开发的业务系统涉及到手机APP端,而手机APP端一定涉及到公网访问,按业务系统内部部署安全策略也一定涉及到DMZ区的设置和硬件防火墙隔离。

    而对于API网关本身恰好又是可以部署到DMZ区的一个内容,既实现了服务代理路由,又实现了安全隔离,如果存在这种场景,即使业务应用不和外部系统打交道,为了前后端的隔离和外部访问,往往也需要API网关能力支撑。当然前期你也可以使用Ngnix来替代API网关实现统一代理。

    灰度发布或金丝雀发布

    这个在我原来谈网关的文章的时候很少谈到这点,但是实际上在DevOps和微服务架构实施下,对于灰度发布能力往往也是必须的。比如我们对已有的一个接口服务做了修改,我们想先在某些业务系统试用,没有问题再发布到所有的业务系统。这个时候就涉及到金丝雀发布的问题。当然你可以配置是按系统,按IP,按用户还是其他的发布策略。

    这块的能力不仅仅是DevOps的自动部署,同时也必须考虑网关层能够基于动态发布的内容进行路由。确保服务调用消费的路由路径是隔离开的。而对于金丝雀发布策略允许你直接只导入指定量的流量到新的版本,API网关就可以帮你来做这件事情。你可以配置10%的请求到新的版本,然后一旦你确保了新版本没有bug,你可以把流量切换到100%。

    服务组合能力

    实际上当我们谈API网关的时候,一般不会谈服务组合能力,因为一涉及到服务组合或编排,那么必然导入网关整体架构变重。从当前主流网关看,一般也不提供类似能力。

    实际上服务组合编排难点在于,上个服务的输出往往要成为下一个服务的输入,同时服务输入和输出还存在大量的数据映射操作。我们回顾下类似智慧家庭里面的组合场景编排,实际上很简单,比如我回到家后需要打开空调,关窗帘,打开热水器,开灯的一系列动作,我只是需要简单将这些动作编排在一起。

    对应到API网关的服务组合,实际上我们也可以做轻量的服务组合,即去掉数据映射等复杂组合场景,只需要实现简单的服务多次调用,服务返回数据的组合等即可。

    对于具体的服务组合和编排,可以参考:https://www.toutiao.com/i6860399450171376141/

    API全生命周期管理能力

    可以看到,API网关更多是一个底层引擎,而要实现完整的API管控,往往还需要配合API全生命周期管理能力。这个完全可以在底层API网关引擎基础上进行扩展开发。

    API接口的定义

    在定义API接口的时候首先要定义API分组,这个从京东,淘宝等OpenAPI能力开放平台的API文档都可以看到,首先要有API归类分组,然后再定义详细的API。

    比如京东开放平台,有商品,店铺,仓储,支付等多个类目,然后各类目下有详细的API的定义。

    API的定义包括两个部分,一个是API基本信息定义,一个是详细输入输出定义。

    API基本信息仍然是包括了API的编码,API名称,API的分组,API的用途描述,API的缓存,安全等基本控制信息的定义等。还有就是这个API接口的访问路径定义,API接口是Get还是Post方法定义等。

    API详细信息主要就是API的输入和输出信息定义。

    API的输入参数注意实际有多种形式,一个就是在API访问路径上的路径参数,还有一个就是在访问路径后?参数后面的查询参数信息,还有就是一个完整的Request Body请求参数信息。

    比如对于Http Rest查询接口,这类Get方法接口,可以看到并没有Body信息,更多的是通过路径和查询参数定义来完成查询。而对于Post接口往往就涉及到具体的Body信息定义。

    但是要注意,为了实现Http Rest接口和SOAP WS接口服务的互相转换,对于SOAP WS查询服务接口在自动转换为Http Rest接口服务的时候实际上仍然为转换为Post方法+Body参数模式。

    对于API接口定义,仍需要预留标准的系统级参数部分内容。这部分内容是API网关实现统一标准化管理的基础,不能随便修改和变动。比如京东API平台预留的API名称,方法,版本,Token,APP_Key,Date等都是使用系统级别的参数定义,是每一个接口API暴露后都需要增加的参数头信息。

    API快速开发的支持

    在API接口服务定义完成后,一方面是可以通过类似WADL或RAML等标准的Rest接口定义规范文件,另外一个就是需要提供客户端和服务端的开发框架代码。

    在这个基础上,还可以提供完整的示例代码下载,方便开发商或合作伙伴对API接口进行快速开发。开发完成的后端原始服务接口,在注册接入前还可以提供接口服务的模型匹配自校验功能,确认开发的服务完全遵循从上到下方式-》API开发框架生成和API后端服务开发。

    对于API接口管理,如果是标准的从顶朝下模式,即在定义了API接口后,实现生成类似WADL或RAML标准接口规范。后端服务基于我们标准的API接口契约进行开发,那么开发完成后就方便快速代理方式接入,在接入过程中就不再有参数映射和转换的问题,否则我们的API接入过程会比较复杂。

    API接口服务的注册和接入

    API接口定义过程和API接口的注册接入最好分开。

    在API接口定义完成后进行API接口服务的注册,即选择具体的后端服务,然后对服务进行接入。同时将后端服务对应到我们在前面定义的API接口代理服务上。注意在前面谈到的API路径定义,方法类型定义,实际上也可以在API接口服务注册和接入的时候来完成。

    API接口服务的后续变更发布,还可以考虑和DevOps平台配合并支持灰度发布功能。

    反向的后端服务快速接入并发布为API接口服务,即直接对后端已有的API服务进行快速接入,将API后端服务发布为代理服务,在整个接入过程中需要定义API接口名称,API访问路径,API方法类型等信息。在发布为API接口服务后,对于后端服务的API参数信息也需要进行快速导入,以方便在API接口查询中看到详细的接口内容定义。

    在将后端业务服务发布为API接口服务的时候,发布的代理服务要自动增加系统级的输入参数信息,这个输入参数最好的方式是在访问路径中进行增加,以减少对已有的后端服务的影响。

    API接口在注册和接入完成后,将自动进行服务部署和服务发布,即注册接入完成后的服务可以通过发布的访问路径地址进行访问。

    服务接入适配能力

    服务注册接入本身分为两个层面,一个是已有服务的注册接入,一个是需要适配后的服务发布。在设计的时候需要考虑到两个方面的需求。

    对于已有服务的存代理接入最简单,即只需要提供业务系统的Rest接口服务地址即可,在接入的时候,对相关的日志,安全,流控,负载均衡等策略进行配置,配置完成后即完成服务接入和注册。同时对于路由服务接入需要单独考虑,对于路由服务在接入的时候可以适配到多个原始业务系统的接口服务地址。

    服务发布是对原来我们服务适配功能的一个改进,即直接从底向上的进行服务发布,而不需要实现定义服务元数据或模型,制定服务契约格式等,在服务发布完成后再生成相关的基础数据到服务元数据库即可。对于服务发布参考服务适配的能力,我们可以考虑如下场景下的需求。

    • 将一个已有的SOAP WS服务发布和注册为一个Http Rest接口服务。
    • 将一个数据库表,或存储过程发布为一个Http Rest接口服务。
    • 将一个JMS消息接口发布为一个Http Rest接口服务。
    • 将一个JAR包中的API接口方法或函数发布为一个Http Rest接口服务。

    对于服务发布而言,如果不仅仅是微服务网关能力,而是一个微服务支撑或微服务快速开发平台的话,还可以提供完整的服务开发和设计能力。即在微服务平台首先定义数据或对象模型,然后将对象模型转换为Http Rest中的资源对象,并发布对应的Get,Post各种Http Rest接口服务。

    对应发布的接口服务可以直接在微服务平台上进行拦截,模拟生成相关的输入或输出数据。当然也可以直接将数据模型对象生成到对应的数据库,同时将微服务API接口的实现生成对应的Java代码框架并给出参考实现。而我们剩余的工作,仅仅是填充代码逻辑即可。通过这种方式可以极大的提高我们进行微服务架构开发的速度。

    API接口在线模拟测试功能

    这个功能参考当前的OpenAPI能力开放平台的做法来实现即可。即对于已经发布完成的API接口服务,提供在线测试工具进行在线测试。同时对接口服务调用的输入参数进行结构化展示,方便用户对测试需要的各种参数进行输入。在输入完成后形成完整的提交参数完整字符串。通过测试,可以返回最终的模拟调用返回结果字符串信息。

    同样,这里可以采用Swagger工具来完成,Swagger不仅仅是API接口的定义,接口文档的生成,同时还可以根据可以接口定义,自动生成接口测试用例,对接口进行测试工作。我们也很容易将Swagger能力整合都API网关的管理平台中。

    API接口查询功能

    对于API接口查询功能也是一个标准的功能,实际上可以考虑将查询功能和API接口服务的分类浏览分开。对于API接口的分类浏览参考开放平台的API接口文档做法来实现接口。对于API接口查询,即可以设置不同的动态查询条件,对API接口进行查询,返回结果集。对于查询到的API接口清单列表,可以点击详细进入到API接口详细的输入和输出信息查看界面。

    API状态管理功能

    对于已经注册和发布的API接口可以对其状态进行管理。其中主要的状态包括了待发布,上线,暂停,下线废弃等几种关键状态。对于API状态本身还需要和后续的API监控管理结合,能够通过API性能监控动态的调整API接口的状态。比如在API触发熔断后,自动对API接口状态调整为暂停。

    API版本管理能力

    对于API需要启用版本管理能力。当前一些API接口服务实现方法会在路径参数中增加API版本信息,以确定究竟访问哪个版本。但是由于不同的API版本可能存在返回的结果集的数据结构不一样的问题,因此对于这种场景需要针对该API定义不同的大版本,不同的大版本实际上对应不同的后端原始服务。

    在这里我们介绍下当前主流的一些API网关功能供参考。

    开源Kong API网关

    在微服务架构之下,服务被拆的非常零散,降低了耦合度的同时也给服务的统一管理增加了难度。如上图左所示,在旧的服务治理体系之下,鉴权,限流,日志,监控等通用功能需要在每个服务中单独实现,这使得系统维护者没有一个全局的视图来统一管理这些功能。API网关致力于解决的问题便是为微服务纳管这些通用的功能,在此基础上提高系统的可扩展性。

    Kong的插件机制是其高可扩展性的根源,Kong可以很方便地为路由和服务提供各种插件,网关所需要的基本特性,Kong都如数支持:

    • 云原生:与平台无关,Kong可以从裸机运行到Kubernetes
    • 动态路由:Kong的背后是OpenResty+Lua,所以继承了动态路由的特性 限流和熔断
    • 健康检查
    • 日志: 可以记录通过Kong的HTTP,TCP,UDP请求和响应。
    • 鉴权:权限控制,IP黑白名单,同样是OpenResty的特性
    • SSL: Setup a Specific SSL Certificate for an underlying service or API
    • 监控:Kong提供了实时监控插件
    • 认证: 如数支持HMAC,JWT,Basic,OAuth2.0等常用协议
    • REST API:通过Rest API进行配置管理,从繁琐的配置文件中解放
    • 可用性: 天然支持分布式
    • 高性能:背靠非阻塞通信的Nginx,性能自不用说
    • 插件机制: 提供众多开箱即用的插件,且有易于扩展的自定义插件接口

    从上面图可以看到,Kong网关是基于OpenResty应用服务器,OpenResty是一个基于Nginx与Lua的高性能Web平台,其内部集成了大量精良的Lua库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态Web应用、Web服务和动态网关。而Kong核心基于OpenResty构建,并且拥有强大的插件扩展功能。

    在Http请求到达Kong网关后,转发给后端应用之前,可以通过网关的各种插件对请求进行流量控制,安全,日志等各方面的处理能力。当前Kong的插件分为开源版和社区版,社区版还有更多的定制功能,但是社区版是要收费的。

    目前,Kong开源版本一共开放28个插件,如下:

    acl、aws-lambda、basic-auth、bot-detection、correlation-id、cors、datadog、file-log、galileo、hmac-auth、http-log、ip-restriction、jwt、key-auth、ldap-auth、loggly、oauth2、rate-limiting、request-size-limiting、request-termination、request-transformer、response-ratelimiting、response-transformer、runscope、statsd、syslog、tcp-log、udp-log。

    以上这些插件主要分五大类,Authentication认证,Security安全,Traffic Control流量控制,Analytics & Monitoring分析&监控,Logging日志,其他还有请求报文处理类。插件类似AOP开发中的横切功能,可以灵活的配置进行拦截控制,下面选择一些关键性的插件进行简单的说明。

    黑白名单控制能力——ip-restriction

    Kong提供的IP黑白名单控制能力还算相当强,从配置项里面可以看到主要可以针对两个维度进行配置,一个是针对所有的API接口还是针对特定的API接口,一个是针对所有的所有的消费方还是特定的某个消费方。对于IP配置可以是一个区段,也可以是特定的IP地址。但是黑白名单不能同时配置,其次当前没有一个功能是针对某一个系统提供的所有服务都启用黑名单或白名单功能。

    日志记录能力——syslog,file-log,http-log

    这里主要日志的插件比较多,一个是sysLog在配置后可以直接将Kong产生的日志写入到应用服务器的系统日志文件中。如果配置了file-log则是单独写入到你指定的file文件中。对于http-log则是对于http服务请求,可以详细的记录请求的输入和输出报文信息,但是具体是记录到哪里,需要通过config.http_endpoint配置。具体关键的配置参数信息如下:

    •  
    • config.http_endpoint:日志接收服务器(包括使用的协议,http or https);
    • config.method:可选参数,默认POST,访问日志服务器的请求方式(可选值:PUT,PATCH,POST);
    • config.timeout: 可选参数,默认10000毫秒,请求超时时间;
    • config.keepalive:可选参数,默认60000毫秒,连接在关闭之前可存活时间。

    熔断插件——request-termination

    该插件用来定义指定请求或服务不进行上层服务,而直接返回指定的内容.用来为指定的请求或指定的服务进行熔断。注意Kong的熔断插件感觉是临时对服务的禁用,而不是说当达到某一种监控阈值的时候自动触发熔断,或者相关内容还没有了解到。从官方文档的应用场景也可以看到这点。

    • Temporarily disable a Service (e.g. it is under maintenance).
    • Temporarily disable a Route (e.g. the rest of the Service is up and running, but a particular endpoint must be disabled).
    • Temporarily disable a Consumer (e.g. excessive consumption).

    如果仅仅是这种方式的熔断话,实际上意义并不是很大。但是可用的地方就在于当某个业务系统进行发版部署的时候我们可以对该业务系统或该业务系统所提供的所有服务进行熔断。

    限流插件——rate-limiting

    Kong当前提供的限流相对来说还是比较弱,即主要是控制某一个API接口服务在单位时间内最多只能够调用多少次,如果超过这个次数那么网关就直接拒绝访问并返回错误提示信息。而在前面我讲限流和流量控制的时候经常会说到,就是限流实际上一个是根据服务调用次数,一个是根据服务调用数据量,需要在这两个方面进行限流。而里面更加重要的反而是数据量的限流,因为大数据量报文往往更加容易造成内存溢出异常。

    安全认证类插件

    当前Kong网关提供basic-auth,key-auth、ldap-auth,hmac-auth多种认证插件。

    Basic-auth基本认证插件,即我们根据用户名和密码来生成一个base64编码,同时将该编码和目标服务绑定,这样在消费目标服务的时候就需要在报文头填写这个Base64编码信息。

    Key-auth认证插件则是利用提前预设好的关键字名称,如下面设置的keynote = apices,然后为consumer设置一个key-auth 密钥,假如key-auth=test@keyauth。在请求api的时候,将apikey=test@keyauth,作为一个参数附加到请求url后,或者放置到headers中。

    Hmac-auth插件是设置绑定的service和rout,以启动hmac验证。然后在Consumers页面中Hmac credentials of Consumer设置中添加一个username和secret。

    请求报文容量限制——request-size-limiting

    该插件用于限制请求报文的数据量大小,可以限制单个服务,也可以显示所有的API接口服务。

    支持OAuth2.0身份认证——oauth2

    Kong网关支持OAuth2.0身份认证,OAuth2.0协议根据使用不同的适用场景,定义了用于四种授权模式。

    • Authorization code(授权码模式):标准的Server授权模式,非常适合Server端的Web应用。一旦资源的拥有者授权访问他们的数据之后,他们将会被重定向到Web应用并在URL的查询参数中附带一个授权码(code)。在客户端里,该code用于请求访问令牌(access_token)。并且该令牌交换的过程是两个服务端之前完成的,防止其他人甚至是资源拥有者本人得到该令牌。另外,在该授权模式下可以通过refresh_token来刷新令牌以延长访问授权时间,也是最为复杂的一种方式。
    • Implicit Grant(隐式模式):该模式是所有授权模式中最简单的一种,并为运行于浏览器中的脚本应用做了优化。当用户访问该应用时,服务端会立即生成一个新的访问令牌(access_token)并通过URL的#hash传回客户端。这时,客户端就可以利用Java等将其取出然后请求API接口。该模式不需要授权码(code),当然也不会提供refresh token以获得长期访问的入口。
    • Resource Owner Password Credentials(密码模式):自己有一套用户体系,这种模式要求用户提供用户名和密码来交换访问令牌(access_token)。该模式仅用于非常值得信任的用户,例如API提供者本人所写的移动应用。虽然用户也要求提供密码,但并不需要存储在设备上。因为初始验证之后,只需将OAuth的令牌记录下来即可。如果用户希望取消授权,因为其真实密码并没有被记录,因此无需修改密码就可以立即取消授权。token本身也只是得到有限的授权,因此相比最传统的username/password授权,该模式依然更为安全。
    • Client Credentials(客户端模式): 没有用户的概念,一种基于APP的密钥直接进行授权,因此APP的权限非常大。 它适合像数据库或存储服务器这种对API的访问需求。

    简单转换能力——request-transformer and response transformer

    Kong网关提供对输入和输出报文简单转换的能力,这部分内容后续再详细展开介绍。从当前配置来看,主要是对消息报文提供了Add,Replace,Rename,Append等各种简单操作能力。

    Kong网关和其它网关的一些对比:

    从上面对比图也可以看到,Kong网关在功能,性能,插件可扩展性各方面都能够更好的满足企业API网关的需求。因此我们也是基于Konga来进一步定制对Kong网关的管控治理平台。

    在整个定制中增加了基于DB适配的Http Rest API接口的自动发布,API服务自动化注册,服务日志采集和服务日志查询,常见映射模板定制,接口服务的自动化测试等方面的能力。

    阿里公有云API网关

    首先我们来看下阿里云提供的API网关产品的功能介绍:

    API 网关(API Gateway),是提供API托管服务,涵盖API发布、管理、运维、售卖的全生命周期管理。辅助用户简单、快速、低成本、低风险的实现微服务聚合、前后端分离、系统集成,向合作伙伴、开发者开放功能和数据。

    阿里提供的API网关提供的关键功能,参考产品本身的功能文档说明,主要如下:

    API生命周期管理

    支持包括API注册和接入发布、API测试、API下线等生命周期管理功能。支持API日常管理、API版本管理、API快速回滚等维护功能。基本需要覆盖API管理全生命周期。

    全面的安全防护

    支持多种认证方式,支持HMAC(SHA-1,SHA-256)算法签名。支持HTTPS协议,支持SSL加密。防攻击、防注入、请求防重放、请求防篡改。(没看到是否支持Auth2.0和具体的Token验证机制)

    灵活的权限控制

    用户以APP作为请求API的身份,网关支持针对APP的权限控制。只有已经获得授权的APP才能请求相应的API。API提供者可以将调用某个API的权限主动授予给某个APP。若 API上架到 API 市场,购买者可以将已购买的API授权给自己的APP。(没看到是否基于IP进行控制,还是基于Token进行控制,即对于消费方分配独立的Token信息)

    精准的流量控制

    流量控制可以用于管控API的被访问频率、APP的请求频率、用户的请求频率。流量控制的时间单位可以是分钟、小时、天。支持流控例外,允许设置特殊的APP或者用户。(流量控制只支持服务运行频率,没看到可以基于数据量进行流控)

    请求校验

    支持参数类型、参数值(范围、枚举、正则、Json Schema)校验,无效校验会被API网关直接拒绝,以减少无效请求对后端造成的资源浪费,大幅降低后端服务的处理成本。(这个功能实际有一定的用处,并不会牺牲太多的性能,但是会实现一些简单的参数完整性校验能力。)

    数据转换

    通过配置映射规则,实现前、后端数据翻译。支持前端请求的数据转换。支持返回结果的数据转换。(暂时不清楚数据转换功能能够实现的能力)

    监控报警

    提供可视化的API实时监控,包括:调用量、流量大小、响应时间、错误率,在陆续增加维度。支持历史情况查询,以便统筹分析。可配置预警方式(短信、Email),订阅预警信息,以便实时掌握API运行情况。

    自动工具

    自动生成API文档,可供在线查看。API网关提供多种语言SDK的示例。降低API的运维成本。提供可视化的界面调试工具,快速测试,快速上线。(当前网上也有不少的API接口文档自动生成工具可选)

    API市场

    可将API上架到API市场,供更多开发者采购和使用。

    从整个功能的介绍可以看到对于API的全生命周期管理(注册,接入,代理,路由,负载均衡),安全,权限,流量控制,监控和告警等是所有API网关都必须具备的功能。而对于API市场,API文档自动生成,请求的参数校验,数据的转换等则可以看做是扩展功能。

    对于API市场往往是一个重要的扩展能力,即对于API接口服务可以作为商品一样进行订购和使用,并根据相应的调用次数,调用的数据量等条件进行计费处理。这我们我们说的PaaS平台的服务层能力作为产品和服务发布,能够进行订购生产订单,能够进行计费等完全是一个道理。

    对于公有云上API网关存在的背景说明

    对于类似亚马逊,华为云,阿里云等公有云上为何要提供API网关类产品,其关键点还是在于一个企业如果内部的主动业务应用和系统都迁移到公有云后,那么当企业需要将内部多个业务系统的共享或发布给外部使用的时候如何做?这个时候必须要有一个API网关,来进行能力的统一发布,最基本是提供统一的服务目录访问,更加重要的是实现统一的安全管理,授权,服务日志监控预警能力。

    因此一个企业迁移到公有云后,只要存在内部多业务系统,多组件都需要发布API接口能力给外部使用的时候,一定存在API网关的应用场景。

    其它开源API网关

    有赞团队的API网关实践

    https://tech.youzan.com/api-gateway-in-practice/

    有赞API网关目前承载着微商城、零售、微小店、餐饮、美业、AppSDK、部分PC、三方开发者等多个业务的调用,每天有着亿级别的流量。

    有赞后端服务最开始是由PHP搭建,随着整个技术体系的升级,后面逐步从PHP迁移到基于Dubbo开发了一个新的框架Nova,兼容Dubbo调用,同时支持调用PHP服务。于是网关也支持了新的Nova协议,这样就有Dubbo、Http、Nova三种协议。

    在这篇文章中提到的网关核心设计部分相关内容可以参考:

    • 异步特性:我们使用Jetty容器来部署应用,并开启Servlet3.0的异步特性,由于网关业务本身就是调用大量业务接口,因此IO操作会比较频繁,使用该特性能较大提升网关整体并发能力及吞吐量。
    • 缓存:为了进一步提升网关的性能,我们增加了一层分布式缓存(借用Codis实现),将一些不经常变更的API元数据缓存下来,这样不仅减少了应用和DB的交互次数,还加快了读取效率。
    • 链式处理:在设计网关的时候,我们采用责任链模式来实现网关的核心处理流程,将每个处理逻辑看成一个Pipe,每个Pipe按照预先设定的顺序先后执行。
    • 平滑限流: 消除了简单计数器限流带来的短时间内流量不均的问题。 目前网关支持IP、店铺、API、应用ID和三方ID等多个维度的限流,也支持各维度的自由组合限流。
    • 熔断降级:使用Hystrix进行熔断降级处理。Hystrix支持线程池和信号量2种模式的隔离方案,内部也开发了一个基于Hystrix的服务熔断平台。
    • 预警监控: 实时地从Kafka消费API调用日志,如果发现某个API的RT或者错误次数超过配置的报警阈值,则会立即触发报警。

    企业级API网关设计

    https://cloud.tencent.com/developer/article/1080652

    这篇文章是对企业级API网关设计必须系统化的产生,从API网关的概述,API网关所起的作用,当前主流的API网关功能对比分析,API网关的高可用性设计多方面进行了阐述。

    网关层作为客户端与服务端的一层挡板,主要起到了三大类作用:

    • 隔离作用:作为企业系统边界,隔离外网系统与内网系统。
    • 解耦作用:通过解耦,使得微服务系统的各方能够独立、自由、高效、灵活地调整。
    • 脚手架作用:提供了一个地点,方便通过扩展机制对请求进行一系列加工和处理。

    API网关作为对外提供服务的入口,就像企业服务的大门。一方面,要有足够的能力,应对大量的对外访问,另一方面,还要给对内的服务提供一定的安全保障。除此之外,企业提供的API服务多种多样,API网关要能够对这些API的全生命周期进行便捷的管理,例如服务发布、调整、下架、计费、监控等。

    企业API网关在功能设计上主要应该考虑如下内容:

    API 生命周期管理功能:覆盖API的定义、测试、发布的整个生命周期管理。

    API开发和使用支持功能:

    • 安全防护功能:API请求到达网关需要经过身份认证、权限认证,才能到达后端服务。
    • 流量控制功能:API调用次数,异常,分级。流控粒度:分钟、小时、天。
    • 请求管理功能:可根据配置进行参数类型、参数值(范围、枚举、正则)的校验
    • 监控告警功能: 提供实时、可视化的API监控,调用量、调用方式、响应时间、错误率。
    • API交易功能:提供API交易市场,计量计费、Quota控制、运营售卖等需求。

    顺着这篇文章,我们参考了另外一篇谈如何设计高并发下API网关的一篇文章,重点对并发模型,SEDA基于事件的并发架构进行了阐述。

    链接:https://mp.weixin.qq.com/s/U1zklCOztWdh7FpIFvNIfA

    传统的并发编程模型主要有两种:一种是Thread-based concurrency,另一种是Event-driven concurrency。总结下两种模式的特点如下:

    基于线程的并发:每个任务一线程直线式的编程使用资源高昂,context切换代价高,竞争锁昂贵,太多线程可能导致吞吐量下降,响应时间暴涨;

    基于事件的并发:单线程处理事件的每个并发流实现为一个有限状态机应用直接控制并发负载增加的时候,吞吐量饱和响应时间线性增长。

    SEDA架构是目前云计算、微服务时代下一种优秀的消息处理架构,而且历经考验,稳定可靠。SEDA架构的核心思想:把一个请求处理过程分成几个Stage,每个Stage可由不同的微服务进行处理,不同资源消耗的Stage使用不同数量的线程来处理,微服务之间采用异步通讯的模式。

    开源API网关Goku

    GoKu API Gateway,中文名:悟空API网关,是eoLinker旗下、国内首个企业级开源的go语言API网关,帮助企业进行API服务治理与API性能安全维护,为企业数字化赋能。

    GoKu支持OpenAPI与微服务管理,支持私有云部署,实现API转发、请求参数转换、数据校验等功能,提供图形化界面管理,能够快速管理多个API网关,提高API业务安全性。

    码云地址:https://gitee.com/eolinker/goku-api-gateway

    官网地址:https://www.eolinker.com/product/api_gateway/

    Goku API Gateway(悟空API网关)是运行在企业系统服务边界上的微服务网关。当您构建网站、App、IOT甚至是开放API交易时,Goku API Gateway能够帮你将内部系统中重复的组件抽取出来并放置在Goku网关上运行,如进行用户授权、访问控制、防火墙、数据转换等;并且Goku提供服务编排的功能,让企业可以快速从各类服务上获取需要的数据,对业务实现快速响应。

    Goku API Gateway的社区版本(CE)拥有完善的使用指南和二次开发指南,代码使用纯Go语言编写,拥有良好的性能和扩展性,并且内置的插件系统能够让企业针对自身业务进行定制开发。并且Goku API Gateway支持与EOLINKER旗下的API Studio接口管理平台结合,对API进行全面的管理、自动化测试、监控和运维。

    产品关键特性:

    • 控制台:通过清晰的UI界面对网关集群进行各项配置。
    • 集群管理:Goku网关节点是无状态的,配置信息自动同步,支持节点水平拓展和多集群部署。
    • 热更新:无需重启服务,即可持续更新配置和插件。
    • 服务编排: 一个编排API对应多个backend,backend的入参支持客户端传入,也支持backend间的参数传递; backend的返回数据支持字段的过滤、删除、移动、重命名、拆包和封包; 编排API能够设定编排调用失败时的异常返回。
    • 数据转换:支持将返回数据转换成JSON或XML。
    • 负载均衡: 支持有权重的round-robin负载平衡。
    • 服务发现:从Consul、Eureka等注册中心发现后端服务器。HTTP(S)反向代理:隐藏真实后端服务,支持Rest API、Webservice。
    • 多租户管理: 根据不同的访问终端或用户来判断。
    • 访问策略:支持不同策略访问不同的API、配置不同的鉴权(匿名、Apikey、Basic)等。
    • 灵活的转发规则: 支持模糊匹配请求路径,支持改写转发路径等,可为不同访问策略或集群设置不同的负载。
    • IP黑白名单。
    • 自定义插件: 允许插件挂载在常见阶段,例如before match,access和proxy。
    • CLI:使用命令行来启动、关闭和重启Goku。
    • Serverless: 在转发过程的每一个阶段,都可以添加并调用自定义的插件。
    • 请求日志(access log):仅记录转发的基本内容,自定义记录字段与排序顺序,定期自动清理日志。
    • 运行日志(system log): 提供控制台和节点的运行日志,默认仅记录ERROR等级的信息,可将等级按实际情况调成INFO、WARN或DEBUG。
    • 可扩展:简单易用的插件机制方便扩展功能。
    • 高性能: 性能在众多网关之中表现优异。
    • Open API:提供API对网关进行操作,便于集成。
    • 版本控制: 支持操作的发布和多次回滚。
    • 监控和指标:支持Prometheus、Graphite。

    具体对比:https://help.eolinker.com/

    从对比可以看到,开源版本对于关键的服务限流熔断,服务降级,数据缓存,格式转换,请求大小校验等能力是没有的,这些能力只在企业版本中提供。

    由于该网关基于Go语言编写,因此比类似Zuul网关有更好的性能,实际性能测试结果数据来看,和Kong网关的性能比较接近,比Kong网关性能略好。

    关键内容说明:

    整个部署架构图和常见的ESB总线或API网关产品类似,数据库可以采用Oracle或MySQL数据库,缓存采用Redis库进行缓存。前端通过F5或Ngnix进行负载均衡,本身网关节点是无状态的,支持集群化架构部署。

    通过定期检查后端服务器的可用情况,智能识别可用后端、屏蔽不可用后端,减少服务器开销。这个实际类似对后端的业务服务进行心跳监测,出现问题后进行屏蔽或预警,后端服务不可用时候实际通过API网关封装暴露的新代理服务本身也处于不可用状态。

    对于后端的业务服务本身可以再通过类似Ngnix集群或K8s集群暴露集群IP地址接入,当然网关本身也支持直接将多个后端业务多节点接入到网关中,由网关对后端业务服务器阶段进行负载均衡,在采用了类似容器化和K8s或集群架构的后端来说,该功能往往并不会用到。

    API健康检查,文档编写完成之后,API定期检查节点运行状态,若节点出现异常则通过邮件或者API发送告警信息,并自动尝试重启修复节点。实际我们看到对于API的监控检查包括了两个方面,一个是通过网关封装后的API节点的监控检查,一个是后端业务API服务的监控检查。

    API断线重连:请求转发失败后,网关会进行一定次数的断线重连,防止因网络闪断等原因导致API访问质量下降。这个类似我们说的服务重试机制,传统ESB总线的标准能力。该功能还是有用,主要是为了防止网络闪断引起的服务访问异常。

    在网关里可以给不同的调用方或客户端设置访问策略,不同的访问策略可以设置不同的API访问权限、鉴权方式以及插件功能等。网关支持开放策略与普通策略:

    • 开放策略:系统自带访问策略,使用开放策略时不需要传递策略ID参数;
    • 普通策略:自定义访问策略,需要传递策略ID参数。

    网关的插件分为策略插件与API插件。

    • 策略插件包括:流量控制、鉴权、IP黑白名单等。
    • API插件包括:参数映射、额外参数、熔断、服务降级等。

    鉴权的对象为策略(Strategy),策略可表示为一个公司、一个业务部门或一个用户。开源版网关支持以下鉴权方式:Public、Basic、Apikey。暂时没有看到基于消费访问IP地址的服务访问鉴权,不清楚是否企业版由对应的IP认证鉴权支持。

    日志管理能力:

    网关系统的日志分为两大部分:请求日志(access.log)和系统运行时日志;运行时日志又分为:控制台的运行日志(console.log)、各节点的运行日志(node.log)。对于请求日志可以详细的配置日志存放路径,记录周期,具体记录的内容等。

    整体相对来说,当前网关提供的日志管理能够偏弱,特别是日志信息的查看,基于服务日志运行进行的API接口服务的运行分析统计等方面的能力。

    参数映射:功能具备,但是使用起来会比较麻烦,暂时没看到图形化或者表格方式的参数映射界面。对于参数映射不一定完全的图形化,但是提供类似阿里云API网关的表格化映射是一种可行的方式。

    小豹API网关

    http://www.xbgateway.com/architecture.html

    这个是最近在网上查找API网关相关资料的时候搜索到的一个商用的API网关,从产品介绍材料来看,我们前面谈过的网关的核心功能基本上全部包括,而且相当来说也比较完善。同时提供了一个较方便的API网关的治理管控平台,可以方便的对API注册接入和运行全生命周期,方便对安全,流控,日志各方面进行灵活管控。

    下面我们看下网站对API网关架构特点的一些说明:

    • 基于Netty NIO的响应式架构;分布式缓存基于Redis;数据库基于MySQL,分布式配置基于ZooKeeper。
    • API配置缓存,运行时不依赖DB,配置更新后自动通知各网关节点;
    • 支持自定义组件,动态加载,在不中断网关服务的情况下重新加载配置和运行组件;
    • API服务连续异常后自动熔断和自我恢复,访问异常、超时处理;
    • 网关核心运行过程不写磁盘IO,避免磁盘IO性能影响网关吞吐量;
    • Docker容器化支持,拆分网关、管理服务、第三方中间件依赖等镜像,便于灵活扩容。

    RestCloud API企业微服务API开发

    http://www.restcloud.cn/restcloud/mycms/apigateway.html

    RestCloud API网关是完全自主研发的面向企业级的API网关,一且以简单、易用、轻量级为目标进行研发,同时兼顾作为企业级的服务总线可以替换企业原有的ESB产品,RestCloud是集ESB和API网关于一体的企业级网关产品。这个不仅仅提供了API网关,也提供了微服务快速开发平台,API服务治理平台,DaaS等相关组件。

    另外RestCloud本身还提供了Http Rest API接口的快速开发平台,可以将数据库表,表对象,一对多对象关系的快速的发布为Http Rest API接口服务,同时支持多数据库接口适配。

    展开全文
  • api网关rpc微服务 对于有关微服务和API网关的所有嗡嗡声,发现细节可能令人惊讶地困难。 我想起了西德尼·哈里斯(Sidney Harris)的那幅漫画,该漫画提出了一个复杂的数学公式的第一步, 然后出现了奇迹 ,光辉...
  • 关于 Service Mesh API Gateway 之间的关系,这个问题过去两年间经常被问起,社区也有不少文章资料给出解答。其中不乏 Christian Posta 这样的网红给出过深度介绍。我在这里做一个资料的整理汇总,结合个人的...
  • Rest API 设计

    2018-09-08 11:39:28
    【问题】 在以前的项目经验中,...这一系列问题,都是Restful风格中不允许出现的,所以在提供对外接口前,先学习了下,如何设计Restful风格API,从而让第三方使用我们的接口第一感觉就是专业规范。 【安全与幂...
  • WebAPI的学习简单分析

    2017-06-26 20:26:00
    Webservice(比较老) 少数在使用,还是以前的老项目WCF(.net):使用比较广,对内WebAPI对外)就是发送一个http请求,返回xml(默认的格式)与json 返回值,清晰简单解析方便所以一般对外Webapi属于mvc项目中一...
  • WebAPI

    2017-06-26 21:34:23
    Ø WebAPI对外)  就是发送一个http请求,返回xml(默认的格式)与json  返回值,清晰简单解析方便所以一般对外   Webapi属于mvc项目中一部分   Webapi对外:给android,ios提供数据 绝大多数使用webapi...
  • 函数API设计笔记

    2021-05-23 17:08:25
    为了统一检索规范 API,可以内部建立一个统一的 (如叫bapis) 仓库,整合所有对内对外 APIAPI 仓库,方便跨部门协作。 统一做版本管理,基于 git 控制。 规范化检查,API lint。 API design review,变更 dif
  • API设计原则

    千次阅读 2017-09-22 23:11:01
    Qt的设计水准在业界很有口碑,一致、易于掌握强大的API是Qt最著名的优点之一。此文既是Qt官网上的API设计指导准则,也是Qt在API设计上的实践总结。虽然Qt用的是C++,但其中设计原则思考是具有普适性的(如果
  • 大部分开源框架基本上都是使用Curl + RPC的方式构筑系统,以提供对外\对内的交互能力。 这种设计,本人认为更多地是出于层次化与模块化设计的考量,简化整个架构,使得开发轻量简单化。 本文主要介绍Compass的REST ...
  • odoo rest api 服务接口

    千次阅读 2020-05-20 22:01:55
    一、REST_API 是前后端分离最佳实践, ... 当然这种接口也可对外,权限为public ,对内权限 则为user。 odoo oca 已经为这样的接口提供了标准的 api 写法 rest-framework 此时我们则可以规则开发出自己业务所需要的
  • SpringBoot -- 服务网关APIGateway

    万次阅读 2017-01-16 11:37:53
    对外提供服务接口 对内根据逻辑调用内部多个接口,进行信息聚合返回给调用者 异步调用无需等待反馈的服务 使用场景 商品详情: 需要调用商品基础信息、推荐信息、评价、排名接口 登录+积分:调用登录、积分...
  • rest api

    2018-05-26 10:59:30
    API最终是给人使用的,无论是对内还是对外,即使遵循上面提到的所有规则,API设计的很优雅,但有时候用户还是不知道该如何使用这些提供的API。 因此,编写清晰可读的文档是很必要的事情。 而且编写文档也可以作为...
  • 输出服务、数据、工具需要通过API,移动APP后端的交互通讯需要API,系统间的深度对接需要API,智能终端跟云端服务的通讯需要APIAPI已经不只是简单的应用程序接口,API正逐渐演变成Paas云服务中的最大载体。那么...
  • API 经济与实现之路

    2018-10-16 10:27:30
    API 经济的兴起 ...本质上,API 是对应用进行封装、对外开放访问接口,以便被其他应用或者客户端访问。 随着软件的种类越来越多、功能越来越丰富,软件在设计的时候,通常要将一个复杂的大系统划分成多...
  • 企业级API网关的设计

    2018-03-06 09:21:08
    企业级API网关的设计 Table table of Contents 背景 作用 隔离 解耦 脚手架 带来的好处 企业级API网关需要具备的条件 企业环境下,API网关需要考虑哪些要素 ...
  • 本周一,小智君刚刚报道Facebook要投资1000万欧元在法国建立AI中心的消息。今天再次获悉,Facebook又宣布了一项重大决定——...对内重组AI实验室据了解,2013年创立了Facebook人工智能研究实验室(FAIR)的伊恩·勒坤
  • API网关

    2019-07-24 14:33:27
    在当前的系统架构中,微服务架构大行其道,在微服务架构中一个很重要的组件就是API网关。 API网关是一个服务器,是系统的唯一入口。从面向对象设计的角度看,它与外观模式类似。API网关封装了系统内部架构,为每个...
  • 关于Service Mesh和API Gateway之间的关系,这个问题过去两年间经常被问起,社区也有不少文章资料给出解答。其中不乏 Christian Posta 这样的网红给出过深...
  • Kube-ApiServer是etcd的唯一访问操作入口,ApiServer对外和对内都提供了一套统一的REST API,用户可以通过kubeclt命令请求ApiServer进行操作,而Kubernetes内部组件都是通过一种watch机制去监控API Server中的资源...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 4,075
精华内容 1,630
关键字:

对外api和对内api