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

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

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

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

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

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

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

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

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

最后一起看下微服务的运行容器：微部署可以部署在Dorker容器、PaaS平台(VM)或者物理机上.使用Docker部署微服务会带来很多优先：

• 一致的环境,线上线下环境一致.
• 避免对特定云基础设施提供商的依赖.
• 降低运维团队负担.
• 高性能接近裸机性能.
• 多租户.

相比于传统的物理机部署,微服务可以由PaaS平台实现微服务自动化部署和生命周期管理.除了部署和运维自动化,微服务云化之后还可以充分享受到更灵活的资源调度：

• 云的弹性和敏捷.
• 云的动态性和资源隔离.

最上层是为服务治理的UI界面,提供在线、配置化的治理界面供运维人员使用.SDK层是提供了微服务治理的各种接口,供服务治理Portal调用.最下面的就是被治理的微服务集群,集群各节点会监听服务治理的操作去做实时刷新.例如：修改了流控阈值之后,服务治理服务会把新的流控的阈值刷到服务注册中心,服务提供者和消费者监听到阈值变更之后,获取新的阈值并刷新到内存中,实现实时生效.由于目前服务治理策略数据量不是特别大,所以可以将服务治理的数据放到服务注册中心(例如etcd/ZooKeeper),没有必要再单独做一套.

介绍完微服务实施之后,下面我们一起学习下微服务的最佳实践.

服务路由：本地短路策略.关键技术点：优先调用本JVM内部服务提供者,其次是相同主机或者VM的,最后是跨网络调用.通过本地短路,可以避免远程调用的网络开销,降低服务调用时延、提升成功率.原理如下所示：

（编辑：PHP编程网 - 黄冈站长网）

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