基于CSE的微服务工程实践-以契约为中心

微服务架构有一个核心特征：采用REST进行通信。微服务之间通过网络进行通信，不通过共享文件、数据库、内存等方式进行通信。亚马逊最早引入微服务的时候，强制所有开发团队必须通过网络的方式开放服务能力，不允许任何其他方式进行能力开放。REST作为一种轻量级的网络通信方式，在微服务架构下被广泛采用。

为了满足微服务团队之间的交流，OPENAPI Initiative制定了Open API标准，该标准综合考虑了不同语言、REST等接口习惯，定义了完整的跨平台接口标准。CSE是最早采用和实现该标准的微服务开发框架，并将“以契约为中心”的概念，应用于整个微服务开发实践。下图展现了软件开发周期的各个环节“契约”所扮演的角色。

1.管理、设计环节

微服务的能力全部通过REST接口开放，从管理和设计角度，提供了一个很好的管控点。在实际的项目团队里面，需求分析和设计人员首先对微服务的接口进行设计，并创建独立的git库存放接口定义。通过做好git库的权限管理，并将Code Review流程纳入接口项目的管控，管理者能够保证软件规格是按照设计要求进行的。

CSE开发的微服务，启动的时候会分析微服务所有的对外接口，并将契约信息注册到服务中心，服务之间的调用需要严格满足契约的要求，并提供了管理界面，可以方便的查询契约。

通过静态的方法管控规格一般是不够的，管理者还可以使用契约生成测试代码，书写一定的验收测试用例，或者将契约提交给第三方进行验收测试。

为了更好的支持接口管控和微服务实现分离，需要对代码组织方式提出一定的要求。[基于CSE的微服务工程实践-Native API先行](https://bbs.huaweicloud.com/blogs/7c03a4793cd011e9bd5a7ca23e93a891) 提供了一个可以供开发者参考的项目。

2.开发、测试环节

基于契约，可以开发代码生成工具，生成开发项目或者测试项目。开发者只需要按照接口要求，实现业务逻辑和测试逻辑。

[单体应用微服务改造实践](