关于API和微服务最重要的三个问题

API也就是我们常说的应用程序接口，是以编程语言提供的结构，允许开发人员更容易地创建复杂的功能。它们抽象出更复杂的代码，并提供一些简单的语法来使用。

而微服务架构是一项在云中部署应用和服务的新技术。微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配。微服务作为一项在云中部署应用和服务的新技术已成为当下最新的热门话题。但大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，我们认为API应该是重点。

本文主要讲的是如何让企业高管了解API和微服务的价值，如何将单一的遗留应用程序转换成微服务和API以及如何围绕API和微服务组织团队？

一、如何让企业高管了解API和微服务的价值？

主要有两种方式。首先，一般很少有企业高管了解API和微服务平台的投资商业价值，因此很少有人能够成功地理解API和微服务架构的抽象价值。尽管如此，大多数人还是都能理解相互依赖的商业投资策略。在这种情况下，需要高于单个项目的分析，来确定可能推动业务变化的已知业务变更计划组合和激发这些变化的行业压力。评估并比较在有或者没有API和微服务的情况下，响应这些变化的成本和时间价值。

换句话来讲，要将对话提升到项目组合级别，因为这是API和微服务协同效应所发挥出最大影响力的地方，并以业务变更投资术语（而不是架构价值术语）进行对话。其次，一些业务计划蕴含内置的API价值，可以把这些价值单独出售。例如，如果一个公司的目标是改进跨多个渠道的订单履行过程(例如，移动、网络、信息亭、直接合作伙伴集成)，那么无论订单来自哪个渠道，API都是实现一致的客户体验和业务流程结果的最佳技术方法。在这种情况下，API应该是建议的默认架构，而不讨论非API的方法。

二、如何将单一的遗留应用程序转换成微服务和API？

我们必须注意不要过快地跳到转换遗留应用程序策略上。为了说明这一点，它有助于明确区分API和微服务。对于API，我们可以利用各种可用的遗留系统和应用的现代化和集成 工具 进行快速构建业务API，从而访问遗留应用程序中隐藏的业务事务和数据。另外可以避免整体结构转换的高成本，并且通过大幅改进用户和员工的体验，来满足数字转换的需求，更不用说基于API的业务流程优化和B2B集成。尤其是当遗留下的业务规则和数据在很大的程度上与业务的未来需求相保持一致时，这种方法最能体现出价值。

但是在业务动态需要对传统应用程序内部进行更改时，那就需要剥离遗留应用程序“块”并将它们转换为微服务架构了。每个“块”将会被提供一组紧密的业务功能（即单个业务功能）并提供与该功能相关的业务API。渐渐地，每个“块”背后的遗留代码将被模块化、可单独部署的微服务组件所取代。

三、如何围绕API和微服务组织团队？

API和微服务团队的主要组织结构应该围绕业务功能进行展开。上一个问题已经回答了如何将遗留应用程序划分为业务功能“块”，那么每个业务功能（例如，订单履行，计费，库存等）都将成为团队交付的软件产品（单个团队可能拥有一项或多项业务能力），团队负责开发由业务功能提供的服务的业务API的同时，还负责将这些API的业务能力转化为微服务。其优势在于，使用API的其他团队不必关心业务API是否由微服务、遗留系统和应用集成或者其他任何实现方法所支持，所有这些都是负责业务能力的团队负责。除此之外，每个企业还可以拥有组建API和微服务的卓越中心（或者更广泛地说，用于云原生解决方案体系架构），从而建立协作设计和治理模型以促进并优化业务API业务的一致性。最后，企业可以组建不同类型的专业技术API团队，例如集成或基础架构API团队。