1.2 微服务架构的挑战

微服务的开发模式和单体服务差异比较大，对设计、开发、测试、运维等研发流程的各个阶段都提出了新的挑战。

1.2.1 服务拆分

服务拆分是微服务架构过程中最重要的一步，关系到微服务架构的成败，糟糕的服务拆分会影响后续的服务化过程，严重时可能会导致大量的返工，甚至是推倒重来；好的服务化拆分，意味着服务化已经成功了一半。微服务拆分时会遇到很多问题和权衡，是一个开着飞机换引擎的过程，比如拆分粒度和拆分原则如何确定；服务拆分是否需要考虑后向兼容；拆分顺序是怎么样的；服务拆分和业务当前迭代之间的关系怎么权衡等。

1.2.2 开发挑战

微服务背景下，微服务的定位是实现特定的业务功能，因此会有大量新增微服务的需求。业务写一个在线的服务，除了实现必需的功能外，还有众多非功能需求要考虑，常见的非功能需求有可扩展性（业务流量变大、业务特性复杂度增加时，业务可以方便扩展）、稳定性（可靠性、可用性）、兼容性（上下版本兼容）、健壮性（面对异常流量时，业务需要能够正确处理）、安全性、性能等，如此众多的非功能需求要考虑，给业务的快速迭代带来很多障碍。同时微服务众多，如果大家没有遵循一致的开发模式和通信模式，跨微服务的沟通成本很大，会给开发、测试、运维等环节带来很大的开销，因此微服务架构的第一个挑战是建立一套完善的服务标准化方案，将微服务的通信和服务治理进行标准化。微服务标准化具体包含命名、路由、RPC、IDL、服务治理等，它对于服务开发效率和稳定性提升有重要意义，并且可以有效提升服务的可维护性。

另外一个挑战是微服务分布式通信带来的复杂性，由于分布式通信的特点，需要考虑容错、数据一致性、超时、重试等话题，同时服务注册和发现、集群路由和负载均衡、服务调用链路质量的跟踪等，都是需要考虑的问题。

分布式事务的处理，单体服务下的事务处理，到了分布式环境下就变得更为复杂，如果根据具体的业务场景进行折中和权衡，是个很大的问题。

1.2.3 测试挑战

微服务架构下，整个系统有一系列承载明确功能的微服务，通过一定的微服务通信组成，微服务架构的特点对软件测试也提出了一些挑战。

（1）开箱即用、一键部署的集成环境

微服务架构下，服务和依赖很多，拓扑复杂，服务随时可能会有各种变更，如何快速构建简单易用的测试环境，是一个很大的挑战。

（2）测试场景和测试确定性

微服务架构下，依赖和网络的细微变化，就可能导致测试结果发生变化，给测试场景和测试用例的构造带来很多困难，如何增加测试的确定性，保障测试效率和效果，是摆在大家面前的一个重要问题。

（3）微服务相关的非功能测试

微服务架构对服务治理有很高的要求，微服务治理相关的非功能需求很多，如降级限流、超时熔断、容灾容错设计等，因此需要构建一套针对微服务非功能需求进行测试的基础设施，保证微服务治理相关的非功能需求的有效性，增加微服务的可用性和安全性。

（4）自动化测试

微服务背景下，服务个数变多，服务变更频繁，对自动化测试的要求也会更高，很多线下测试没有问题的服务，线上可能会出问题，如果能够构建一套生产环境可用的自动化测试基础设施，对微服务的测试效率和效果会有很大的帮助。

1.2.4 运维挑战

监控上，单体服务的监控比较简单，微服务背景下，一个服务变为多个服务，需要对多个服务分别进行监控，对多个服务之间的通信也需要监控，监控管理变得非常复杂。

部署上，微服务拓扑复杂，有太多服务需要维护和管理，并且服务变更很频繁，对服务的部署和运维提出很高的要求。

问题追查上，单体服务的请求在一个服务内完成，微服务的请求由多个微服务协作完成，每个微服务也部署多个节点，整个调用链路很长，业务出现问题时，如何在比较短的时间内快速找出具体问题所在，是个很大的挑战。

依赖管理上，微服务依赖众多，如果每个依赖发生故障都会影响系统的整体稳定性，系统就会变得非常脆弱，因此需要对服务的各种依赖进行有效管理，比如哪些是强依赖，哪些是弱依赖，依赖故障对整个系统的影响，这些问题都需要提前预估并制定相应的预案。

容量管理上，如何在细粒度的状态下，更有效地管理数量庞大的微服务，如何预估系统的容量，业务爆炸式增长或者通过运营手段导致业务流量突增时，如何快速扩容？如何在保障业务稳定发展的同时，控制成本支出。微服务的容量管理和容量规划是个系统工程，需要在效率和成本之间有很好平衡，需要有完善的基础设施支持。精细化的容量管理需要做到可视化、可量化、可优化，对运维提出了很高的要求。

微服务架构最大的挑战在运维上，微服务的复杂性给微服务运维带来了很多难题。如果不能很好地解决微服务的运维问题，微服务架构的优势就无法体现，微服务改造也很容易陷入泥潭，因此，解决微服务的运维挑战，构建一体化的自动化运维基础设施，是微服务架构的关键一环。