api网关架构图（api网关和服务网关）

本文目录一览：

• 1、微服务入门｜微服务架构怎么设计

• 2、关于API网关（四）——限流

• 3、为什么需要api网关

微服务入门｜微服务架构怎么设计

将一个单体应用拆分成一组微小的服务组件，每个微小的服务组件运行在自己的进程上，组件之间通过如RESTful API这样的轻量级机制进行交互，这些服务以业务能力为核心，用自动化部署机制独立部署，另外，这些服务可以用不同的语言进行研发，用不同技术来存储数据 。

通过以上的定义描述，我们可以基本确定给出微服务的节特征：

用微服务来进行实践到生产项目中，首先要考虑一些问题。比如下图的微服务业务架构：

在上图图表展示的架构图中，我们假设将业务商户服务A、订单服务B和产品服务C分别拆分为一个微服务应用，单独进行部署。此时，我们面临很多要可能出现的问题要解决，比如：

1、客户端如何访问这些服务？

2、每个服务之间如何进行通信？

3、多个微服务，应如何实现？

4、如果服务出现异常宕机，该如何解决？

以上这些都是问题，需要一个个解决。

在单体应用开发中，所有的服务都是本地的，前端UI界面，移动端APP程序可以直接访问后端服务器程序。

现在按功能拆分成独立的服务，跑在独立的进程中。如下图所示：

此时，后台有N个服务，前台就需要记住管理N个服务，一个服务 下线 、 更新 、 升级 ，前台和移动端APP就要重新部署或者重新发包，这明显不服务我们拆分的理念。尤其是对当下业务需求的飞速发展，业务的变更是非常频繁的。

除了访问管理出现困难以外，N个小服务的调用也是一个不小的网络开销。另外，一般微服务在系统内部，通常是无状态的，而我们的用户在进行业务操作时，往往是跨业务模块进行操作，且需要是有状态的，在此时的这个系统架构中，也无法解决这个问题。传统的用来解决用户登录信息和权限管理通常有一个统一的地方维护管理（OAuth），我们称之为授权管理。

基于以上列出的问题，我们采用一种叫做网关（英文为API Gateway）的技术方案来解决这些问题，网关的作用主要包括：

网关(API Gateway)可以有很多广义的实现办法，可以是一个软硬一体的盒子，也可以是一个简单的MVC框架，甚至是一个Node.js的服务端。他们最重要的作用是为前台（通常是移动应用）提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，不过API Gateway也有可能成为 单点故障 点或者性能的瓶颈。

最终，添加了网关(API Gateway)的业务架构图变更为如下所示：

所有的微服务都是独立部署，运行在自己的进程容器中，所以微服务与微服务之间的通信就是IPC（Inter Process Communication），翻译为进程间通信。进程间通信的方案已经比较成熟了，现在最常见的有两大类： 同步调用、异步消息调用 。

同步调用

同步调用比较简单，一致性强，但是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。同步调用的有两种实现方式：分别是 REST 和 RPC

基于REST和RPC的特点，我们通常采用的原则为： 向系统外部暴露采用REST，向系统内部暴露调用采用RPC方式。

异步消息的方式在分布式系统中有特别广泛的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能保证调用方的服务体验，继续干自己该干的活，不至于被后台性能拖慢。需要付出的代价是一致性的减弱，需要接受数据 最终一致性 ，所谓的最终一致性就是只可能不会立刻同步完成，会有延时，但是最终会完成数据同步；还有就是后台服务一般要实现 幂等性 ，因为消息发送由于性能的考虑一般会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）。最后就是必须引入一个独立的 Broker，作为中间代理池。

常见的异步消息调用的框架有：Kafaka、Notify、MessageQueue。

最终，大部分的服务间的调用架构实现如下所示：

在微服务架构中，一般每一个服务都是有多个拷贝，来做负载均衡。一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。这就出现了新的问题：

这就是服务的发现、识别与管理问题。解决多服务之间的识别，发现的问题一般是通过注册的方式来进行。

具体来说：当服务上线时，服务提供者将自己的服务注册信息注册到某个专门的框架中，并通过心跳维持长链接，实时更新链接信息。服务调用者通过服务管理框架进行寻址，根据特定的算法，找到对应的服务，或者将服务的注册信息缓存到本地，这样提高性能。当服务下线时，服务管理框架会发送服务下线的通知给其他服务。

