随着微服务的越来越流行,越来的越多的公司开始实行微服务架构,相对于单一应用架构,微服务将复杂性拆分并且打散到一个个粒度更加细分的应用中,极大了减少了开发中单个服务的复杂性,开发人员只需要面向专注单一业务场景编程,从技术开发角度,单一服务代码量上减少很多,从业务角度上,业务复杂性的降低降低了需求的沟通成本,然而,整体业务复杂性依然存在,当我们需要接入或者依赖其他服务时,通常作为接入方来说,我们不需要深入了解服务提供方的业务,此时API成为了开发人员间的沟通语言。良好的API设计,能极大的减少沟通成本,甚至有时候可以代替文档,尤其是对于基础性服务来说,服务的可扩展性有时候体现在API的可扩展性,我曾经参与过一个基础业务微服务的业务升级,由于旧版本的API划分不够清晰,部分API存在重复性,后面不得不对大部分API进行重构(替换为新版本的API),仅仅在服务消费方升级这个阶段就持续1-2个月之久,在这个过程中也不断对API设计中存在的一些问题以及应该遵循哪些原则进行了一些思考。
API先行
在敏捷开发的大浪潮下,产品上通常要求快速迭代,面对一个新的需求,如果需要开发新的接口,通常在表结构完成设计后,开发人员就需要完成API设计并交付消费方(即服务的调用方或者依赖方,文中其余部分均表示此含义),在技术联调前,消费方可以Mock接口来完成调试。所以通常来说,API先与服务交付,之后再完成编码,测试,调试等工作。当然,由于可能在需求细节,技术实现方面可能在实现过程中发现需求需要调整,或者API接口的调整,最初版本的API可能是不成熟的,导致我们经常在API调整或者演化过程中在API维护方面存在很多遗漏,所以API最初交付后的维护是持续性的工作。
API设计常见问题
在我们设计API过程中由于存在经验的缺失,或者由于多次交接,或者由于经历多次需求的变更,导致服务的API慢慢腐化,带来以下常见的问题。
API设计的原则
简单且专注
良好的注释
扩展性
唯一不变的是变化,接口也会一直演化,我们不提倡过度提前设计,但是在演化过程中要始终保持接口的可扩展性。
兼容性
完善的测试
重视文档
良好的注释和文档能减少大部分和服务消费者的沟通工作,也避免了一些错误的接口调用。没有人希望每次都需要在IM工具上浪费大量口水或者需要当面询问才知道如何正确使用API,也没有开发者愿意每天重复回答如何调用提供的接口。对于接口文档,可以是采用Javadoc这样简单的方式,也可以是通过wiki来集中管理,可以是markdown文档,也有很多的开源系系统例如Swagger,yapi,eolinker等;微服务的架构极大的加强了沟通的成本,这也是微服务架构的一个弊端,但是合理的利用 工具 可以减少不必要的沟通。
总结
作为微服务之间的桥梁,API设计和维护是微服务架构中很重要的一个环节,每个开发人员不仅仅需要良好的代码规范,也需要建立并遵守API设计规范。API设计能力在微服务架构中作为软实力的一个部分,需要开发人员有一定的设计经验的积累,同时,只有不断的思考和总结才能更加深入的理解。
逆锋起笔
是一个专注于程序员圈子的技术平台,你可以收获最新技术动态
、最新内测资格
、BAT等大厂大佬的经验
、增长自身
、学习资料
、职业路线
、赚钱思维
,微信搜索逆锋起笔
关注!