微服务中，如何交付一款成功的API

【51CTO.com快译】摘要：在微服务中，API作为关键要素，可以极大地提高业务的敏捷性和效率。它往往位于客户和微服务之间，将两者连接在一起，以创建令人满意的用户体验。在本文中，我们讨论了成功交付一款API所涉及到的九个方面。

如今，各大企业都纷纷以消费者为导向，以为客户提供价值为首要任务。为了需要找到那些更有效率、工作更便利的方法，我们需要通过反复试验来构建并试用系统的各项功能，以确保它们确实能够为客户带来了巨大的价值。近年来“微服务”的出现，恰恰方便了企业对于原有服务架构的分解和按需组合。

由于微服务能够使得传统的具有高度依赖性的整体资源，被分解成为更小的独立单元，因此我们能够更快、更轻松地向系统中引入新的功能，而且最小化对于系统其他区域的影响。

在微服务中，API作为关键要素，可以极大地提高业务的敏捷性和效率。它往往位于客户和微服务之间，将两者连接在一起，以创建令人满意的用户体验。在本文中，我们将深入探讨如何交付一款成功的API。

一、颠覆传统的API交付模式

如果贵企业从事过消费类API的交付过程，您一定熟悉以下的交付模型。

传统API工作流程

在该模型中，我们首先使用某个门户（portal）来设计、实现和记录自己的API。接着，通过发布的方式，将其部署到我们的网关和开发人员的门户上，以供应用开发人员发现和使用。虽然此模型为我们提供了良好的服务流程，但是如今它已成为我们在为客户提供价值的过程中，主要的敏捷性瓶颈之一。

为了提高微服务流程的自动化效率，以及在发生故障时的“回滚”能力，我们需要改进开发和部署的流程，将自上而下的方法，替换为如下图所示的自下而上的方式：

自下向上的API开发方法

与部署代码类似，我们的API也需要进行持续集成和持续部署。

• 我们可以授权开发人员去构建、部署和测试API，并在满意的基础上，将其部署到门户和生产环境的网关中。
• 我们需要使用SCM（Github）对API的代码进行版本控制和管理。
• 我们需要使用Jenkins、Travis CI等自动化构建工具，来将API自动部署到各自的环境中。
• 我们需要为开发人员配齐所需的适当工具，以方便在API上启用CI/CD，并对其进行类似应用程序源代码式的管理。

二、API治理

当然，采用自下而上的API交付模型也需要适当地进行治理。研发团队有责任确保其发布的API能够遵循正确的标准，优秀的实践，以及恰当的保护。

API工作流程

如上图所示，API需要通过良好“控制平面（Control Plane）”来支持生命周期的管理。在被发布到门户之前，以及通过CI/CD被交付到上层环境之前，API需要得到充分的审核。我们通过可配置的工作流，将API的设计以及验证等优秀实践，应用到相关的安全性架构之上。

三、可组合性

API的可组合性

API不再仅仅是微服务的简单HTTP接口。现代企业架构由许多不同类型的微服务所组成。您可以让团队开发出作为无服务器功能（例如AWS Lambda）的各种微服务，并发布到gRPC，WebSockets上。

同时，应用程序需要通过统一界面来访问这些服务。该界面包括应当具有单一的身份验证服务、访问服务的授权、单一的SDK、以及统一的文档等。这些都是由API层提供给应用程序的。可见，API并不是一组服务的简单代理。它具有能够处理集成异构微服务细微差别的能力，并通过“暴露”的统一接口，以供应用程序使用这些细微差异化的单元。

四、API安全

许多组织会将其业务功能作为公共的API发布出去。这自然会使得API成为攻击者尝试窃取敏感信息，进而对组织造成危害的狩猎场。因此，我们需要对API的安全性问题保持高度的警惕，并设为高优先的事项。

通常情况下，企业会从基于OAuth2.0的身份验证和授权方式入手。如下图所示，我们还应当考虑到如下三个方面的API安全性：

• 防止恶意内容和DoS攻击。
• 身份验证和授权。
• 通过不断识别与异常模式的学习，来保证安全性。

API安全性工作流

恶意内容和DoS攻击

为了攻击API，黑客可以完全控制其发送的恶意请求。这些请求消息既可能是注入攻击（如：SQL注入）的消息，又可能是畸形消息（导致大量耗尽服务器的资源），还可能是包含XML炸弹（https://www.soapui.org/security-testing/security-scans/xml-bomb.html）的消息等。

所谓DoS攻击是指：恶意软件客户端会发出大量的API请求，导致服务器没有足够的资源去为真正的用户请求提供服务。为了防范此类针对API的攻击，我们可以使用Web应用防火墙（WAF）或API网关，来检查消息的内容，并根据预定义的规则与模式予以验证。同时，它们还能够限制客户端请求的速率，以防止客户端在较短的时间内发送大量的消息。而对于安全网关而言，我们也需要通过持续监控，发现新的漏洞，并及时为其打上补丁。

尽管从技术上来说，API网关和Web应用防火墙都可以防范此类攻击，但是Web应用防火墙会更适合些。其原因在于：Web应用防火墙更专注于此类安全域，而API网关则通常负责系统中的多项功能性任务。

身份验证和授权

在身份和访问控制方面，我们往往会基于有效的凭证，来授予请求对于API资源的访问权限。此类凭证包括：OAuth2.0访问令牌、API密钥、基本身份验证的标头、客户端证书等内容信息。例如，任何具有有效用户名和密码的用户，都应当被允许在某个电商网站上浏览产品的详细信息。但是，只有那些具有管理员权限的用户才被允许更新产品的详细信息。当然，访问控制也不仅限于基于角色的检查，有时一些系统还会根据日期和时间（如：仅允许在工作日的8点到17点之间访问），或基于请求的配额等方面进行访问控制。