常见的服务管理框架有：Zookeeper等框架。

如上的问题解决方案有两种具体的实现，分别是： 基于客户端的服务注册与发现 、 基于服务端的服务注册与发现 。

优点是架构简单，扩展灵活，只对服务注册器依赖。缺点是客户端要维护所有调用服务的地址，有技术难度，一般大公司都有成熟的内部框架支持。

优点是所有服务对于前台调用方透明，一般小公司在云服务上部署的应用采用的比较多。

前面提到，单体应用开发中一个很大的风险是，把所有鸡蛋放在一个篮子里，一荣俱荣，一损俱损。而分布式最大的特性就是网络是不可靠的。通过微服务拆分能降低这个风险，不过如果没有特别的保障，结局肯定是噩梦。

因此，当我们的系统是由一系列的服务调用链组成的时候，我们必须确保任一环节出问题都不至于影响整体链路。相应的手段有很多，比如说：

关于API网关（四）——限流

通俗的说，流量控制就是控制用户请求的策略，主要包括：权限、限流、流量调度。

权限上一篇已经讲过了，这一篇讲限流，下一篇讲流量调度。

限流是指限制用户调用的频率（QPS/QPM）或者次数。

流量限制，站在用户或者运营的角度看，最直观能感受到的作用是——收费

各大主流开放平台的对外API，一般都有一些免费的额度，可以供个人测试用，一旦想大规模调用，就需要付费购买更大的额度（频率、次数），根据调用次数或者频率进行收费。一旦超过拥有的额度，就会被限制调用。

其实这才是限流最大的用处，只是用户或者运营同学无感，所以不太被大多数人了解。

网关后面是各个服务，各个服务的接口通过网关透出去给用户调用。理论上说，用户的流量是不可预知的，随时可能来一波，一旦流量的峰值超过了服务的承载能力，服务就挂了，比如有大新闻发生时的某浪微博，比如前些年的12306.

所以， 网关必须保证，放过去到达后端服务的流量一定不可以超过服务可以承载的上限 。这个上限，是网关和各个服务协商出来的。

由简到难，限流可以 分为单机限流、单集群限流、全集群限流 。

这里不讨论具体的如漏桶、令牌桶等限流算法，只说概念和思想。

单机限流的思想很简单，就是每个机器的限流值 x 机器数量 = 总的限流值。

举个例子，A用户的QPS限制是100，网关部署了10台机器，那么，每台机器限制10QPS就可以了。

先说好处，这种方法实现起来非常简单，每台机器在本地内存计算qps就可以了，超过阈值就拒流。

不过单机限流的缺陷也十分明显，主要体现在两点：

   当网关部署的机器数量发生变化时，每台机器的限流值需要根据机器数调整。现实中，因为扩容、缩容、机器宕机等原因，机器数的变化是常有的事。

   单机限流的前提是，每台网关承载的用户的流量是平均的，但是事实上，在某些时间，用户的流量并不是完全平均分布在每台机器上的。

举个例子：

10台机器，每台限qps10，其中3台每台实际qps是15，因为超限导致用户流量被拒。其余7台每台qps是7。这样用户总的qps = 15 * 3 + 7 * 7 = 94. 用户qps并没有超限，但是却有一部分流量被拒了，这样就很有问题。

实际上，单台限流的阈值也会设置的稍微大一些，以抵消流量不均的问题。

因为上面的问题， 单机限流通常作为一种兜底的备用手段，大多数时候用的还是集群限流 。

先来看一个示意图：

相比单机限流，集群限流的计数工作上移到redis集群内进行，解决了单机限流的缺陷。

但是集群限流也不是完美的，因为引入了redis，那么，当网关和redis之间的网络抖动、redis本身故障时，集群限流就失效了，这时候，还是得依靠单机限流进行兜底。

也就是说， 集群限流 + 单机限流配合，才是一个比稳妥的方案 。

接下来我们来思考这样一个问题：大型网关一般都是多机房、多地域部署的，当然，后端的服务也是多机房、多地域部署的，在保护服务这一点来说，集群限流是够用了。但是对用户来说，还是有一些问题：

比如，用户购买的QPS上限是30，我们的网关部署在中国北、中、南三个地域，那么这30QPS怎么分配呢？

