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

容器技术越来越成熟，应用领域也越来越广，容器的应用促进了微服务的快速发展，也使旨在提升效率和融合开发运维的DevOps迅速落地。容器、微服务、DevOps就像孪生兄弟，相互依存，相互融合和发展。随着容器平台的建设落地，微服务越来越火，越来越多的公司已经开始采用或者正在考虑采用微服务架构。但微服务架构应用通常是分布式的，一个业务应用通常是由众多的微服务编排而成，服务之间的调用、通信、安全认证、访问控制、负载均衡、限流限额等需求也带来了运维的复杂性，实现微服务治理是个不小的难题。如果再把微服务部署于容器云平台，则会更加复杂。目前也有不少的厂商或者公司尝试开发微服务治理平台，不管基于gRPC或者Istio等，都不是一个成熟的方案。基于我们银河证券容器云平台建设和微服务管理治理的实践研究，我们提出了使用成熟的API网关产品来实现容器云平台微服务治理的方案，更快、更便利的实现微服务的治理，特别对于传统行业IT技术实力相对有限的情况下，避免投入大量的人力财力去做基础平台的研发，更可避免项目失败所导致的时间、发展机遇的错失。

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

微服务化带来了很多好处，比如通过将复杂单体系统切分为若干个微服务来分解和降低耦合性，而且每个微服务功能单一，实现快捷，使得这些微服务易于被小型的开发团队所理解和维护，相对于单体系统降低了复杂度。然而微服务也带来了很多挑战，微服务架构是分布式架构，单个微服务简单，众多的微服务分布式应用的复杂性难以回避，众多微服务之间的通信、微服务事务处理、微服务的拆分、服务注册、服务发现、负载均衡、路由、监控、AB测试、金丝雀发布、限流、访问控制等等都带来了挑战。特别微服务部署于容器云平台，基于当前现状如何治理好微服务是一个棘手的具有挑战性的问题。

1. 常用方案的不足

服务治理的问题由来已久，服务治理也是一个很大的话题。在SOA ESB的时代就有很多探讨，微服务化盛行之后显得尤为重要。目前比较流行的微服务开发框架是SpringCloud，国内也有用Dubbo的，但Dubbo远远达不到实际的要求。SpringCloud虽然提供了很多组件，但都是半成品，作为开发人员还有很多工作需要做，最终服务组件的质量往往取决于开发人员的能力，不同开发人员所实现的微服务可能千差万别；其次，SpringCloud对代码有侵入性，如果以后要更换开发框架，需要重写很多东西，甚至可能不得不推倒重来，代价高昂；再者，Java语言的特异性，如果要采用其他开发语言如Go/Python等开发的微服务或者不全是Java微服务，SpringCloud可能就无能为力，无法统一管控。微服务治理更是难以实现。

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

Service Mesh服务网格目前是很火热的存在。很多人鼓吹其为第二代微服务，不过在我们看来更多是概念炒作，Service Mesh服务网格描述的是微服务网络，所实现的是服务治理能力而不是微服务。其定义是一个用来连接、保护、控制和观察微服务的工具。Service Mesh 服务网格的核心思想就是“流量代理”，通过一个个SideCar“代理（Envoy）” 来为微服务转发和接收所有流量，而不用去修改微服务代码，通过控制这些SideCar代理，就可以实现微服务连接、访问控制、注册发现、安全认证、负载均衡、限流熔断、监控等等一系列服务治理相关功能，使微服务的代码不再需要去实现服务治理逻辑，简化了开发并提高了敏捷效率。说到底其是服务治理工具，谈不上第二代微服务。
作为Service Mesh的一种实现，Istio 1.0刚刚GA（General Availability）,虽然鼓吹说可以上生产，但依然需要时间和实践的检验。服务网格会随着微服务数量的增加而成倍的增加复杂度，这也是需要进一步检验的方面。

3. 微服务治理的复杂性

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

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

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

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

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

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

4. 敏捷性需求

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

5. 安全挑战

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

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

6. 服务接口标准化要求

微服务架构的挑战是实现服务的标准化，以及保证服务的可靠性和可用性。车同辙、书同文、量同器、货同币。微服务实现可以是不同的语言、不同的协议、不同的名称、不同的字段类型等，这些微服务之间如果要交互，就面临着众多的转换问题，类似于曾经的系统集成问题，所以后来出现了ESB，但ESB并没有从根本上解决问题。所以不管微服务是怎么实现的，微服务接口API需要标准化。
一种实现方式是在微服务前面加个Adapter适配器，由Adapter来实现转换。对微服务来说它有了API网关，其可以承担其Adapter的职责，因此API网关层是可以提供标准化的接口的。

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的调用，提供了接口的稳定性。

API相对稳定，API实现是不固定的，Client /Server都可能是不固定的，但API层是稳定的。API（Application Programming Interface，应用编程接口）则提供了一个稳定的接口层。接口的实现可以变，只要接口不变，调用接口的应用就不需要改变。
同时对外访问控制由网络层面转换成网关应用层面，减少变更流程和错误成本
（3）.不同服务定义为不同的API，非兼容更新的服务定义不同的API。不影响原来的接口版本。

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

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

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

API网关提供安全和保护能力，阻止客户端应用以非安全和非管理的方式直接访问API，保护开放的应用。这是API网关最重要的能力之一。隔离内外服务也就减少对外暴露的服务可能，以增加系统安全性。在API接口层实现授权认证、访问控制、防范威胁和OWASP漏洞、防御性缓存、通过SSO和统一身份管理来等来提高安全性，为应用程序、移动和IoT提供端到端的安全机制。也可能需要在API网关实现流量控制、限额、过滤、熔断、服务优先级控制、超时处理、负载均衡等机制来保护应用服务的安全。
安全第一，就像我们的社会交通一样，第一要保证安全的条件下快速通过。这也是在实现或选择API网关时首先要考虑的问题。
安全涉及的问题也比较多，API网关层通常要实现身份统一认证，可对接统一认证中心、权限中心，实现授权认证、访问控制等功能。为了最小化延迟，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网关产品众多，商用的产品功能相对完善，可以很好的满足微服务治理的需求。