微服务架构正在各种规模的企业中获得广泛的关注;它们是目前设计软件应用程序最流行的方法之一。与传统的单体应用开发方法相比，微服务架构可以更快地更改和开发新的应用程序，因此可以提供更高的敏捷性。 Netflix，Google，亚马逊和许多其他IT企业已成功地采用此架构，并引导其他人模拟这种模式。
对于大多数企业而言，微服务架构的采用和过渡将是一个渐进的过程，基于微服务的应用程序将与传统的应用程序共存和交互。微服务必须与传统应用程序、现有系统和业务流程，以及当前的企业运营，以及合规性的要求同时存在。
此外，微服务在带来的好处的同时也引入了一些负面性，例如服务蔓延，复杂性增加，以及增加冗余工作的风险。企业和组织需要微服务和API共同有效地实施IT架构。
对于许多公司而言，挑战在于学习如何将微服务架构与企业中已部署的众多其他架构模式相结合。在控制复杂性的同时，管理微服务提供的速度和灵活性的一种方法是采用API。制定一个整体的API策略将使得微服务更易于管理，并允许它们与现有的遗留系统共存，而不是生活在远离这些关键系统的围墙花园中。将微服务架构与整体的API策略相结合是获得微服务带来的优势的有效方法，同时可以有效地限制以上提到的缺点。
微服务和API如何协同工作
API曾经是底层的代码编程接口，但现在它们已成为产品本身，遵循一定的API标准，例如REST，使他们对开发人员更友好，并具有更强的管理和治理能力。 API提供商们现在互相竞争，以引起开发人员的注意。并且，API经济，一个围绕着API使用者和API提供者之间价值交换的新经济模式正在日渐增长。
对API使用方法的变化也改变了他们的技术要求。API现在需要复杂的门户，这样开发人员才能发现并测试它们。同时也需要提供注册和支付API调用，以及限制API使用的各种机制。并且，由于API是对外部公开的，它们需要通过API网关提供强大的安全防范能力。当所有这些功能结合在一起时，便形成了API管理这样一类新的解决方案，为越来越有价值的业务资产提供控制，可见性和治理的功能。
所有对互联网上公开API（以及它们创造的价值）的关注都提出了一个问题：是否有办法为企业内部的API实现相同的价值？现在API管理技术已经变得更加成熟， 现在可以实现数据源，服务和应用程序的 发现和自助 服务。 这使得整个企业内更多的团队能够以受控和可见的方式开发软件，扩展IT团队的生产力，并创建内部的API经济。
使用微服务架构，内部API经济的价值甚至更高，因为随着微服务创建更多数据端点，控制连接的难度就越大。试图在所有这些端点之间创建点对点的连接将会是灾难性的。在一个像微服务架构这样的高度分布式环境中，开发一个整体的API策略将会至关重要。
许多公司采用这样一种API策略来开放所有的服务（无论他们是基于微服务还是是单体架构；是在本地部署还是基于云端部署）：由API主导的连接。 这种以API为主导的集成方法是一种明确的整体策略：它使用不同功能的，可重用的API来开放服务，并且使用API来组合和重构出不同类型的服务，以创建易于更改和演进的业务需求。
随着微服务架构的应用变得更加普及，尤其对于具有传统IT技术栈的老牌组织而言，集成所有这些服务并从中获取价值的问题变得更加重要。 这就是实施以API主导的系统集成策略，对于使微服务架构在企业内部生效的重要原因。
API不仅弥合了微服务和传统系统之间的差距，并且还使得构建和管理微服务变得更加容易。通过制定API策略，公司可以将微服务提供得功能公开为产品，这可以同时带来内部和外部的业务价值。
标准化的、产品化的API还有助于减少SaaS应用程序与传统IT系统之间构建点对点集成的相关成本。这使得组织可以根据业务需求快速插拔微服务，而无需大量定制化的开发。API可以在整个企业中以标准化方式为流量管理和监控、日志记录、审计和安全等提供标准化的机制，同时保留业务所需的灵活性。
这些管理良好的API还可以实现微服务的重用和可发现性。随着开发团队构建了可能对更广泛的消费用户有益的微服务，API接口使它们可被发现。然后，这些微服务可以向更广泛的受众开放-内部或外部–并且作为可重用的功能进行管理。
