基于API 网关的微服务治理方案

基于API 网关的微服务治理方案

微服务治理当前面临的问题

1. 常用方案的不足

2. 服务网格（Service Mesh）的不成熟

3. 微服务治理的复杂性

微服务架构一定程度上是为了解决伸缩性问题、运行效率问题和开发效率问题。

单体应用功能是集中式的，难以满足伸缩性、也就是扩展要求。微服务是分布式的，伸缩性是其最重要价值所在；

单体应用随着功能的累积，越来越难以更新和维护，而微服务专注于只提供一种功能，可以横向和纵向两个维度伸缩，开发简单，开发速度也会大幅提升，与其他微服务共同编排组成一个或多各业务应用系统，形成微服务生态系统；

单体应用包含了所有的功能，这些功能往往是紧耦合的，缺乏弹性，运行效率往往也不高，微服务则独立自治而轻量，运行简单而快捷。把一个单体应用拆分为微服务往往是处于伸缩性和效率方面的考虑。每个微服务的效率提升带来整个业务应用的效率提升。但随着微服务量的增加，比如何管理好这些微服务并使其高效则并不容易。

另外其弹性伸缩要求非常适合容器云平台的弹性伸缩特性，因此往往和容器平台结合，部署于容器云平台，这也更增加了微服务治理的难度，涉及的东西越多，复杂性越大，需要考虑如何更好的利用容器平台的优点来简化复杂性。

以微服务架构实现的业务应用，通常是分布式的，有众多的微服务组件，彼此有依赖性。一个微服务简单，但有众多的微服务相互关联就复杂化了，每个业务应用可能有多个服务编排而成，每个服务又可能部署不同数量的服务实例。单体应用不存在的微服务治理问题也由于微服务生态系统中众多的微服务和微服务实例，以及承载微服务的基础设施容器云平台，随着微服务量的增加而使其运营和运维复杂化，使微服务治理复杂化。

4. 敏捷性需求

引入任何一个产品或者一种技术或者一种方法，目的都是为了快速的解决面临的问题，也就是要求敏捷性。新产品新技术新方法如果无法作到敏捷，也就失去了采用其的重要价值。采用微服务一个重要的原因也效率问题。在应用微服务提高开发效率和运行效率的同时，不能带来服务治理等的复杂化。虽然微服务分布式架构和部署于容器云平台增加了运维的复杂性，复杂性同时带来了风险，但复杂性并非我们设计的初衷，风险更不是我们想要的。化繁为简、简化运维、控制风险、提高效率、实现敏捷是基础的要求。 常用的开发框架都是半成品，需要很多的工作量，如果能实现通过规则或策略配置就可以实现微服务的大部分治理能力，比用SpringCloud等去实现要敏捷的多。微服务实现关注的应是业务逻辑，不应该去关注服务治理的问题。所有非业务逻辑的功能尽可能的交给服务治理层来实现，这样才能具有敏捷性。所谓术业有专攻，做到因为专业，所以敏捷！

5. 安全挑战

速度和敏捷不应该损害安全性，任何时候安全都是第一位的。安全也是微服务可用性的一个重要指标。如果客户端直接以非安全和非管理的方式连接和调用实现的后端微服务，那是存在严重的安全隐患的。要访问这些后端的微服务需要以受管理的方式访问，不能无序，需要保证安全。 微服务生态系统拥有众多的组件微服务，这些组件服务相互依存，微服务与微服务生态就像一个人之于人类社会，接触面越大、关系网越复杂、接触量越多，安全挑战就越大。

要保证安全，就像人类一样筑座城池，把自己保护起来。但完全保护起来不跟外面接触也不行，需要开个城门，建个关口，实现对外交流。每个城池就是一个微服务，城门就是API，在城门口实现进出安全检查、管控，就类似于我们说的微服务API网关。一个国家可能有很多座城池，是一个小生态，要保护整个国家可能需要建立起一条长城，对外交流也是开个关口，这就实现了统一的微服务安全管控。多个国家形成一个大生态，就是整个微服务生态系统，通过API网关来实现安全管控。

6. 服务接口标准化要求

7. 扩展性、负载均衡、路由、限流等需求

