银行 API 能否从云技术中获益？

银行 API 不可或缺，因为它们能把银行产品汇集到一起，分发给消费者、企业和合作伙伴。它们相当于数字银行的"结缔组织"，能够支持客户的需求并更快地响应变化。云技术改进了银行设计、开发和运维 API 的方式，助力银行摆脱了过去的限制。

这是因为前几代 API 技术是围绕传统架构构建的，而这些架构通常都受底层基础架构限制。这种方法意味着托管安排是预先静态定义的，这就带来了集成问题的集中化。最终，这就阻碍了银行按需快速创建和调整 API 的能力。

随着微服务等新架构不断发展，支持它们所需的技术也在不断发展，进而对 API 开发和管理提出了更高的要求。但是，通过正确的云原生流程和工具，API 和云技术可以协同工作，从而降低技术复杂性并为客户和合作伙伴创造新价值。它们可以帮助银行打破传统 API 方法的限制，提高灵活性和效率。

更具体地说，通过云原生技术，银行可以简化创建和管理 API 的流程，而无需管理底层基础架构，同时将非侵入式策略实施应用于支持它们的运行时。

长期以来，银行内外流动的数据一直是犯罪分子的目标，常被其盗窃用于各种犯罪活动。而 API 就是犯罪分子盗取和操纵银行信息的主要攻击媒介。

随着网络攻击越来越复杂，银行在考虑 API 保护和 API 安全防护时需要的不仅仅是 API 访问控制。传统的安全方法就像是"城堡和护城河"，但这种模型已被证明无法有效防御当今的犯罪分子。而云平台可以通过内置服务网格帮助银行轻松采用零信任模型，以提供 API 保护，这种模型假设来自任何来源的任何通信默认都是不可信的。

通过在 API 管理中加入 Kubernetes 原生方法，银行可以利用云平台的底层功能为其动态数据提供最稳固的 API 安全态势。

从根本上来说，API 的核心就是交换数据，因此设计的目标就是使交换变得简单、安全和可靠。完善的 API 设计可以确保银行尽可能高效地实现上述目的。通过在部署管道中应用并通过标准策略实施点实施的规则，云平台可以实施 API 最佳实践和 API 标准。这种实施有助于保持 API 定义简单且一致。

通过在 API 粒度方面贯彻良好的 API 设计原则，云技术还可以让您的架构更加灵活。银行可以使用容器来采用基于微服务的架构，以便将 API 分解为可以独立演进、大小合适的部分，并提供媲美云原生架构的敏捷性，同时保持银行内外通信所需的安全性和可靠性。 

如果能够快速发展 API 的能力，就可以为银行提供前所未有的优势。许多银行已经采用敏捷实践和原则来加速开发，但传统的分布式技术限制了由此带来的优势。通过云平台，敏捷团队无需请求基础架构或其他支持资源即可发展 API。这意味着团队可以花更多时间专注于通过 API 编程创造价值，而不用把时间耗在提交工单请求资源上。云平台还有助于分散的开发人员发现和使用 API，从而将自己的应用与现有服务集成。
使用 Kubernetes 原生方法，开发人员可以简化软件交付并更快地将新功能提供给用户。开发人员在云平台内拥有用于 API 设计和测试的附加服务以及其他技术，能支持与部署管道配合使用的全栈开发。这使团队能够在需要时快速调整，同时遵守软件交付最佳实践。

API 消费者往往希望银行提供的 API 能够具备高服务水平。性能不佳的 API 和服务中断会对银行的声誉产生负面影响，并且恢复服务的成本也会很高。API 依赖于其他系统和组件，来实现正常运行并满足服务级别义务。

云平台中的服务网格在监控 API 方面远远超越了传统方法。它们可以自动检测减速并关闭通信，直到受影响的组件可以恢复。云平台可以自动识别实例不正常的时间，并采取纠正措施使它们进入正常状态，从而扩展服务网格的价值。这些基于云的功能不仅提高了可用性，还降低了运行运维的成本。 

云平台还具有支持持续交付的内置管道。在需要发布 API 的新版本时，这可以减轻繁琐的部署实践的痛苦。它还使银行能够采用金丝雀部署，以便流量可以逐渐迁移到新版本的 API 并最终降低部署风险。