微服务API设计实践与思考
随着微服务的越来越流行，越来的越多的公司开始实行微服务架构，相对于单一应用架构，微服务将复杂性拆分并且打散到一个个粒度更加细分的应用中，极大了减少了开发中单个服务的复杂性，开发人员只需要面向专注单—业务场景编程，从技术开发角度，单一服务代码量上减少很多，从业务角度上，业务复杂性的降低降低了需求的沟通成本。

然而，整体业务复杂性依然存在，当我们需要接入或者依赖其他服务时，通常作为接入方来说，我们不需要深入了解服务提供方的业务，此时API成为了开发人员间的沟通语言。

良好的API设计，能极大的减少沟通成本，甚至有时候可以代替文档，尤其是对千基础性服务来说，服务的可扩展性有时候体现在API的可扩展性，我曾经参与过—个基础业务微服务的业务升级，由千旧版本的API划分不够清晰，部分API存在重复性，后面不得不对大部分API进行重构（替换为新版本的API), 仅仅在服务消费方升级这个阶段就待续1-2个月之久，在这个过程中也不断对API设计中存在的一些问题以及应该遵循哪些原则进行了一些思考。

API先行
在敏捷开发的大浪潮下，产品上通常要求决速迭代，面对一个新的需求，如果需要开发新的接口，通常在表结构完成设计后，开发人员就需要完成API设计并交付消费方（即服务的调用方
本，后续如果不对API进行重构，新增加的维护成本将远大于最开始节省的开发成本，例如需要对某个参数增加有效校验，那么我们需要对两个接口的API实现都做修改，而且是重复性的代码，而且我们的影响范围已经成了两个接口，这样影响范围的扩大也带来了更多的潜在风险。

当然在某些场景例如接口逻辑出现大的调整，API重构等情况下，更好的方法是提供新的接口，并推动服务消费者使用新的API,最后慢慢下线旧的API, 这样才能遵循简单和专注的原则。

完善的测试
•单元测试，完善的单元测试能保证代码的健壮性，提前在编码阶段发现并解决潜在的
b ug, 单元测试是一个开发人员的必备能力。

•接口和场景测试，接口测试包含内部逻辑验证，异常输入，并发等场景下对单一接口的验证，如果要对API进行完整的逻辑验证，需要开发人员构造完整的测试数据（通常包含sc he m e.sq I和d ata.sq I文件），尤其是对于基础服务，需要对某些复杂业务场景下联合多个接口完成某个场景的测试，并对中间的数据和输出进行A sse r t确认，这样也会代码一定的测试代码维护成本，需要开发人员进行利弊权衡。

重视文档
良好的注释和文档能减少大部分和服务消费者的沟通工作，也避免了一些错误的接口调用。

没有人希望每次都需要在IM工具上浪费大量口水或者需要当面询问才知道如何正确使用API,也没有开发者愿意每天重复回答如何调用提供的接口。

对于接口文档，可以是采用J a v a do c这样简单的方式，也可以是通过w iki来集中管理，可以是m a rkdown文档，也有很多的开源系系统例如S w agge r, yap i ,e o l ink e r等；微服务的架构极大的加强了沟通的成本，这也是微服务架构的一个弊端，但是合理的利用工具可以减少不必要的沟通。

总结
作为微服务之间的桥梁，API设计和维护是微服务架构中很重要的一个环节，每个开发人员不仅仅需要良好的代码规范，也需要建立并遵守API设计规范。

API设计能力在微服务架构中作为软实力的一个部分，需要开发人员有一定的设计经验的积累，同时，只有不断的思考和总结才能更加深入的理解。