微服务为什么需要契约测试

本贴最后更新于 962 天前,其中的信息可能已经水流花落

首先我介绍一下公司的情况。我们使用的是微服务架构,每个部分会负责其中的几个微服务的研发和维护。我所在的部门维护公司的支付服务(billing),这个服务需要依赖其他部门的几个服务。

当用户需要支付一笔订单时,会调用 billing 服务,同时携带很多参数,为了方便,我们先只考虑核心的两个参数:用户 id 和支付金额。

当 billing 接收到用户请求时,会调用其他的依赖服务,用户服务(user)是其中的一个。我们需要查询该用户是否有足够多的余额可以支付订单。

https://gitee.com/looker53/pics/raw/master/img//20210422152812.png

def pay(uid, amount):  
		"""付款"""  
		user_host = app.config.get("user_server_host")  
		user_server = f'{user_host}/user/{uid}/pay'  
		resp = httpx.get(user_server)  
		user = resp.json()  
		if user.get('balance') < amount:      
			return {"msg": "not enough money"}  
		return {"msg": "success", "amount": amount, "uid": uid}

user 被很多服务调用,而 billing 主要想消费它的 balance 字段校验余额是否足够。 user 判断如果是 billing 请求的 /user/<uid> 接口,则把余额给它。其他的消费者请求时返回的数据不太一样。

def user_info(uid, src):  
		"""用户信息"""  
if src == 'pay':      
		return {"id": uid,"balance": 8000}  
elif src == 'manage':      
		return { "id": uid, "age": 19}  
...

某一天用户直接反馈支付出错,但是我们最近都没有对 billing 服务进行任何的修改,显然,这个突发情况可能不是由我们部门引起的。

我们只能紧急的去线上排查问题,通过一系列分析,终于发现是 user 服务返回的余额字段由 balance 改成了 user_balance,其他没有发生任何变化。user 服务修改了代码,却没有通知我们。数据结构的轻微变化导致我们根本拿不到 balance 字段,所以我们的支付服务无法继续。

https://gitee.com/looker53/pics/raw/master/img//20210422153215.png

于是我只能立马给 user 部门发邮件。在微服务的维护过程中,最简单有效的测试工具是邮件。 因为一个服务往往依赖于其他多个服务,又被另外的服务依赖,导致最后的数据流向变得跟蜘蛛网一样。可是当涉及到跨部门协作的时候,沟通起来也并不那么容易。

我们来看一下这么简单的一处改动会涉及到的流程。首先,user 服务收到需求更改,修改代码之后,user 的测试人员会对自己服务进行组件测试,但是 billing 调用 user 的集成测试他们没有办法测,因为他们根本不知道 billing 是怎么消费它提供的数据的。

user 决定通知所有的下游服务,凡是使用了我这个服务,这个接口的,通通发一遍邮件,麻烦你们各自部门测试一下你们的业务,我的 /user/<id> 接口进行了修改,可能会引发你们的服务异常。其他部门收到通知以后,再针对性的测试这个接口。

这些下游部门会因为一处小改动,浪费非常多的时间和资源。为什么呢?billing 服务是受到修改影响的,所以对我们来说是必要的。但是其他的服务虽然调用了 /user/<id> 这个接口,却并没有消费 balance 这个字段,balance 字段的改动对他们不会产生任何影响。但是他们在测试之前是不知道会不会有影响的,是不是浪费时间呢?

还有一个问题,billing 部门难道不可以建立对 user 服务的集成测试吗?当然可以,实际上我们有专门 mock user 服务的测试,也有对 user 的集成测试,偶尔也会进行手工测试。

但是mock测试、集成测试和手工测试这些测试手段都不能及时发现问题。

首先我们看看 mock 测试。mock 服务器是由我们自己掌控的,他的结果是不可信赖的,并不能完全代替真实服务,我们之所以用 mock,是因为快、可控、稳定性高,而且能做到环境隔离。

当真实的 user 服务发生变动时,mock 的数据格式并不能及时更新,所以这些测试用例并不会爆红,而是继续通过。

https://gitee.com/looker53/pics/raw/master/img//20210422153626.png

而集成测试和手工测试都有相同的缺陷,他们太慢了。billing 部门的整套集成测试从构建到结束需要 5 个小时,手工测试一轮就更久了。也就是说,我们至少需要 5 个小时才能发现我们依赖的服务发生了变化,而这个问题早就引发了我们的系统瘫痪长达 5 个小时之久。

契约测试是融合了 mock 测试和集成测试的综合性测试手段,他把消费者 billing 编写的测试用例形成契约文件(contract file),放到提供者 user 端去构建。当代码修改以后,提供者 user 先针对所有的契约文件构建一次测试,如果所有的契约文件都满足,没有造成毁约现象,就可以上线了。如果有毁约,则需要和被毁约方协商解决,再上线。

附消费者和提供者示例代码,以及mock测试和集成测试示例代码:

billing server:

import httpx
from flask import (Flask,request)
app = Flask(__name__)
app.config.update(user_server_host='<http://localhost:5001>')

@app.route('/pay/<uid>/<int:amount>')
def pay(uid, amount):  
		"""付款"""  
		user_host = app.config.get("user_server_host")  
		user_server = f'{user_host}/user/{uid}/pay'  
		resp = httpx.get(user_server)  
		user = resp.json()  
		if user.get('balance') < amount:      
				return {"msg": "not enough money"}  
		return {"msg": "success","amount": amount, "uid": uid    }
if __name__ == '__main__':  
		app.run(port=5000, debug=True)

user_server:

from flask import (Flask, request)
app = Flask(__name__)
@app.route('/user/<uid>/<src>')
def user_info(uid, src):  
"""付款"""  
if src == 'pay':      
		return {"id": uid, "balance": 8000}  
elif src == 'manage': 
		return {"id": uid, "age": 19}  
...
if __name__ == '__main__':  
		app.run(port=5001)

测试代码:

import unittest
from billing_server import app

class TestBilling(unittest.TestCase):  
		def test_mock_user_server(self):      
				app.config.update(user_server_host='<http://localhost:5002>')      
				with app.test_client() as client:          
				resp = client.get('/pay/1/100')          
				assert b"amount" in resp.data  
		def test_real_user_server(self):      
				app.config.update(user_server_host='<http://localhost:5001>')      
				with app.test_client() as client:         
				resp = client.get('/pay/1/100')          
				assert b"amount" in resp.data
if __name__ == '__main__':  
		unittest.main()

真实的 user 服务更新后,bill 服务端的测试用例如果 mock 了依赖的 user 服务,测试用例会继续通过,因为 mock 服务是不可信赖的。

如果使用集成测试方法,直接调用远端的服务,不可避免的会造成测试运行很慢,如果整套测试运行需要 2 个小时,则会造成用户无法使用 2 个小时后,才能发现问题。

回帖
请输入回帖内容 ...