前后分离架构中所需要的契约!

阳光穿透心脏的1/2处 2022-07-10 20:45 187阅读 0赞

#### 前后分离　 ####

前后端分离已经是业界所共识的一种开发/部署模式了。所谓的前后端分离,是指后端开发人员只需要定义出接口就可以了，而不需要在编写JSP等东西,而前端开发人员也只需要专心做界面，需要数据的地方直接调用后端开发人员定义的就行了。  
　　这样，前后端就分别有了着自己的开发流程，构建工具，测试等。做前端的谁也不会想要用Maven或者Gradle作为构建工具，同样的道理，做后端的谁也不会想要用Grunt或者Gulp作为构建工具。前后端仅仅通过接口来协作，这个接口可能是JSON格式的RESTFul的接口，也可能是XML的，重点是后台只负责数据的提供和计算，而完全不处理展现。而前端则负责拿到数据，组织数据并展现的工作。这样结构清晰，关注点分离，前后端会变得相对独立并松耦合。　  
　　但有一个很头痛的问题。比如在最后需要集成的时候，我们才发现最开始商量好的数据结构发生了变化，而且这种变化往往是在所难免的，比如:deliveryAddress字段本来是一个字符串，现在变成数组了（业务发生了变更，系统现在可以支持多个快递地址）；price字段变成字符串，协商的时候是number；用户邮箱地址多了一个层级等等。这些变动在所难免，而且时有发生，这会花费大量的调试时间和集成时间，更别提修改之后的回归测试了。  
　　归根结底，**还是前端或者后端感知到变化的时间周期太长，不能“及时协商，尽早解决”，最终导致集中爆发。怎么解决这个问题呢？我们需要提前协商好一些契约，并将这些契约作为可以被测试的中间产品，然后前后端都通过自动化测试来检验这些契约，一旦契约发生变化，测试就会失败。这样，每个失败的测试都会驱动双方再次协商，有效的缩短了反馈周期，并且降低集成风险。**

#### 契约测试 ####

谈到了前后端分离，那么在所难免，会遇到一些集成的问题：一拨人在全心全意的进行前端开发，另一拨人在心无旁骛的做后端开发，那么谁应该为集成买单呢？在现在这个持续集成、持续交付的年代里，我们应该如何去保证双方不会分道扬镳、越走越远呢？  
　 所以，在一开始就定一个契约就成了迫在眉睫的事情，双方就API相关的内容，包括路径、参数、类型等达成一致，当然，这份契约并不是一旦创建就不能修改的，而且，如果一开始没有设计好，很有可能会频繁的修改。这个时候，要让双方都能够实时的跟踪最新的API就成了一个难题。还好，有了Swagger后，我们可以方便的做契约测试。  
　 简而言之，我们需要商定一些契约，并将这些契约作为可以被测试的中间格式。然后前后端都需要有测试来使用这些契约。一旦契约发生变化，则另一方的测试会失败，这样就会驱动双方协商，并降低集成时的浪费。  
　　一个实际的场景是：前端发现已有的某个契约中，缺少了一个address的字段，于是就在契约中添加了该字段。然后在UI上将这个字段正确的展现了（当然还设置了字体，字号，颜色等等）。但是后台生成该契约的服务并没有感知到这一变化，当运行生成契约部分测试（后台）时，测试会失败了 — 因为它并没有生成这个字段。于是后端工程师就找前端来商量，了解业务逻辑之后，他会修改代码，并保证测试通过。这样，当集成的时候，就不会出现UI上少了一个字段，但是谁也不知道是前端问题，后端问题，还是数据库问题等。  
　　而且实际的项目中，往往都是多个页面，多个API，多个版本，多个团队同时进行开发，这样的契约会降低非常多的调试时间，使得集成相对平滑。  
　 首先，我们先假设我们已经有了一份契约，可能是基于JSON格式的，有可能是基于XML格式的，这都不重要。然后，前端会根据这份契约建立一个Mock server，所有的测试都发往这个Mock server。有两方面的原因：一是这个时候可能后台的API还没有开发完成；二是有可能因为网络等其他方面的原因导致直接调用真实的后台API会很不稳定或者很耗时。到这里，可能有人就要说了，如果后台的API实现和之前约定的并不一样，怎么能保证到了集成的时候双方还能很顺利的集成呢？其实这个问题并不难，只需要让前端的测试定期连接真实的API执行一遍就能尽早的发现差异性。比方说，在我们平常的build pipeline上添加一个job，让这些测试每天在午夜里连着真实的API执行。如果，第二天发现这些测试有的失败了，那么就需要和开发后台API的人员进行一次沟通了，很有可能由于真实的业务逻辑发生了变化，API在实现的时候，已经和之前的契约不一致了，如果是这样，那么相应的测试和契约定义就需要更新以满足最新的业务需求。

#### 总结: ####

目前开发过程中存在的问题

联调成本过高,要双方开发到某一阶段后放在同一个环境上才能进行，要同时把握双方的进度，造成资源和时间上的浪费。  
对于接口的变动把控相当困难。由于接口变动是普遍存在的，尤其对于调用关系复杂的接口，一旦发生变动，如果没有一套机制进行控制，验证的成本巨大。更不必说持续集成了，只能成为空谈。  
契约测试能给我们带来什么  
通过使用契约测试，接口调用双方协商接口后就可以并行开发，并且在开发过程中就利用契约进行预集成测试，不用等到联调再来集成拉通接口，一旦成熟，在保证质量的前提下，联调的成本可以减低到几乎为0。

参考: [http://www.cnblogs.com/whitewolf/p/4686154.html][http_www.cnblogs.com_whitewolf_p_4686154.html]

[http_www.cnblogs.com_whitewolf_p_4686154.html]: http://www.cnblogs.com/whitewolf/p/4686154.html