一 摘要

在日常的开发中，我们经常会接触到服务方、服务商、服务提供方这类的角色。简单来说，就是提供服务让我们使用。本篇会展开思考，如果我们作为服务提供方，那么应该做到哪些，才能保证服务的提供是“好”的。

二 概念

2.1 什么服务

这个“服务”，可能是具体一点的资源对象，也可能是一些业务能力的抽象，还可能是支持类的能力提供。

2.2 服务对象

服务对象，可以理解为是我们的“客户”。大家有过相关经验的都能够理解，当面向不同的客户时，我们提供的内容或提供方式会有所差别，这是由客户本身的特性和需求决定的。例如，不同行业的客户需求千差万别，大中小客户在沟通方式、对接能力、回款能力等诸多方面都相差悬殊，如果我们要覆盖最广泛的用户，那么就必须做好抉择：是只提供共性需求，还是也要支持定制化得部分？

当然，比较理想的考虑是支持定制化，这可以扩大能力覆盖的客户范围，可以争取更多的项目和资金。但必须要注意的是，过多的定制化需求会导致无法聚焦，差异越大，共性的东西可能就越少。极端情况，几乎所有都是定制化开发，只有很少的一部分可以复用，那么必然很难沉淀产品，同时也会极大地占用沟通、开发资源，疲于应对。必须在二者之间做好取舍（至少是比例上）。

2.3 怎样提供服务

几个核心问题：1）提供形式，产品 or 功能接口？2）功能列表；3）计费方式；4）安全保障；5）交付时间 &付款方式。

这些，其实在阿里云、华为云、高德地图 API 等服务提供方已经有非常经典的提供模式。特征鲜明的官网，完善的使用、计费、说明文档，简单便捷的示例说明，以及最佳实践和问题解答/工单系统，从上述多个角度确保了服务提供的完整和质量保障。

三 开发人员之间的服务提供

以上更接近于通用产品/服务类型的实现。作为技术开发/管理者，让我们把视角拉回到开发人员，当 A 服务需要 B 服务提供一些功能时，通常是采用服务接口的形式进行调用。如何做好服务提供？

3.1 真的很简单吗？

相信很多人会不假思索地回答，这有什么难的，提供接口文档就好了，需要再拉群沟通，必要时拉会当面对接问题。

没错，确实大家都是这样做的。但效果真的都很好吗？显然不是！经历过不只一个项目，收到的接口文档并不完整，数据格式与环境中看到的并不相同，联调环境并不稳定甚至经常挂掉，问题职责不清。。 一系列问题都直接影响着使用者的对接进度和工作心态。除了一部分情况是使用方能力导致的以外，更多情况是服务提供方并没有做好“服务”者的职责。

3.2 接口文档

接口文档是比不可少的，但应该如何组织和描述，却并不简单。简单的接口地址、请求方式、参数说明、返回值格式 &示例，功能说明，这些都属于必须包含的内容，但还远远不够。

很多提供方是站在自己的角度来组织和描述的，而并没有站在使用者的角度。一定要先明确，我所做的服务，是要给他人使用的，这点至关重要！

3.3 环境 &资源

服务的环境要确保稳定，在联调、测试时服务频繁中断是让人无法接受甚至崩溃的。不稳定的服务其实并不应该对外暴露。只不过现实中由于排期所限，经常会有并行开发和 mock 联调的情况，所以不得不接受。但稳定性保障其实应该是必备的。

3.4 完善的更新、变更通知机制

服务发布后也会有迭代更新，如果是无关功能的优化，那么对使用方的影响还比较小。但如果对接方式、功能、参数/返回值这样的调整，不及时做好通知和及时修改，必然会给使用方带来损失，而也会直接影响提供方的信任程度。

尽可能做好兼容，确保用户无感知的升级；如果不得已有影响到客户的重大调整，那么必须及时告知，并协助限期完成修改，避免调整后影响使用。

四 总结

做好服务提供方，还不止文中提到的这点内容。这里只做为抛砖引玉，希望引起大家的深入思考。

如果想尝试自己评价服务的好坏，不妨试着暂时忘掉对服务的历史了解，站在一个第一次接触并准备使用服务的开发者角度，通过说明文档把服务用起来。如果整个过程很顺畅，不存在大的甚至流程上的问题，那么就可以认为服务做到了很好的提供；但如果不是这样，就需要反思在哪里有缺失、歧义之类的问题了。