软件架构师需要具备独具特色的API设计思想，因为这会对混合云部署的效率和抉择产生重要的影响。

大多数企业和软件架构师都意识到，不是所有应用程序都可以移动到公共云中，因此，混合云设计就显得至关重要。许多人都不太了解API设计对公共云部署选择和效率会带来如此重要的影响。API设计过程中，通过设定参数以及管理状态和工作量而解决组件模型和工作流的最优化问题。为了建立效果较佳的API，我们选定了一种混合模型来实现最初的目标和记录应用程序工作流量，同时，API设计也可以有助于状态管理和负载平衡。

选择一款混合云模型

当每一个人都在使用混合云的时候，那么就有多种混合模型可供选择，当然，任何一款API都有它的特殊问题。多数计划实施混合云的企业都已经采用了Web前端混合模型，并将用户访问应用程序的部分转移到了公共云中，但是，其中转移数据需要经过数据中心的处理。

排名第二受追捧的模型就是云簇模型，在高负荷或者传输失败的时候，补充数据中心资源就会希望获得公共云资源。第三大混合模型是卸载分析模型，在云应用被用于分析包括大数据在内的历史数据时，该模型得以应用。

我们需要知道的是，哪些模型需要受到支持，一家公司如何排列这些模型的优先顺序。我们需要记住设为目标的混合模型，最好从最重要的一个开始，因此，需要设置整体API策略。

重新回顾API设计决策

通常，分析混合API选择的第一步是评估应用程序的工作流量。避免陷入现有组件模型中；API设计应当总是以业务流程流作为开始环节，最好是从企业架构模型中选取流程。要做到这一点，我们需要在每一个业务流程之间都添加一种数据库访问流。这种结合会让你决定在混合模型互动活动中信息的流动方向。

从已有的经验来看，当一组独立组件负责访问数据库信息时，或者至少是集中而不是分散在整个工作流中的组件负责数据库访问时，云应用就会成为最有效的工具。当组件转移动中时需要跨越混合云模型的数据库访问边界，那么着将会有时间的限制，但是，这种情况下有时会出现性能问题。通过数据库集中访问设置，会形成一种总结应用程序数据库需求的虚拟记录。

考虑工作流

架构师在寻找支持Web前端模型的工具时就应该构建一种在云中可以支持用户交互活动以及 GUI 的应用程序。Web前端可以通过数据接触到应用程序匝道组件，随后建立数据库内容。多数访问核心任务数据库的应用程序都会运行这种内部组件。

在混合分析模型中也可以采用同样的方法。在大多数情况下，应用程序云部分将会接收和验证查询内容，然后，将其分派到应用程序匝道中，在这里可以访问到真实的数据库。如果，在云或者一些查询中，可能托管抽象的或者概述性的数据库时，那么云DBMS与核心DBMS之间独立的查询语句将会由分析应用程序的云部分完成。

在多种决策中进行抉择

这些持续支持云全部内容和匝道组件的API需将全面的用户需求信息发到匝道组件中，并反馈需求结果，这样API可以得到较佳的RESTful。一旦匝道组件达到阀值时，我们将会采取两种策略——通过交易数据模型保护其他组件或者选择保存模型中的一部分。

在后一种情况下，缓存DBMS将会被存储在该模型中，从而日后具有可用性。在前一种情况下，可以一直采用RESTful API，但是在需要支持特殊数据元素的每个组件中，最好是考虑使用SOA模型，这样可以获取到每个组件所需的数据文件。

混合云簇模型较为复杂，因为其假设为，组件可以进出基于当前负载和数据中心资源的云。在这一个模块中，状态管理十分重要，之前关于交易数据模型的探讨也可以应用到状态管理中，同时也可以作为多组件案例中分配工作的一种方法。

大多数架构师都认为，如果API是处于RESTful状态，那么动态地移动或者水平伸缩组件实例就会变得非常容易。基于DNS的负载均衡同样能够解决数据中心与云之间的故障转移。如果交易数据中心掌控了某一状态，那么为了达到运行的条件，就不得不将该状态传递到组件案例中。如果数据模型不是特别大，那么最好是选取整个模型而不是挑选个别参数进行检验。如果被移动或者具体化后的组件存储在不同的组件模型中，那么该组件也许就不会具备访问数据模型的权限。

在设计混合云API时，最好要记住，应用灵活性以及资源有效性都可能引起这一模块的变化。也就是说，最佳的方案是具有高度灵活性的，同时，独立的交易数据模型可能是实现灵活性以及降低API变化风险的最佳途径，而且，这种变化是需要耗费昂贵的成本和大量的时间才能够完成的。