什么是 API Everything？
先简略介绍一下 API，便是适当于前端比方 Web 拜访到后端的服务接口，这中心有一个阻隔，适配给外部各端进行拜访，阻隔是起到安全性的考虑，还有一个协议转化的考虑。
当然，依据这一块咱们还有许多其他的考虑。在饿了么初期开展阶段，咱们的许多 Web API 层都是手写的，即大都运用服务后端，都自己写 Web API，独自布置，供给给前端 HTTP API 调用。
其时事务高速开展，为了快速应对，有一些事务逻辑会放在 Web API 层，甚至在 Web API 层也会拜访数据库，进行数据库操作。
在 API 层直接拜访数据库会导致安全性的一些问题，这个是不允许的。前端拜访后端，这个 HTTP API 接口是什么风格？
有 Restful ，还有 JSON-RPC ，需求共同考虑，否则对前端开发的体会不共同。
别的 HTTP API 文档存在过期，不能反映代码完结的改变，比方代码改了，文档没有改。
终究，前端同学和后端同学一同开发，但开发的节奏或许不太相同。比方前端在进行开发，但后端或许会被刺进愈加紧迫的项目，就不能及时完结当时项目的 API。
这样或许会延误前端的开发，发生前后端开发不同步，导致前端资源和后端资源有个彼此等候，会导致开发体会的不顺利，功率也不高。
需求调研-API Everything
依据这些状况，公司考虑是否能够共同构成一个 API 结构，所以咱们调研了各个部门，发现他们都有这个需求，期望有一个共同的 API 结构开发，现在也有一些独立写的 Web API 层。
如下图，是调研的一些需求：
从图中，咱们能看到一个很重要的功用便是 HTTP 到 SOA 的服务映射，还有认证与鉴权，比方公司的 SSO，包含用户、饿了么的一些鉴权，API 布置与运转。
API Orchestrati
on，
这个适当所以 API 的拼接和取舍的概念，能够调用多个 API，取各个 API 回来成果的一部分，从头组合成新的成果，回来给前端。
这个运用在一个前端 API 调用，能够实践调用多个后端 API，拼装一个回来成果给前端，削减前端调用后端屡次，进步前端用户的体会。
别的，由于后端现已有了许多根底服务的接口，新事务开发不需求后端再供给接口，只需求在这些接口上进行组合、裁剪就能够了。
此外还有 API 文档、API 测验、Mock API、限流、反爬（便是说接口露出在公网，存在爬虫爬取这些接口的状况，咱们怎样维护接口等等）以及灰度。
产品技能计划准则
调研出来今后，需求考虑以什么准则去考虑产品和体系规划。
API Everything 是一个根底结构，咱们首要考虑到根底结构的安稳性是第一位。
哪怕你不能满意一切功用需求，但你很安稳，接入 API Everything 结构的各个运用体系就不会歇菜，不会出问题，服务才干在安稳的根底上提高，才有或许增加新的功用和特性，也便是说安稳名列前茅。
然后是功用，
包含吞吐量（呼应速度）、功用高了，就会节约硬件资源；高可用性，防止呈现单点故障。
还有容错性，对外各种依靠，要考虑外部依靠歇菜怎样办，怎样降级。
还有，API Everything 接了后端的运用体系，外部流量进来，不能冲击到后端运用体系。怎样让这个体系更强健，怎样维护自己，怎样维护接入的运用体系等等。
其次，在这个根底之上考虑 DevOps 怎样弄，供给接入方自助 DevOps，还有各种方针检查、监控告警、排错手法、检查 log/trace/exception、自助扩容等。
终究期望这一块做到对接入方是通明的，能够主动扩容。API Everything 结构引起的问题，由咱们处理，接入运用方呈现的问题，由接入方处理，要有十分明晰的鸿沟界定。
一般问题能够主动处理，现场日志主动保存，尽或许自愈，而且接入方知道发生了什么状况。
别的，怎样让咱们的研制或许运用开发端更“懒”？便是把常常要做的工作主动化。
比方接入一个运用方，要进行各种装备，比较繁琐也简略犯错，那咱们是不是能够进行主动化接入、主动化装备呢？
方才也谈到代码和文档不同步怎样办，所以咱们不写文档，在代码里边写文档。
比方：在 Java 代码里写 Java doc 注释，咱们就把这些注释抽出来，作为 API 文档的一部分；别的，咱们也供给一些标示，协助完结文档。
用户体会
也是考虑的一大要素，由于技能产品基本上由工程师直接进行开发，寻求完结功用，大都没有考虑用户体会，导致用起来操作别扭。
所以在这方面要充沛吸取教训，把运用者的体会考虑起来，能点一下就不必点两下，不能把技能杂乱性露出给用户去了解、去操作，让用户用起来很爽，简略不去操作是一个方针。
这个结构涉及到许多装备，散放在不同体系，咱们的主意是在一个装备里边全把它搞定，不要让用户了解这个是 API Everything 结构的哪一部分办理的，要到哪个体系去操作。
别的便是满意不同的功用需求，比方接入不同的协议等，这是咱们对整个产品计划在准则上的一些考虑。
生命周期
从 API 这边动身，能够看到 API 的生命周期是从 API 开发开端的，这个进程中会有文档、Mock，开发完了是办理，也便是授权谁能拜访，有些是不是能够灰度。
API 办理之后是 API 网关服务，便是运转态服务，对 API 进行协议转化，比方将 HTTP 协议转化成 SOA，调用后台的 SOA 服务，终究进入 API 运维，便是对 API 进行监控办理和布置扩容。
产品规划
依据产品体系规划准则，结合 API 的生命周期，咱们规划了下面几个产品，如下图：
比方说开发支撑这一块，便是 API Portal，运转支撑这块便是 Stargate Cluster。
还有质量确保，便是 API Robot，经过主动化回归测验来确保 API 的质量。
别的要考虑到在开发的进程中，怎样让前后端同步，这儿边很重要的一点是怎样样 Mock API 的数据，让前后端别离开发？这就发生了 Mock Server，所以依据规划构成了这四个产品。
但这四个产品之间是什么样的联系呢？
这儿从体系上的交互来考虑。
如上图，咱们从底下看，前端的运用（比方抵达圈前端），经过 HTTP 拜访，抵达 Nginx Cluster，然后转向 SOA 服务。
灰色的途径便是抵达圈办理后台运用，灰色再上去就抵达圈服务，别的还有赤色这条途径，前端 URL 能够经过参加 query string 拜访 Mock Server。
Stargate Cluster 收到这个 querystring，就不会发给后端 SOA 服务，会路由到指定的 Mock Server。前端会经过 Mock 的办法完结前端的开发。
API Portal 担任 API 文档这块，文档对应的是布置到哪个环境，在 API Portal 里有显现。
在饿了么有如下几个环境：
-
开发的 Alpha 测验环境，
这个是供给给开发运用的。 -
Beta 环境，
这个是供给给测验来验证是否能够上线的环境，只要经过了 Beta 测验，才干上线。
这个 Beta 环境也用来和其他团队进行联调。 -
Prod 环境，
用于线上出产。在 API Portal 上就能知道当时布置的运用、对外供给的 API 文档详细是什么。这是 API Portal 经过拜访 Stargate Cluster 布置信息取得的。
API Robot 从 API Portal 中获取 API 界说，经过界说发测验恳求给 Stargate Cluster。
饿了么内部服务是 SOA 架构，服务间有彼此依靠的状况，需求进行测验、联调。
有时分发现咱们 SOA 服务依靠对方 SOA 服务，对方还没有开发完结，咱们想测验自己开发 的 SOA 服务怎样办？
这时咱们就能够用 Mock Server，Mock 对方的 SOA 服务，写一下 Mock Case，完结咱们自己的开发测验。
方才说代码即文档，所以或许要标准一下怎样写代码，注释和标示写完了，就能够主动化从这些注释和标示中抽出文档，构成 API 文档。
Web API 这一块不需求手艺写，现在咱们主动生成对应 Web API 的代码，然后主动再布置。
布置便是监听 SOA 服务布置音讯，收到了布置音讯，就主动生成的 Web API 代码而且主动布置。
而 Mock，咱们也是主动生成的，创立 Mock Case 的时分，就主动生成相应的数据，这些数据能够自己改。还有 API 的监控告警，每个运用接入，主动进行全链路监控。
Stargate Cluster 技能架构
如上图，这是其间一个产品 Stargate Cluster 的技能架构。
从上面看，ELESS 是咱们构建体系，咱们会监听它的构建音讯，当有构建过来的时分，调用 base.stargate_core 服务。
该服务完结十分简略，便是把 Stargate Cluster 需求的信息保存到 MaxQ 里边，MaxQ 是饿了么自己开发的一个 MQ 产品，现在在许多运用。
终究 Stargate Cluster 运营办理服务是从 MaxQ 取音讯进行处理。
为什么会有这样的考虑？
由于之前咱们在 Stargate Cluster 运营办理服务里常常有迭代开发，常常增加一些功用（比方异地多活），这些功用不断地迭代、增加，需求常常布置，处于一个不太安稳的状况。
咱们想任何这种构建和布置音讯不能丢，所以就有了 stargate_core 这个服务，这个服务十分简略，不进行功用上的迭代，坚持不变，这样就比较牢靠，效果便是把构建和布置音讯放在 MaxQ 里头。
而 stargate 运营办理不断开发、然后重启，这个进程中至少 MaxQ 里的数据不会丢，重启完了也能够消费，继续进行布置。咱们是依据改变和不改变的阻隔去考虑体系牢靠性的成果。
Stargate Cluster 依据 Docker 布置
谈谈为什么能主动布置？
其实挺有意思的，咱们这边用的是 Docker 环境。
从底下开端看，能够看到，比方 SOA 服务布置了，经过 ELESS(饿了么发布体系 ），咱们取得布置音讯，放到 MaxQ 里。
然后咱们从 MaxQ 拿出音讯，调用 AppOS（饿了么自研的 Docker 渠道），发动相应的 Docker 实例。
实例上运转着这个 SOA 服务对应的 Web API 代码，Docker 实例发动时，调用 Navigator（饿了么自研的 Nginx 办理渠道），将该 Docker 实例的 IP 注册到 Nginx 上，这样外部流量就打到这些 Docker 上了。
在新 Docker 成功发动之后，Stargate Cluster 就会调用 AppOS 将之前版别的 Docker 实例给销销毁，经过 Navigator 将对应在 Nginx 上的 IP 也删除去，这便是完结主动布置。
这是咱们主动布置的一些信息，从图中能够看到左上角基本上是 SOA 服务布置的 Push Seq，下面是 PushSeq Used by Client。
这两个 Push Seq 共同，就阐明 SOA 服务布置时，Stargate Cluster 将其对应的 Web API 端也主动布置了，两头用的版别(Push Seq)是共同的。一同，包含布置的一些版别信息咱们也都会保存下来。
API Portal – 主动化文档
讲完 Stargate Cluster，咱们再来看看 API Portal 这一块。
API Portal 在体系布置时，获取布置的源文件，主动解析这些代码，然后依据代码里边的注释和标示主动生成 API 文档，这个文档以 Swagger 办法存储。
刚开端咱们以 Swagger 的原生界面去展现这个界面，前端开发不太习气这个界面，所以咱们就用前端喜爱的，即作为各种表格进行展现来给他们运用。上面的表格展现办法，便是由于这个开发出来的。
那 Swagger 原生的界面还需求吗？
API Portal 上有一个功用， Try it Out(便是试一试），详细便是后端开发选用这个功用看看后端 API 吐的数据长得怎样样，不对就修正后端 API，直到满意停止。
前端也运用这个功用，看看没有实践数据又是怎样样的。Try it Out 功用就选用了 Swagger 原生的界面，后端反而比较喜爱这个页面，因而保存下来。
这样前后端的用户体会，也都能满意，咱们各取所需。
下面是一个 Swagger 文档界面：
Mock Server 流程
Mock Server 是什么？
看看图中这个场景，SOA Client 要对 Service Provider 进行测验。
Service Provider （便是被测验的目标 Server Under Test ）依靠外部的服务，比方 Server Cluster 1，可是外部的服务由于其他状况不能用，咱们就用 Mock Server 来模仿 Server Cluster 1。
这样依靠问题处理了，SOA Client 对 Service Provider 就能正常进行测验了。
运用 Mock Server 还能够处理，依靠服务需求回来特定的场景，但又欠好操作，这样经过 Mock Server，写不同的 Mock Case 进行回来，就比较便利。
实践状况下 SOA 环境里边有许多依靠联系，但对方的接口没有承认或许环境欠好怎样办？
咱们经过 Mock Server 把这些服务悉数屏蔽掉，这样只需求测验咱们要测验的服务就好，这对 SOA 环境处理依靠问题是挺有用的。
Mock Server—主动解析
饿了么有 Maven 私服，各个 SOA 服务之间经过 Maven 私服上的 API 进行调用。
上图是咱们的 Mock Server 界面，从图中能够看到左面是输入依靠服务的接口 Maven 依靠，基本上操作便是连续之前 SOA 调用的一些流程，把外部依靠填到上面的框里头，在 Mock Server 指定依靠的接口。
所以 Mock Server 就能从 Maven 私服去拉这些依靠，主动剖析它到底有哪些类，剖析好这个类，包含这个类里边有哪些办法都悉数显现出来。
上图右边的办法便是主动剖析，黄色标识的那个办法，便是想进行 Mock，点击下右边的加号，就创立了 Mock Case。这个 Mock Case 姓名便是测验恣意参数。
主动生成 Mock Case
Mock Case 是说当 Mock Server 接纳的数据，即恳求的参数和 Mock Case 里设定的 Input 匹配，那么这个 Mock Case 里设定的 Output 就作为呼应回来。
方才创立了一个 Mock Case 叫做测验恣意参数， Mock Case 的值是依据剖析的 Model（数据界说），主动生成。
比方 Input "type" : Integer，咱们没有参加 enum[234567] 的时分，就意味着只要是恳求里包含任何整数，该 Mock Case 就会被射中，回来 Output 的内容。
假设参加了 enum [234567]，那么只要恳求参数里是 234567，该 Mock Case 才会射中。
Output 支撑函数，上面 Preview 就能够看到履行 Output 的表达式之后是什么成果，当该 Mock Case 被射中时，这个 Preview 的成果就作为呼应回来。
前后端开发别离
后端开发依据 PRD，经过在代码接口里增加标示和注释，就完结了 API 界说。
把代码 check in，构建体系知道这个改变后，然后把这个改变告知到 API Portal，就主动生成了 API 文档，后端在 API Portal 上告知前端，两边经过API Portal 评论承认 API 文档。
前端依据这个文档，经过 API Portal 上供给的 Mock，完结前端的开发，更杂乱的交互需求结构后端 API 发生不同的数据。
前端经过结构不同的 Mock Case，完结这些杂乱的开发。开发完结之后，就去进行其他工作，在后端完结 API 开发之后，告知前端一同进行联调。
在曾经，前后端不别离的话就会彼此等候，前端开发等后端完结 API，吐出数据之后再进行，对前端开发体会欠好，现在这样前端就能够趁热打铁把它开发完结，不必等候后端了。
现在，后端这边也开发完了，说一个时刻咱们联调一下就 OK 了，这便是整个前后端开发别离的流程。
运用实践
这个流程在咱们配送规模的项目里现已运用起来了，这儿咱们给出了一个迭代的计算，这个迭代能够在开发的进程中就看到运用的状况。
比方本来估量工时 5 天，现在 3 天就做完了，后端也节约一些时刻，曾经他们说，否则就等前端调用后告知他们什么姿态，或许他自己写一些测验脚本去看是什么样的数据。
这方面他就写了 API，经过 API Portal 就能看到后端 API 吐的数据是否正确，这样的话后端开发也削减了开发时刻。
还有，后端曾经要写 Web API 代码，还要进行布置，现在也不必写了，也不必布置了。
曾经联调时刻都比较长，是两天时刻，由于那时联调是包含开发时刻，他不确定数据对不对。
所以有些处理还没有写，等他看到数据今后再去开发出来，时刻就略微长一些。
联调的时刻，只需半个小时，看这个工作通不通就好了，整个开发体会仍是不错的，整体来看，整个开发时刻削减了 50% 左右。
问题真的处理了吗？
有了这些产品，咱们看最早说到的那些问题是不是都处理了。假设今日写事务，咱们是经过共同的办法介入，把它下沉到 SOA，因而事务也不会涣散到各个地方。
本文来自网络，不代表快递资讯网立场。转载请注明出处： http://www.llaiot.com/express-headline/1797.html