上文提到的API网关，可专门负责此类身份验证与授权检查。它们将各种系统安全需求抽象成标准的规范和协议，并允许客户端应用通过该机制（例如OAuth2.0）与之交互。

另外，下游或后端API有时候也需要了解访问API用户的详细信息，以便执行其固有的逻辑。因此，有些API网关还会负责将用户的上下文，转发到下游或后端API上。

为识别模式和检测异常而持续学习

光有防火墙和简单的身份验证，是不足以检测API密钥或访问令牌等凭据入侵的。前文提到了OAuth2.0，其访问令牌的时间跨度相对较短，即使被黑客入侵，也只能在令牌过期之前有效。那么为了防止令牌在这么短的时间内被被盗，我们需要通过MFA（多因素身份验证）来进一步执行身份验证。

值得一提的是，API网关本身并不能保护系统免受异常攻击，它只是在横跨不同网络的群集之间避免共享用户的状态和访问记录。因此，API网关需要与某些机器学习和数据模式分析类型的方案一起使用。这些方案将能够跟踪用户的访问历史记录和模式，并在出现问题时向API网关发出警报，以便网关采取适当的措施。

五、可扩展性

API的扩展

如今，许多组织正在将他们的基础架构迁至云端，以按需付费的方式在第三方IaaS提供商（如：AWS、Google、以及Azure等）上运行全部或部分IT服务。云原生架构的一项关键特征是能够提供自动扩展的服务。那么我们的API及其网关也要具有此类特征。在此方面，我们需要考虑到如下三点：

• 启动的延迟。
• 对其他系统的依赖性。
• 状态的复制。

通常，进程启动的速度越快，就越容易扩展。例如：某个进程需要30秒或更长时间才能启动，那么它就至少需要在30秒之前开始扩展，以便系统能够及时启动并运行该进程。也就是说，如果某个进程启动需要的时间越长，您越需要提前扩展该进程。

有时候，某个进程无法自行扩容，此时您的API及其网关就需要依赖于其他辅助类进程来实现。可见，您的API及其网关越独立，就越容易实现系统的扩展。另外，如果您的API及其网关需要维持内部、外部状态的一致性，那么在扩展API时则需要考虑如何复制系统的状态。与常规有状态系统相比，独立且无状态的API更易于自动扩展。

六、可用性

如今系统的可用性变得越来越重要了。虽然云服务为我们的整体业务提升了鲁棒性，但是我们仍然需要考虑如何为API构建和配备具有一定的弹性系统，其中包括：

• 当系统出现故障时，我们能够快速地恢复系统。
• 数据中心、整体区域、以及IaaS服务的高可用性。

通常而言，我们很容易通过备份的形式满足单个系统中的每个服务器、进程、文件系统、以及数据库的高可用性。但是，我们该如何应对整个数据中心或区域的故障呢？我们通常需要在多个数据中心的位置上同时部署自己的API。而为了减少API构建、部署和维护的开销，我们往往需要通过尽可能多的自动化，来轻松有效地实现跨多个可用区域的数据复制。

由于系统存在的依赖性越多，其故障恢复的难度就越大，因此许多系统都采用了具有自动修复能力的原生云端容器平台（如：Kubernetes），以降低故障恢复的难度。不过，云服务提供商本身的可用性最近也受到质疑。设想一些：如果某个IaaS提供商的特定服务发生了全球范围内的中断，我们是否能够切换到其他IaaS处呢？例如，是否可以通过协作，我们将运行在AWS RDS某个区域的中断业务切换到Azure的备份上？

如今，已经有企业成功地在不同地区的IaaS提供商之间部署了自己的API。他们在不同的IasS上构建了分布式的可扩展系统，并通过分担整体系统负载的方式，实现了按需扩展与付费。

七、维护

我们可以从如下三个方面及时获悉API有效性与性能:

• 运营监控
• 故障诊断
• 业务监控

运营监控

运营监控对于API的正常运行，以及业务平稳开展都是至关重要的。您需要在真正发生问题之前就能判定故障，予以解决，并消除负面影响。例如：您的某个服务或API出现了耗尽内存的情况，那么您就可以及时通过监控系统，检测到API对于内存使用率的极速增长，并在超过既定阈值的时候收到警报信息。而针对此类情况，我们往往可以通过扩展出更多的实例进程，来为根本原因的查找和解决赢得时间。

故障诊断

对于事件的故障诊断，及时收集到故障的相关数据是非常重要的。首先，我们需要从API和服务处收集到所有的运行时日志，通过对其进行索引，以便快速轻松地进行搜索，进而获取和识别特定时间段发生的系统事件。在掌握事件日志之后，我们需要根据“蛛丝马迹”按需启用进一步的日志跟踪，以获取内存dump、网络等方面的信息。

您应该致力于构建能够以理想的零故障率或最小的客户影响率进行故障排除的系统。这样做的一种流行模式是将一组故障节点隔离到一个单独的群集中，该群集要么不接收客户的流量，要么仅接收一小部分流量，以方便执行故障排除。

业务监控

现如今，许多企业都将对外提供API作为自身业务的主要增长点。因此，他们需要通过衡量API的使用，来决定组织业务的策略。为此，我们需要一个系统来捕获与实现与当前业务目标相关的所有API数据，其中包括：前一个月新API的使用者数量，基于现有API构建的新应用的数量，调用当前API的应用在其响应时间上的改进，特定区域内API用户的增长等方面。我们通过深入挖掘API的调用，以衡量业务KPI的表现。

总结