平均肯定不行，用户的流量可能是明显不均衡的，比如用户的业务主要集中在中国北方，那么用户的流量大部分都会进入北方的网关，网关如果限制QPS为10的话，用户肯定来投诉。

那每个地域都限制为30行不行？也不行，如果用户的流量比较均匀的分布在各个地域，那么用户购买了30QPS，实际上可能使用了90QPS，这太亏了。

按照解决单机限流流量不均的思路，搞一个公共的redis集群来计数行不行？

也不行，受限于信号传播速度和天朝的广阔疆域，每个流量都计数，肯定不现实，rt太高会导致限流失去意义，带宽成本也会变得极其昂贵，对redis的规格要求也会很高。总之，很贵还解决不了问题。

有一种巧妙的解决办法是：本地集群阶梯计数 + 全集群检查。

还是刚才的例子：

限流阈值时90，那么三个地域各自计数，当本地域的数值达到30时，去其他两个地域取一次对方当前的计数值，三个地域的计数值加起来，如果超了，告诉另外两个地域超了，开始拒流。如果没超，本地QPS每上涨10，重复一次上述的动作。

这样就能有效的减少与redis的交互次数，同时实现了全地域真·集群限流。

当然，这种全地域集群限流，因为rt和阶梯计数间隔的存在，一定是不准的，但是，比单集群限流还是好很多。

当某个用户流量特别大的时候，redis计数就会遇到典型的热点key问题，导致redis集群单节点压力过大， 有两种办法可以解决这个问题：打散和抽样。

打散是指，把热点key加一些后缀，使其变成多个key，从而hash到不通的redis节点上，均摊压力。

比如热点key是abcd，那么打散后，key变成了abcd1、abcd2、abcd3、abcd4。技术时，轮流加1、2、3、4的后缀就可以了。

抽样是指，针对热点key，不是每个每个请求到来时都进行计数，而是进行一个抽样，比如每10个请求记一次数，这样redis的压力就会降低到十分之一。

说着把流量调度的也说完了哈哈，那下一篇再说说监控好了，顺便推一下我现在在用的国产网关：GOKU，来自Eolinker。我觉得比KONG好用，感兴趣的同学可以自行去了解一下。

为什么需要api网关

API网关跨一个或多个内部API提供单个统一的API入口点。 通常还包括限制访问速率限制和有关安全性等特点。 诸如Tyk.io的API管理层增加了额外的功能，例如分析，货币化和生命周期管理。

基于微服务的架构可以具有10到100个或更多个服务。 API网关可以为外部消费者提供统一的入口点，而与内部微服务的数量和组成无关。

API网关对于微服务的好处：

1、防止内部关注暴露给外部客户端

API网关将外部公共API与内部微服务API分开，允许添加微服务和更改边界。 其结果是能够在不对外部绑定客户端产生负面影响的情况下重构和适当大小的微服务。 它还通过为您的所有微服务提供单一入口点，对客户端隐藏了服务发现和版本控制详细信息。

2、为您的微服务添加额外的安全层

API网关通过提供一个额外的保护层来防止恶意攻击，例如SQL注入，XML解析器漏洞和拒绝服务（DoS）攻击。

3、支持混合通信协议

虽然面向外部的API通常提供基于HTTP或REST的API，但是内部微服务可以从使用不同的通信协议中受益。 协议可能包括的Protobuf或AMQP ，或者用SOAP，JSON-RPC或XML-RPC系统集成。 API网关可以在这些不同的协议之上提供外部的，统一的基于REST的API，允许团队选择最适合内部架构的API。

4、降低微服务复杂性

如果微服务具有共同的关注点，例如使用API令牌的授权，访问控制实施和速率限制。 每个这些关注可以通过要求每个服务都实现它们，但这为微服务的开发增加更多的时间成本。 API网关将从您的代码中删除这些问题，允许您的微服务关注手头的任务。

5、微服务模拟和虚拟化

通过将微服务API与外部API分离，您可以模拟或虚拟化服务，以验证设计要求或协助集成测试。

API网关的服务对象

API网关可以为Web端、APP提供API访问，也可以给物联网设备提供API接口。另外致力于开发生态的企业还会为一些合作伙伴提供API网关，供其调用通用的微服务。对于可以提供数据或算法服务的企业，可以在云市场的API网关注册自己的API，从而对外提供服务。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。