在正文开始之前，我们来看一个日常生活场景，咖啡自动售卖机：
第一排，是四个选项：美式、拿铁、摩卡、白咖啡；
第二排，单位是ml，代表产出咖啡的量；
第三排，是否加糖；
第四排，是否加奶。
输入以上这四个参数后，自动售卖的咖啡机便会按照要求提供所需的咖啡。当然售卖机还是会根据操作者的人脸或扫码确定其身份信息，做出相应的扣款，或是先付款后操作等处理。这就是一台咖啡机所提供的服务，机身上提供了操作的说明，根据提示输入类型、口味等信息，制造出对应的咖啡。
微服务与 API
咖啡机提供的是生活服务，而我们一直以来的话题：“微服务”，则提供的是软件服务。一个软件服务的使用，需要输入参数：如第一个参数代表了类型，第二个参数代表了返回的数量，第三个、第四个参数代表了是否需要加某些规则；同时也需要身份信息：如报头加入消费者名称，加入认证信息等；当然还需要有返回，也就是计算或者处理的结果返回。这就是软件服务提供的能力，也是软件服务的API。
在微服务的架构提出之前，行业内首先提出的是服务化，毕竟服务能力的封装、自运行，可比自己编码实现要快捷、低廉很多。在服务化的基础上才有了微服务，微服务就是其基于服务化将应用程序构造为一组松散耦合的服务。
因此，微服务基于 API 作为服务能力的提供，也是服务间消费的规则和方式。信息标识认证的方式、参数传递的类型，格式返回的方式，这都是API定义的。
API
API 的定义是应用程序编程接口，而在服务化的场景中，API 是应用程序间的访问接口，即服务提供的行为合同。那么在微服务的场景中，API就是微服务间获取信息的契约。
微服务架构中服务间调用关系错综复杂，程序提供的服务能力可以被其他任意服务消费和使用，这也是建设微服务的一个优势。服务能力的复用，可以在某个业务领域内被消费，也可以被网络区域外的服务所依赖，也可以是整体企业对外的能力开放，其本质归根结底都是 API 的调用。
当然，还有调用中的信息认证，调用允许/拒绝的控制，应对大流量时限流控制，熔断控制，批处理方式等等，全都是 API 管理内容。有了这么细则的控制，对于 API 的监控也尤为重要，因为很多控制的数据皆是从监控记录而来。
因此，API 才是微服务化建设中最为核心的管理对象，而且从整体微服务化建设的角度出发，在开发态、运维态、运行态均需要关注对 API 的管理。
开发态：API 管理
之前提过微服务的建设，从横向上看，跨越微服务的开发态、运维态、运行态，那么在开发态，API 设计是先于服务开发的，因此 API 管理应该在开发态就已经开始记录和调试。
API 包括请求方法（GET、POST等）、请求参数（请求头、请求体）、响应内容等信息，对于 API 接口文档的管理，应该是当做微服务间调用的契约，在服务调用中，指导消费服务的使用。
API 管理可能在不同的阶段会有不同的运用，在开发阶段可以帮助开发人员快速的对 API 进行设计和调整，在测试阶段方便测试人员查看 API 的用法，也更有利于知识传递和工作交接；在运行阶段，API 的说明也会便于其他应用或系统对该服务的调用。
运维态：API 变更
微服务场景下，敏捷是第一要务。因此，服务可能会经常升级、变更，也难免会有 API 的变动和更改。既然 API 是微服务间的契约，那么 API 的变更也就如同契约的变更，将会对所有消费者产生影响。
因此 API 的变更需要慎重，变更之后也需要做详细的变更说明以供消费者参阅，甚至需要有固定的流程审批。
当然这里也给 API 管理提供了一个要求，就是要支持多版本的管理，以满足持续集成、持续发布，以及变更的信息。
运行态：API 治理
运行态下，对于 API 的治理算是细粒度的微服务治理。毕竟微服务化的建设，是企业服务化中台建设的第一步，可不只是调调微服务框架那么简单。
未来在服务化中台中，服务能力均以 API 的方式提供，所有的管理粒度都是 API 接口。因此，对于 API 的治理，才是微服务治理的重点，如 API 粒度的访问控制，API粒度的限流、降级、熔断，API 级别的性能监控信息，API 的调用依赖关系。API 的链路节点信息等等。
当然除了服务间的 API 治理以外，伴随微服务逐渐走进人们视线的 API 网关，更是对 API 的南北向调用的管理和控制。API 网关提供 API 的统一对外能力输出，在真实环境中，也不只是对外能力，也表现在跨网络域、兼容异构框架等等方面，但都是针对 API 粒度的管控和观测。
总结
微服务的建设其管理的核心对象是比服务更细粒度的 API，管理内容包括 API 接口信息的管理，变更的影响，运行的监控，以及流量控制等各个方面。
当然还未提到存量的业务系统，因为非微服务架构提供的接口也非标准协议，这类的系统也是以 API 接口形式提供，并在适当的位置做好协议、报文的转换。存量老旧系统的兼容，将会在下一期文章中做详细介绍和分享。