如何做好上下游对接 - HelloWorld开发者社区

自己的模块，常常要对接上下游，如何在对接的过程中，保证正确性呢？
一般和上下游对接的有两种方式：

一：接口对接

在接口对接中，需要注意下面的点。
1，首先和上下游约定接口的功能是什么，这往往和承载的业务有关系，需要提前在产品宣讲阶段+产品评审阶段定义清楚，每个接口预期的功能都应该准确的描述在接口注释上。

2，约定好接口的功能后，紧接着就是约定好接口的入参和返回值数据结构，确定参数数据结构中哪些是必传的，哪些是不必传的，他们的传值范围是什么？
确定返回值的数据结构是什么。什么时候失败，什么时候成功等等，都需要定义清楚。这里比较推荐常用的yapi管理接口。
另外注意字典维护，比如sex中的"未知" "男" "女"，是统一使用中文表示，还是0 1 2编码表示，还是英文表示。如此这类的，都要标准化。另外字段名称也尽量统一。
对于接口返回个人建议使用下面这种通用的数据结构

public class Message<T> {
 private boolean success
 private String errcode
 private String errmsg
 private T data

public Message(boolean success,String errcode,String errmsg,T data){
this.success=success;
this.errcode=errcode;
this.errmsg=errmsg;
this.data=data;
}

// 返回成功
 public Message success(T  data){
  return new Message(true,"0","",data);
 }

// 返回失败
 public Message fail(String msg){
   return new Message(false,"400","param is illegal",null);
 }
}

对于返回成功还是失败，这里有一些案例值得思考

pubilc User findOneUserById(Long userId){
// 这个userId应该是之前系统生成的，那么根据这个userId，在数据中应该一定能查到数据，但如果查不到呢？此时应该返会失败。
}

pubilc User findOneUserByName(String selectName){
//根据selectName去搜索的时候，在数据库中可能查不到，这种情况是正常的，因此要返回成功。提示没有数据。
}

还有比如根据用户手机号作为唯一标识，插入用户信息，如果第一个请求已经插入成功，当第二个请求携带相同的参数插入时，接口是返回成功，还是返回失败？这在上下游对接的过程中比较重要

3，接口处理
3.1在接口impl层面的第一件事情，先打印请求参数日志。在接口实现的关键点也需要打印日志。这样方便后续定位问题边界。

3.2紧接着第二件事就是按照约定的数据结构进行参数校验，对错误的参数请求做好拦截，防止他们捣乱系统，破坏数据。这一点可能很多人忽略，但其实是最重要的

3.3对于非必传参数，接口应该如何处理，也需要明确，这一点一般反应在该接口在不同的场景中使用。

3.4 处理异常，不要使用抛异常的方式退出某个方法，并毫无保留的把异常信息传递给上下游，除非方法有捕获异常，并且知道怎么处理。

3.5 明确返回值和错误信息：如果处理成功返回success=true。如果失败，不能仅仅返回失败就完事了，必须在返回信息明确的告知上下游是什么原因导致这次请求处理失败，是参数校验不通过，缺省哪些值?还是要操作的数据，在数据库中不存在？等等。

3.6 接口开发完毕，对接口进行单元测试，我个人认为这是很重要的一步：根据步骤1的注释，必须按照这些预期功能进行测试，如果预期提供的功能，在单元测试中成功通过，那么说明该接口提供的功能基本上是可靠的，可以和上下游对接了。但这还不够，单元测试的参数最好分各种各样的情况，如果你模拟的参数情况比真实用户发出的参数组合多，并且返回都按照预期响应，那么该接口可以说是合格的了。这样，你就可以拍着胸脯说没有bug了，可以去开发另外的接口了。

一般来说，接口对接做好上面就足够了，但是还不够！接口设计的时候还必须考虑以下事情：

a，幂等：也就是说相同的请求来了（可能是多线程并发请求，也可能是重复请求），该接口如何实现这一点，这一般反应在增删改等接口。
接口该怎样支持幂等？一种方式是利用数据库的唯一索引来。还有利用分布式锁（为什么不用jvm锁？）

b，分布式事务：比如该接口是一个扣减库存的接口，那么在和上下游对接的过程中，需要注意如何处理分布式事务。谁负责解决分布式事务？
在众多的项目经验，我得出一个结论，分布式事务，一定是利用最终一致性+ack的思想解决，两阶段，三阶段不适合大规模的系统

c，并发：这可能是最容易忽略的，很多神奇的问题，都是由于这个而找不到原因，跟个鬼一样。特别是在soa和微服务架构，往往会利用k8s部署多个pod情况下。所以对于提供的写操作接口，一定要研究有没有并发问题。如果有，往往是利用分布式锁解决(除非只运行一个pod)

d，性能：有些业务处理可能比较复杂，一次响应需要太久的时间，这对使用者来说，都是一次不好的体验，在上下游对接中，我们提供的接口可能仅仅是整个业务中的一环，因此需要注意接口的性能。
有书籍说"如果能够正常运行，就不要进行性能优化，否则会带来灾难"，这句话不全对。
首先需要分析是慢在哪里了。其中我觉得需要快速得出结论，是否因为数据组织，系统架构不合理而导致查询本身就很慢，如果是，那么就需要快速的商讨对策了。为什么这一点很重要？如果在接口上线一段时间才发现这个问题，再去调整数据，调整系统架构那往往是灾难。
如果不是这些问题，那么可以建一些todo，或许是加缓存，或许是算法优化等等

e，请求量限制：
有的时候，可能时间很紧迫，上下游随便扔过来一个查询需求，如果没有时间做好需求调研，那么功能实现后，一定要加上限流的策略。这些组件有很多比入sentinel。一定要保护好自己的系统。

f，模块：
相同功能的接口，最好放在统一的模块中进行管理