微服务的开发模式和单体服务差异比较大,对设计、开发、测试、运维等研发流程的各个阶段都提出了新的挑战。
1、拆分挑战
服务拆分是微服务架构过程中最重要的一步,关系到微服务架构的成败,糟糕的服务拆分会影响后续的服务化过程,严重时可能会导致大量的返工,甚至是推倒重来;好的服务化拆分,意味着服务化已经成功了一半。微服务拆分时会遇到很多问题和权衡,是一个开着飞机换引擎的过程,比如拆分粒度和拆分原则如何确定;服务拆分是否需要考虑后向兼容;拆分顺序是怎么样的;服务拆分和业务当前迭代之间的关系怎么权衡等。
2、开发挑战
微服务背景下,微服务的定位是实现特定的业务功能,因此会有大量新增微服务的需求。如果大家没有遵循一致的开发模式和通信模式,跨微服务的沟通成本很大,因此需要建立一套完善的服务标准化方案,将微服务的通信和服务治理进行标准化。微服务标准化具体包含命名、路由、RPC、IDL、服务治理等,它对于服务开发效率和稳定性提升有重要意义,并且可以有效提升服务的可维护性。
微服务分布式通信带来的复杂性,由于分布式通信的特点,需要考虑容错、数据一致性、超时、重试等话题,同时服务注册和发现、集群路由和负载均衡、服务调用链路质量的跟踪等,都是需要考虑的问题。
3、测试挑战
微服务架构下,整个系统有一系列承载明确功能的微服务,通过一定的微服务通信组成,微服务架构的特点对软件测试也提出了一些挑战。
- 开箱即用、一键部署的集成环境
微服务架构下,服务和依赖很多,拓扑复杂,服务随时可能会有各种变更,如何快速构建简单易用的测试环境,是一个很大的挑战。
- 测试场景和测试确定性
微服务架构下,依赖和网络的细微变化,就可能导致测试结果发生变化,给测试场景和测试用例的构造带来很多困难,如何增加测试的确定性,保障测试效率和效果,是摆在大家面前的一个重要问题。
- 微服务相关的非功能测试
微服务架构对服务治理有很高的要求,微服务治理相关的非功能需求很多,如降级限流、超时熔断、容灾容错设计等,因此需要构建一套针对微服务非功能需求进行测试的基础设施,保证微服务治理相关的非功能需求的有效性,增加微服务的可用性和安全性。
- 自动化测试
微服务背景下,服务个数变多,服务变更频繁,对自动化测试的要求也会更高,很多线下测试没有问题的服务,线上可能会出问题,如果能够构建一套生产环境可用的自动化测试基础设施,对微服务的测试效率和效果会有很大的帮助。
4、运维挑战
微服务背景下,一个服务变为多个服务,需要对多个服务分别进行监控,对多个服务之间的通信也需要监控,监控管理变得非常复杂。微服务拓扑复杂,有太多服务需要维护和管理,并且服务变更很频繁,对服务的部署和运维提出很高的要求。
- 问题排查
单体服务的请求在一个服务内完成,微服务的请求由多个微服务协作完成,每个微服务也部署多个节点,整个调用链路很长,业务出现问题时,如何在比较短的时间内快速找出具体问题所在,是个很大的挑战。
- 依赖管理
微服务依赖众多,如果每个依赖发生故障都会影响系统的整体稳定性,系统就会变得非常脆弱,因此需要对服务的各种依赖进行有效管理,比如哪些是强依赖,哪些是弱依赖,依赖故障对整个系统的影响,这些问题都需要提前预估并制定相应的预案。
- 容量管理
如何在细粒度的状态下,更有效地管理数量庞大的微服务,如何预估系统的容量,业务爆炸式增长或者通过运营手段导致业务流量突增时,如何快速扩容?如何在保障业务稳定发展的同时,控制成本支出。微服务的容量管理和容量规划是个系统工程,需要在效率和成本之间有很好平衡,需要有完善的基础设施支持。精细化的容量管理需要做到可视化、可量化、可优化,对运维提出了很高的要求。
微服务架构最大的挑战在运维上,微服务的复杂性给微服务运维带来了很多难题。如果不能很好地解决微服务的运维问题,微服务架构的优势就无法体现,微服务改造也很容易陷入泥潭,因此,解决微服务的运维挑战,构建一体化的自动化运维基础设施,是微服务架构的关键一环。
标签:服务,测试,运维,挑战,简述,构建,拆分,架构 From: https://blog.51cto.com/key3feng/6167649