根据CA公司2018年发布的研究，现代化应用架构对传统架构有三个改造方向，分别是API，微服务化和容器化。容器化很好理解，就是在虚拟化的基础上，将上层应用进一步与底层操作系统和依赖的Kernel解耦，仅裹挟应用运行必要的动态链接库，运行时组件形成定制化容器。这在另一个层面上是对有限的标准化的PaaS平台做了适应性拓展。
而API和容器化之间的关系就比较密切了，他们更贴近业务模式，在引入今天的正题之前，我们简单回顾下这两个趋势的定义。
微服务，即微服务架构，是将传统应用以业务域（Business Domain）单位改写成一系列自治服务集合的一种架构风格。在这个架构中，每个微服务都可独立完成单一业务功能。
业务领域的概念我们之前也提过，以电子商务为例，用户旅程从注册开始，到产品浏览、购物车、购买、支付、物流、交易关闭、评价一直到售后，按主体分可分为用户域（注册、支付账户、物流）、商品域（产品列表、评价）和交易领域（交易单号、交易状态、交易关闭），而业务域就是反复关联这些主体的各业务环节，以下是销售环节和客服环节的业务边界和通过客户和产品进行的主体链接。而其环节内的各个独立的操作单元就是微服务。
而API（应用可编程接口）是为处理客户请求将多个应用串联起来的一种形式，客户请求以调用方式来分的话，可以有增删改查（创建信息、读取信息、更新信息和删除信息）四种类型。
下面进入正题，API是如何与微服务结合，提升应用架构的效率的呢？一般来说每个微服务发布一个API接口，这些接口可以是内部链接各个微服务的，也可以通过API网关将服务发布到外部供客户进行信息的增删改查，后端当然可能会经过多个内部API的编排，因此从某种意义上讲，API也是发布端的微服务。
同时API也兼容传统的应用发布，它不仅弥合了微服务和传统系统之间的差距，并且还使得构建和管理微服务变得更加容易。通过制定API策略，公司可以将微服务提供的功能公开为产品，这可以同时带来内部和外部的业务价值。标准化的、产品化的API还有助于减少SaaS应用程序与传统IT系统之间构建点对点集成的相关成本。这使得组织可以根据业务需求快速插拔微服务，而无需大量定制化的开发。API可以在整个企业中以标准化方式为流量管理和监控、日志记录、审计和安全等提供标准化的机制，同时保留业务所需的灵活性。
这些管理良好的API还可以实现微服务的重用和可发现性。随着开发团队构建了可能对更广泛的消费用户有益的微服务，API接口使它们可被发现。然后，这些微服务可以向更广泛的受众开放 - 内部或外部– 并且作为可重用的功能进行管理。
长按，识别二维码，加关注
