华为内部如何实施微服务架构？基本就靠这5大原则

微服务架构的演进,应该是一个循序渐进的过程.在一个公司、一个项目组,它也需要一个循序渐进的演进过程.一开始划不好,没有关系.当演进到一个阶段时,微服务的部署、测试和运维等成本都非常低的时候,这对于你的团队来说就是一个好的微服务.

微服务的开发还会面临依赖滞后的问题.例如：A要做一个身份证号码校验,依赖服务提供者B.由于B把身份证号码校验服务的开发优先级排的比较低,无法满足A的交付时间点.A会面临要么等待,要么自己实现一个身份证号码校验功能.

以前单体架构的时候,大家需要什么,往往喜欢自己写什么,这其实是没有太严重的依赖问题.但是到了微服务时代,微服务是一个团队或者一个小组提供的,这个时候一定没有办法在某一个时刻同时把所有的服务都提供出来,“需求实现滞后”是必然存在的.

一个好的实践策略就是接口先行,语言中立,服务提供者和消费者解耦,并行开发,提升产能.无论有多少个服务,首先需要把接口识别和定义出来,然后双方基于接口进行契约驱动开发,利用Mock服务提供者和消费者,互相解耦,实现依赖解耦.

采用契约驱动开发,如果需求不稳定或者经常变化,就会面临一个接口契约频繁变更的问题.对于服务提供者,不能因为担心接口变更而迟迟不对外提供接口,对于消费者要拥抱变更,而不是抱怨和抵触.要解决这个问题,一种比较好的实践就是管理 + 技术双管齐下：

• 允许接口变更,但是对变更的频度要做严格管控.
• 提供全在线的API文档服务(例如Swagger UI),将离线的API文档转成全在线、互动式的API文档服务.
• API变更的主动通知机制,要让所有消费该API的消费者能够及时感知到API的变更.
• 契约驱动测试,用于对兼容性做回归测试.

微服务开发完成之后需要对其进行测试.微服务的测试包括单元测试、接口测试、集成测试和行为测试等,其中最重要的就是契约测试：

用微服务框架提供的Mock机制,可以分别生成模拟消费者的客户端测试桩和提供者的服务端测试桩,双方可以基于Mock测试桩对微服务的接口契约进行测试,双方都不需要等待对方功能代码开发完成,实现了并行开发和测试,提高了微服务的构建效率.基于接口的契约测试还能快速的发现不兼容的接口变更,例如修改字段类型、删除字段等.

（编辑：网站开发网_盐城站长网 ）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!