成功的可伸缩微服务生态系统需要完善且稳定的基础设施的支撑。微服务的弹性扩展性通常是基于完善的容器云平台基础设施服务。弹性并不是我们说起来这么简单。微服务的弹性依赖于基础资源的弹性，依赖于资源调度的能力，依赖于服务伸缩的策略等。微服务的弹性伸缩可以基于容器平台的弹性伸缩能力，但伸缩策略并不是固定的，不同场景需要配置不同的伸缩策略，特别是在收缩时，需要保证业务请求已经被处理完成且不会有新的业务请求到来。这就需要靠负载均衡路由策略等实现。每个微服务对于不同的用户可能会采用不同的服务策略，提供不同的业务流量，这面临这限流限额等需求。另外在微服务出现异常情况下，能实现异常迁移、错误修复、容错等，或者达到某种熔断阀值暂停服务。 这些能力固然可以在容器云平台上和其他工具集成来实现，但会使整个平台运维复杂化。复杂化不是我们设计的初衷，所以需要换个思路。

微服务治理思路

SpringCloud等微服务治理涉及众多的组件需要自己开发搭建，这是一个挺大的工作量。为每个微服务都实现一个API网关，来对外提供统一的接口，实现注册、转换、路由、限流、负载均衡等能力又使API网关职责过重，使微服务生态复杂化。如果把每个微服务的这些非业务逻辑能力要求都提取出来，放在一个公用的API网关上去实现，使每个微服务专注于其业务逻辑的开发，就会简化开发，提升敏捷性。公用的统一的API网关上实现微服务的注册、转换、路由、流控等，映射为一个标准的API对外提供服务。这样既满足了微服务开发敏捷性的要求，也是简化微服务治理的需求。微服务所有的安全认证、访问控制等从微服务本身剥离出来，通过统一的API网关组件定义策略配置来实现微服务的安全管控和服务治理能力。

我们希望微服务不会随着量的增加而带来运维和治理的复杂性，也希望能快捷的接入不同协议不同格式不同类型的微服务业务应用和业务服务，这就可能需要一个统一的层次来完成这些能力，而不用每个微服务都实现一个sidecar Gateway；也可以容易的使用新技术替代旧技术。这就是统一的API网关服务。如果我们满足了这些要求，微服务架构将会带来敏捷、可靠和高可用，提升效率，并减少风险。

API网关

实施微服务可能不可或缺的一个很重要的组件就是服务网关。网关，顾名思义，网络关口，担负着安全检查、认证授权、路由分发、流量控制、熔断保护等重要的职责。API网关，那就是API的网络关口、通道，是整个微服务平台的咽喉，API请求应答必经之路。为了利用容器云弹性伸缩等特性，结合微服务的优点，部署微服务于容器云平台，则API网关的实施部署则会显得更复杂些。 API网关（API Gateway）是一个服务器，是调用服务的唯一节点和请求应答出入口。API Gateway封装内部系统的架构，并且提供API给各个客户端。通常情况下它还需要实现其他功能，如认证授权、访问控制、路由、负载均衡、缓存、日志、限流限额、转换、映射、过滤、熔断、注册、服务编排、API管理、监控、统计分析等等。 从API网关的能力来看，我们可以理解其重要性。一夫当关，万夫莫开。其不但是整个服务系统的安全屏障，也承担着很多服务治理的能力。所以实现或者选择一个好的API网关，是建设容器云和微服务体系中一个至关重要的事项。这也决定了API网关的部署，要尽可能的减少接触面。 微服务对外可以提供统一的接口API，可以在API网关层通过对API的治理实现对微服务的治理。

API网关在微服务治理中的价值

很多人对于微服务API网关也都有比较深入的介绍。一个重要的原因是微服务通信、微服务重构、协议转换等的需要，API网关还可以提供更多能力实现微服务治理。

1. API网关提供了一个稳定可重用接口层

API网关首先隔离了内部和外部服务，所有外部服务通过API网关所暴露的标准API访问内部服务，提供了相对稳定的API接口，隐藏了服务的内部实现细节，保障后台服务的安全性。 这方面有众多的应用场景： （1）. 一个服务可以在API网关映射为不同的API接口，相当于提供了多种的服务能力。也就是提供了接口便利的重用能力。 一个后台服务通过API网关可以映射为多个不同的API接口，以满足不同的客户端调用需求，比如有个服务实现了按照业务类型查询业务数据，可能某个客户就是特定的业务类型，在API网关就可以映射一个API，使用固定的业务类型值，服务于特定用户。

