...

想要做好微服务化,这个核心对象要管好

2021-06-26

在正文开始之前,我们来看一个日常生活场景,咖啡自动售卖机:   

第一排,是四个选项:美式、拿铁、摩卡、白咖啡;

第二排,单位是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 接口形式提供,并在适当的位置做好协议、报文的转换。存量老旧系统的兼容,将会在下一期文章中做详细介绍和分享。