模块可测试

要想能自动化测试，被测代码首先必须要可被测，可被测包括两方面，一个是支持获取状态，一个是支持操作

获取状态情况包括

单独查询: 包括之前有异步操作后通过查询获取操作状态，比如查询操作是还在进行中，还是已经结束，如果已经结束则结果如何
同步操作返回

为了达到高自动化率，我们总结了如下要求

请求有唯一GUID标识

系统在高负载时每一秒都可能有很多的请求，另外调用方和服务提供方的时间也很可能不同步，为了减少定位请求的时间，我们要求每个请求都有一个唯一GUID标识，由调用方提供，这样当调用失败时，业务提供方根据GUID可以很容易定位到相关log，甚至可以用这个GUID来过滤log，在高并发时候很有必要

请求有明确清晰结果

调用结果不应该是简单的0成功，-1失败，而应该是具体的错误码err_code和错误消息err_msg，错误码同时负责区分报错模块，比如5******代表模块A，6******代表模块B，错误消息则负责提供更可读的信息，比如ERR_CONNECT_TO_MYSQL_FAILED, ERR_CALL_XXX_TIMEOUT等

第一跳服务提供者保证结果清晰，首先它应该给出接口最大延迟，其次如果调用超时它也应该把结果写入log，不管超时与否最终的错误码应能明确的标识如果失败了是哪个模块导致的，并且log中应该有具体请求的参数、期望的结果、实际的结果，方便分析和重现

支持distributed tracing

https://opentelemetry.io/docs/concepts/signals/traces/

使用Jaeger等提供

服务标准应该尽量清晰

比如最大延迟，指定配置指定环境下的并发量，可以按照测试结果给出一个初版

异步操作可查询

异步操作应提供查询手段，比如查询操作是还在进行中，还是已经结束，如果已经结束则结果如何

提供Metric信息

比如每秒请求数，平均延迟，成功率等

清晰文档

各模块应提供清晰文档，使使用方知道如何使用，可期待的结果

总的说就是记录有意义的信息

请求有唯一GUID标识​

请求有明确清晰结果​

支持distributed tracing​

相关操作可关联​

服务标准应该尽量清晰​

异步操作可查询​

提供Metric信息​

清晰文档​