开发人员

• 遵循 REST

• 使用 HTTP/HTTPS 作为服务的调用协议

• 将服务的行为映射到标准 HTTP 动词

• 使用 JSON 作为进出服务的所有数据的序列化格式

• 使用 HTTP 状态码来传达服务调用的状态

为什么 JSON 用于微服务？

• 与其他协议（如基于 XML 的 SOAP（Simple Object Access Protocol，简单对象访问协议））相比，JSON 是非常轻量级的。

• JSON 易于人类阅读和使用。

• JSON 是 JavaScript 中使用的默认序列化协议。

但是，其他机制和协议能够比 JSON 更有效地在服务之间进行通信。

• Apache Thrift 框架允许你构建使用二进制协议相互通信的多语言服务。

• Apache Avro 协议是一种数据序列化协议，可在客户端和服务器调用之间将数据来回转换为二进制格式。

如果你需要最小化通过线路发送的数据的大小，建议你查看这些协议。但是根据经验，在你的微服务中使用直接的 JSON 就可以有效地工作，并且不用在你的服务消费者和服务客户端之间再插入一层通信用来调试。

在深入编写微服务之前，要确保你（以及你组织中的其他可能的团队）为想要公开的端点建立了标准。应该使用微服务的 URL（Uniform Resource Locator，统一资源定位器）来明确传达服务的意图、服务管理的资源以及服务内管理的资源之间存在的关系。

• 使用明确的 URL 名称来确立服务所代表的资源。使用规范的格式定义 URL 将有助于 API 更直观，更易于使用，并且在你的命名约定中保持一致。

• 使用 URL 来确立资源之间的关系。通常，微服务中的资源之间会存在一种父子关系，其中子项不会存在于父项的上下文之外。因此，你可能没有针对该子项的单独的微服务。要使用 URL 来表达这些关系。

  如果你发现你的 URL 很长而且有嵌套，可能意味着你的微服务做的事情太多了。

• 尽早建立 URL 的版本控制方案。URL 及其对应的端点代表了服务的所有者和服务的消费者之间的契约。一种常见的模式是使用版本号作为前缀添加到所有端点上。要尽早建立版本控制方案，并且坚持下去。在若干消费者使用它们之后，再想将 URL 改造成版本控制（例如，在 URL 映射中使用 /v1/）是非常困难的。