现代企业是高度以消费者为导向的。因此，为客户提供价值应该是我们的首要任务。使客户的任务更加方便和高效是我们的首要目标。要做到这一点，我们需要找出“什么”可以使我们的客户更有效率并为他们的工作带来便利的方法。
这需要大量的反复试验。这要求我们构建并尝试使用系统和功能，以查看这些功能是否确实为我们的客户带来了巨大的价值。这是促使企业体系结构更加分解和可组合的主要动机。听说过“微服务”吗？
这就是为什么微服务变得非常流行的原因。微服务使传统的企业（高度依赖整体资源）可以分解为更小的独立单元。这使我们能够更快地向系统中引入新功能，而对系统其他区域的影响则小得多。这就是创建一个平台的原因，它可以帮助我们比以往更快，更轻松地发现“真正”为客户带来价值的“东西”。
尽管微服务可以极大地提高我们的业务的敏捷性和效率，但API才是为我们的消费者/客户提供微服务价值的要素。API位于我们的客户和微服务之间的边缘，将两者连接在一起可创建令人惊叹的用户体验。因此，API位于为客户提供价值的最前沿。在本博客文章的其余部分中，我们将探讨作为成功的API系统的架构师，CxO和其他决策者需要考虑的内容。
颠覆传统的API交付模式
作为向消费者交付API的组织/企业，您可能熟悉以下交付API的模型。
传统API工作流程
在此模型中，我们首先使用门户来设计，实现和记录我们的API。然后，通过发布将其部署到我们的网关和开发人员门户。然后，API可供应用程序开发人员发现和使用。虽然此模型为我们提供了良好的服务，但现在它已成为我们为客户提供价值的过程敏捷性的瓶颈。
我们提供微服务的流程效率更高，更易于自动化，并且在发生故障时易于回滚。我们还需要为我们的API采用类似的模型。为此，我们需要更改开发和部署过程，以遵循更多自下而上的方法，而不是自上而下的方法，如上所述。下图说明了这是什么。
自底向上的API开发方法
与部署代码类似，我们的API从第一天起就需要进行持续集成和持续部署。我们需要授权API开发人员构建，部署和测试API，直到他们对结果满意为止，然后才能将其部署到门户和生产网关。API的代码需要使用SCM（Github）进行版本控制和管理。
我们需要使用Jenkins，Travis CI等构建自动化工具来将API部署到各自的环境中进行自动化。我们需要确保开发人员从第一天起就具备所需的适当工具，以在API上启用CI / CD并对其进行管理，类似于管理其应用程序的源代码。
API治理
采用API的自底向上传递模型的关键瓶颈之一是对API缺乏治理。API产品经理担心他们会失去正在发布的API的权威和治理。这是一个真正要解决的问题。组织有责任确保其发布的API遵循正确的标准，最佳实践，以正确的方式进行保护等等。否则将对组织产生负面影响。那么，我们如何以敏捷的方式交付API，同时又对API进行适当的管理？
API工作流程
在这里，API的良好“控制平面”的价值变得很重要。API控制平面需要支持API的良好生命周期管理功能，以便API产品经理可以在API发布到门户并通过CI / CD传播到上层环境之前进行审核和同意。通过可配置的工作流程批准API的设计以及验证用于最佳实践和安全性的架构的能力是必不可少的功能。
可组合性
API的可组合性
API不再是HTTP（仅）微服务的简单接口。现代企业体系结构由许多不同类型的微服务组成。您可以让团队开发微服务，这些微服务作为无服务器功能（例如AWS Lambda）在gRPC，WebSockets上公开。
但是，需要使用这些服务的应用程序需要一个易于理解的统一界面来访问这些服务。应用程序将需要一个单一的身份验证终结点，以授予对服务的所需访问权限，一个用于这些服务的单一SDK，一个具有统一文档来源的统一界面等。
这些都是由API层授予应用程序的。因此，API并不是一组服务的简单代理。它是一个处理集成异构微服务的细微差别并将其组成可暴露的统一接口以供应用程序使用的细微差别的单元。
API安全
API的成功鼓励了许多组织将其业务功能公开为公共API。许多人会开始仅出于内部目的公开API，然后再将它们扩展为公开展示。在过去几年中，对API的这种广泛采用已实现了巨大的增长，并导致API获得了极大的普及。
这自然使API成为攻击者尝试窃取敏感信息或以其他可能的方式对组织造成危害的丰富狩猎场。因此，我们需要对API的安全性问题保持高度警惕，并应将API安全性视为高度优先事项。无论何时部署API（即使是第一次），都绝不要事后思考，并且应该始终是一个醒目的复选框。
几乎总是以基于OAuth2.0的身份验证和授权的形式来考虑API安全性。OAuth2.0确实已经确立了自己作为API安全的事实上的标准，但是必须充分考虑API的安全性，而不是认证和授权。我将API的安全性分为3个方面。
- 防止恶意内容和DOS攻击。
- 身份验证和授权。
- 通过不断学习异常模式识别来保证安全性。
API安全工作流程
恶意内容和DOS攻击
向API发出请求的客户端（攻击者）可以完全控制其发送的消息。这些消息可以经过许多服务层，如果是恶意的，则可能对系统造成潜在的危害。这些消息可能是旨在执行注入攻击（SQL注入）的消息，非常大的消息（导致消耗大量服务器资源），包含XML炸弹的消息等。
恶意客户端应用程序还可能发出大量API请求，从而导致服务器用尽资源来为系统的真正用户提供服务（DOS攻击）。可以使用Web应用程序防火墙或API网关来防止对API的此类攻击。这些系统可以检查消息的内容，并根据预定义的架构或规则（模式）验证消息的内容，并且仅接受属于定义范围内的消息。它们还能够限制客户端请求的速率，以防止客户端在非常短的时间内发送大量消息，从而防止潜在的DOS攻击。
尽管从技术上来说可以使用API网关或Web应用程序防火墙来防止这些类型的攻击，但是Web应用程序防火墙更适合于此目的。这是因为Web应用程序防火墙专用于这些类型的安全域，而API网关通常负责这些系统中的许多任务。
安全是一个应该专门化的领域，并且需要专职致力于研究和创新。一旦发现新的漏洞并为其发布了补丁程序，则应立即更新安全网关。这是专门针对领域的系统最好的方法。Alissa Knight撰写的此博客文章详细比较了每个角色的职责，并讨论了为什么在企业体系结构中使用这两个层次很有意义。
身份和访问控制的验证是我们在API领域中大多数人所熟悉的东西。这是关于基于有效凭证授予对API资源的访问权限，该凭证的范围可以是OAuth2.0访问令牌，API密钥，基本身份验证标头，客户端证书等之间的任何内容。
它还涉及检查所提供的凭据是否具有访问所请求资源所需的权限级别。系统不应仅基于有效凭证就允许全局访问其资源。它的系统设计应检查或至少保留执行进一步访问控制的规定。
例如，任何具有有效用户名和密码的用户都应被允许在在线零售商店上阅读产品详细信息。但是，应仅允许具有管理员权限的用户更新产品详细信息。访问控制有时远远超出基于角色的检查范围。也有一些系统会根据日期和时间（工作日仅在上午8点至下午5点之间允许访问），基于请求配额等进行访问控制。
API网关专门从事这些类型的身份验证和授权检查。他们将这些要求抽象为标准规范和协议，并允许客户端应用程序使用这些机制（例如OAuth2.0）与它们进行交互。大多数API网关解决方案还能够将用户上下文传播到下游（后端）API。
由于这些身份验证和授权检查在API网关处终止，因此默认情况下，下游API将不具有发出这些请求的用户的上下文。下游API有时需要知道访问API的用户的详细信息，以执行其自己的逻辑。因此，API网关有责任将用户上下文传播到下游API。
持续学习以识别模式并检测异常
凭证被盗很难追踪。如果有人入侵了您的API密钥或访问令牌，仅我们的防火墙或身份验证层不足以检测到有人正在使用被入侵的凭据。这就是为什么与API密钥或基本身份验证凭据相比，OAuth2.0访问令牌在使用上更加安全的原因之一。OAuth2.0访问令牌的时间跨度相对较短，即使被黑客入侵，也只能在令牌过期之前使用。只有通过观察用户的访问模式，才能检测到被盗凭证或凭证使用不当。如果某个特定国家/地区的用户使用了令牌，并且几分钟后另一个国家/地区的某人使用了同一令牌，
API网关本身无法保护系统免受这些类型的攻击。API网关通常跨不同网络进行群集，它们之间不一定会共享用户的状态和访问历史记录。但是，API网关可以与数据分析解决方案一起使用，其中包括某种形式的机器学习和模式分析解决方案。这些系统将跟踪用户访问历史记录和模式，并在出现问题时向API网关发出警报。然后，网关可以采取有关验证用户请求的适当措施。
规模
扩展API
许多组织正在将其基础架构迁移到云中。此举是免费的。在第三方IaaS提供商（例如AWS，Google，Azure等）上运行全部或大部分企业IT的成本很高。所有IaaS提供商都采用按需付费模式。这意味着您需要为使用的资源付费。
因此，至关重要的是，以最少的服务器超额配置来消耗运行系统所需的最佳资源量。对于传统的企业IT，我们将对系统进行容量规划，以应对峰值负载。如果我们的系统需要10台服务器来满足平均系统负载，但又需要10台服务器来满足峰值负载，那么为了安全起见，我们将以20台服务器运行系统。
当组织本身拥有基础架构时，这将不是问题。但是，当使用来自第三方IaaS提供商的基础架构时，这意味着我们正在花钱购买几乎不使用的东西。为了解决这个问题，我们需要我们的API（和API网关）能够快速按需扩展和缩小。自动扩展是云原生企业架构的关键特征之一。几乎所有的IaaS提供商都提供自动扩展功能。但是，要使自动缩放有效，我们的软件还必须能够快速缩放。扩展我们的软件时需要考虑以下几点：
- 开机延迟。
- 对其他系统的依赖性。
- 状态复制。
进程启动速度越快，扩展系统规模就越容易。如果某个进程需要30秒或更长时间才能启动，则需要至少在30秒之前开始扩展系统，然后才能真正启动并运行该进程。一个过程开始花费的时间越长，开始缩放过程的时间就越早。
有时无法仅对单个进程进行缩放。您的API和API网关可能依赖于其他帮助程序进程来执行其功能。这意味着您还需要考虑扩大/缩小这些帮助程序。您的API和API网关越独立，就越容易扩展系统。
如果您的API和API网关在其内部或外部维护状态，则在扩展API时将需要考虑复制系统状态。与有状态系统相比，无状态系统通常更易于扩展。因此，快速启动，独立且无状态的API是自动缩放系统的理想选择。
可用性
在当今世界，系统的可用性变得至关重要。停机造成的对企业的影响越来越难以忍受。因此，我们的目标是使我们的API做到100％可用，这绝非易事。假设我们已经处理了前面讨论的与规模相关的问题，那么此处重点关注的是
弹性。我们都自然地擅长于创建强大的系统。但是，我们必须承认和接受的是，在某个时间点上，某些事情将会失败。您未曾预料到的事情一定会发生并引起麻烦。因此，至关重要的是，我们要考虑发生故障时会发生什么情况，如何恢复，为API配备什么样的备份系统？
我们讨论的有关规模的一切对于构建弹性系统都很重要。除此之外，我们还需要考虑：
- 当系统出现故障时，我们可以以多快的速度恢复系统。
- 系统的高可用性（数据中心可用性，区域可用性和IaaS提供程序可用性）。
恢复系统可能比看起来困难。系统具有的依赖性越多，发生故障时恢复的难度就越大。在这个区域中，容器和平台（例如Kubernetes）可以成为救生员。这些平台具有自动修复功能，可为系统提供急需的鲁棒性。
当然，它们有其自身的复杂性和局限性，但是它们提供给我们的API的健壮性和易于管理的水平是值得的。与扩展一样，API的启动时间，它们的独立性和有状态性是恢复API系统的重要因素。您的API的原生云越多，一旦出现故障，它们越容易恢复。
高可用性是我们都熟悉的东西。它只是意味着为系统中的每个服务器，进程，文件系统，数据库等都有一个备份。但是，我们还需要考虑数据中心和区域可用性区域。如果我们的整个数据中心或区域出现故障，会发生什么？如果要在内部运行基础结构，则需要计划在其他物理位置上具有备份基础结构。
您的API需要同时部署在这两个位置。为此，您需要构建系统和流程，以使您可以轻松地在多个数据中心之间部署API，而不会给API开发人员增加更多的开销。这些需要通过尽可能多的自动化来有效地完成。即使您依赖IaaS提供商的基础架构，也是如此。您需要考虑可用性区域，以及如何在尽可能少的工作开销下轻松地跨多个可用性区域复制数据。
最近，云服务提供商的可用性也受到很多质疑。如果IaaS提供商的特定服务在全球范围内（即使是很短时间内）失败，会发生什么情况？您的系统是否具有足够的弹性，以便可以在可以切换到的其他IaaS提供程序上运行备份？例如，如果AWS RDS服务在给定区域上短时间失败怎么办？您是否可以备份Azure上的备份？将所有鸡蛋放在一个篮子里绝对不是一个好主意。
我与许多客户合作，这些客户已成功在不同地区的IaaS提供商之间部署了他们的API。听起来像是一个不可能的问题的昂贵替代方案。是的，除非经过深思熟虑和精心设计，否则一切都会如此。此处的关键是构建可扩展的系统，该系统可在IaaS提供程序之间分布，并在整个基础架构中分布系统负载。这样，您只需为使用的商品付费。并在必要时保留规定以按比例缩放。
见解
API是当今许多数字企业的经济/收入背后的驱动力。因此，了解API的性能，了解有效的方法，无效的方法以及拥有良好的数据集以进行准确的课程更正对于API至关重要。基于API的见解可以分为3个不同类别，例如
- 运营洞察力。
- 错误诊断。
- 业务见解。
运营见解
运营洞察力（也称为监视）对于任何组织确保其API正常运行，从而确保业务平稳运行都是至关重要的。拥有针对API的监视系统通常可以使您“在发生问题之前”知道问题。当然，相反的情况是，缺少监视系统只会让您意识到发生故障后的故障，通常是通过客户投诉！
不用说，在故障发生之前就知道故障，这将使您更轻松地处理故障，并且所承受的压力也更少。最好的部分是，您将采取必要措施消除此类故障对客户的影响，因此您的客户永远不会知道故障。
假定您的服务/ API之一开始耗尽内存的情况。一个好的监视系统将检测API的内存消耗的逐渐增长，并在超过特定阈值时发出警报。这为系统管理员打开了立即采取行动的机会，可防止您的客户受到此事件的影响。
在这种情况下，通常的做法是启动一些备份过程。由于我们尚未发现并解决故障的根本原因，因此备份程序很有可能也会在一段时间后开始耗尽内存。
但是，拥有一组备份流程使我们有机会继续重新启动有故障的流程，让备份流程处理客户的请求，并以循环方式继续执行此操作，直到确定并解决了根本原因。因此，尽管我们的流程有问题，但由于该事件，对客户的影响为零，这从业务角度来说是一个重大胜利。
错误诊断
一旦发生了事件并通过运营监控或客户投诉确定了事件，下一步应立即采取的措施是确定事件的根本原因并加以解决。错误诊断在确定根本原因中起着关键作用。出于诊断目的而获取数据的速度，这样做的难易程度以及您收集的有关故障的数据量都是要考虑和实施的重要因素。
首先要查看系统日志以识别事件原因。因此，从API和服务收集所有运行时日志并使其具有索引形式以便于快速轻松地进行搜索非常重要。获取特定时间范围内发生的系统事件日志的能力也很重要。
掌握事件日志后，日志本身可能会揭示事件的原因，例如磁盘空间错误不足。但是，在某些情况下，日志仅给出原因的暗示，而不一定揭示实际原因本身。在这种情况下，有必要启用进一步的日志记录，跟踪，获取内存转储，网络（tcp）转储，等等。
您应该致力于构建能够以理想的零故障率或最小的客户影响率进行故障排除的系统。这样做的一种流行模式是将一组故障节点隔离到一个单独的群集中，该群集要么不接收客户流量，要么仅接收一小部分客户流量，并对它们执行故障排除。
商业见解
如前所述，API是当今许多数字企业的主要收入来源。因此，企业自然会通过使用和采用其API来衡量业务的成功和增长。使API成为组织业务策略的驱动力也很有意义。
为此，我们需要确保我们的API能实现我们期望的业务价值和增长。为此，衡量API的“业务影响”至关重要。我们需要一个系统来捕获与实现我们的业务目标相关的所有API数据。诸如上个月的新API使用者数量，基于我们的API构建的新应用程序数量，响应时间改进，特定区域内的用户增长（在针对该区域的营销活动之后）等等。
由于API是组织数字服务的切入点，因此它们是衡量业务KPI的重要来源。
结论
在本文中，我们了解到：
- 为客户提供价值是我们的第一要务。基于微服务的体系结构旨在以更快的速度交付可靠的软件，从而为客户提供更高的价值。
- API是企业体系结构的基础层，可以创建数字体验。
- 现代API是自下而上开发的，从而使API开发人员和CI / CD流程更加突出。
- API治理在确保正确交付API和正确交付API方面发挥着重要作用。
- API应该是可组合的。组织应具有将服务的异构集合组合到API中的能力。
- API安全性有三方面。内容检查，身份验证和授权，异常的模式分析。
- API应该具有可扩展性，可以满足云原生时代的需求。
- 9的可用性不再存在。需求是100％的可用性。
- API见解对于维持和发展数字企业至关重要。
閱讀更多 一名小白人員 的文章
