Salesforce 构建可扩展 API 的旅程作者|NiteshKumar

作者|NiteshKumar
译者|张卫滨
策划|Tina
API对于组织来讲正变得越来越重要，但是，构建安全、可扩展的API并非易事。本文从执行环境、API技术、安全性等角度出发，介绍了如何构建高效、可扩展的API 。
本文最初发表于Salesforce站点，经作者NiteshKumar授权，由InfoQ中文站翻译分享。
API是一个重要的工具，允许合作伙伴、开发人员和其他应用消费我们提供的微服务，与之进行通信，并基于此构建各种各样的功能。
高质量的API要能够随着业务生态系统的发展而扩展，构建这样的API并不是一件容易的事情，需要对所有的事情进行通盘思考和规划，涉及到选择哪种执行环境，甚至要决定该使用哪种API技术。
那么，我们是如何实现的呢？在本文中，我将会分析在Salesforce为ActivityPlatform构建API的经验，它可以作为你自己编写API的一个指南。 ActivityPlatform是一个大数据处理引擎，每天会摄取和分析超过1亿次的客户互动，以自动捕获数据并产生分析、推荐和feed 。 ActivityPlatform提供了API来为我们的客户交付这些功能。
选择执行环境
根据需求不同，执行环境可以是裸机、虚拟机（VM）或者应用容器。我们选择了使用应用容器，因为它可以在物理机或VM上运行，一个操作系统实例能够支持多个容器，每个容器都在自己独立的执行环境中运行。简而言之，容器是轻量级、可移植、快捷的，并且易于部署和扩展，所以它们天然适合微服务。

文章图片
关于容器编排
如果你像我们这样决定使用容器，容器编排能够帮助你实现自动化部署，管理容器、扩展以及网络。在这方面，有很多可选的容器编排工具，比如Kubernetes、ApacheMesos、DC/OS（withMarathon）、AmazonEKS、GoogleKubernetesEngine（GKE）等。
我们使用的是Hashicorp的Nomad集群。它非常简单、轻量级，并且能够编排任何类型的应用，而不仅仅是容器。它能够无缝与Consul和Vault集成，实现服务发现和secret管理。我们可以很容易地将需求描述为一个待执行的任务（task），比如内存、网络、CPU ，以及我们水平扩展服务所需的实例数量。

文章图片
选择API技术
为了构建API ，我们选择了使用GraphQL 。如果你没有听说过它的话，它是其他可选技术（如REST、SOAP、ApacheThrift、OpenAPI/Swagger或gRPC）的一个替代方案。
我们为什么选择GraphQL
我们想要构建的API能够服务于多种客户端，涵盖Web和移动应用。它需要具备高效、强大和灵活的特点。
鉴于以下的原因， GraphQL是最合适的方案：
GraphQL是数据库无关的技术，能够从任何地方为我们预先定义的业务领域提供数据。这意味着为了满足一个查询，底层可以使用Cassandra、Elasticsearch或其他模块的现有API 。

文章图片
它允许客户端精确请求想要的数据，避免过量加载（overfetching）或加载不足（underfetching）。如果API返回的数据超出了客户端的需求，这会导致性能问题，如果返回的数据比预期要少，那么会进行多次网络调用，从而减缓渲染时间。 GraphQL能够避免这两种情况。
尽管大多数的API都实现了版本管理，但是GraphQL是一个无版本化的API 。因为它只会返回明确请求的数据，所以我们可以通过添加新的类型以及类型上的新字段来增加功能，避免带来破坏性的变更。