不同API可以满足不同SLA需求，节约后端开发成本。 （2）.只要API不变，对应的服务只要是兼容性的更新，都不影响客户端对该API的调用，提供了接口的稳定性。

（4）.隔离内部和外部服务，隐藏了服务实现细节。业务应用只需要关注API，不管API对应的服务是什么，由谁提供。

实现内外隔离，隐藏了服务的内部实现细节，保障后台服务的安全性。也降低客户端和服务的耦合度，阻断服务依赖，服务独立运行，通过网关层实现按服务映射，服务编排，缩减外部调用频次，提升访问效率。 隔离内外部服务，也为微服务的扩展提供了便利，在应用层面可以利用容器的伸缩特性实现应用服务实例的自动弹性伸缩，实现应用服务的高可用。

2. API网关是平台的安全屏障

API网关是微服务平台的安全屏障。不管私有服务或者开放服务，其安全性都是一个时刻都需要认真面对的课题。

3. 敏捷-简化开发

在API网关层实现这些安全机制，不但提高安全性，也简化了应用服务的开发。使开发人员专注于业务应用、业务服务的研发，不再考虑基础能力基础组件，提升开发部署的效率，从而提升收益率。 将安全、访问控制等非业务逻辑功能从微服务中分离出来，也使微服务的设计和实现简化。使微服务更轻盈，更敏捷。 通过对 API服务的分类分级，简化和控制开发人员对数据和服务的访问；服务的开放和共享，可以构建更大范围内的协作和开发人员生态体系。加快业务服务业务应用的交付。

4. 标准化接口，统一入口

API网关提供统一对外接口以实现开放性、标准化和规范化。当实现新的业务应用时或者需要集成不同系统或者服务之间的功能，调用不同服务提供的能力时，利用API网关可以让用户在不感知服务边缘的情况下，利用统一的接口编排组装服务。对于一个公司内部不同的服务，由于历史原因提供的接口可能有不小的差异，通过API网关可以消除这种差异，统一对外提供标准化的接口，比如Restful接口。 当内部服务更新时，也可以通过API网关进行适配转换，对客户端透明，不需要调用方进行调整。 标准化是微服务化面对的一个很大挑战。虽然我们也强调微服务的价值在于重构，但重构需要很长的路要走，刚开始可能需要类似于ESB的集成，首先实现互连互通，资源共享。但ESB服务往往比较重，无法满足低延迟的要求，所以还需要逐步的重构业务应用。不同微服务的开发语言、协议、接口类型等可能不一样，所以需要API网关来实现转换，提供统一的标准化API对外开放，最为统一的入口。

5. 监控分析，明确各部分工作业绩

日志监控等能力也是API网关的重要能力之一。通过对API访问日志和运行监控数据的统计分析，可以了解业务服务的调用情况、调用趋势、运行情况等等。一方面是业务服务评价的指标，另一方面也是助力智能决策的数据来源。哪些API服务调用的多，哪些API服务调用的少，哪个客户调用的多，以及高峰流量时刻、平均流量、响应时间等等都是需要监控和统计分析的。这些数据将有助于我们对提供API的服务进行运维运营或重构，有助于我们做出合理决策。更为智能决策提供必须的数据支持。也是服务开发和拥有者的业绩参考。

使用API网关实现微服务治理

微服务治理涉及的方面很多，但大体上包含微服务生命周期管理、微服务注册发现、微服务日志监控、微服务安全、微服务访问控制、微服务编排、微服务负载扩展、微服务流量控制、容错熔断等。这其中的大部分能力都可以在API网关层来实现，同时可以结合容器云平台来实现完善的微服务治理能力。 从API网关的定位和能力来看，我们主要可以在网关层实现微服务的安全认证及访问控制（包括路由、转换、流量控制等），同时API网关也提供注册发现、日志监控、服务编排、负载均衡等能力。利用这些能力，可以便利的实现微服务的治理，天然融合，无需再开发或部署一套微服务治理平台，也不用为不同平台之间的集成花费人力财力和珍贵的时间。 目前API网关产品众多，商用的产品功能相对完善，可以很好的满足微服务治理的需求。

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