目录
[1.1 概述](#1.1 概述)
[1.2 服务拆分](#1.2 服务拆分)
[1.3 开发挑战](#1.3 开发挑战)
[1.4 测试挑战](#1.4 测试挑战)
[1.4.1 开箱即用、一键部署的集成环境](#1.4.1 开箱即用、一键部署的集成环境)
[1.4.2 测试场景和测试确定性](#1.4.2 测试场景和测试确定性)
[1.4.3 微服务相关的非功能测试](#1.4.3 微服务相关的非功能测试)
[1.4.4 自动化测试](#1.4.4 自动化测试)
[1.5 运维挑战](#1.5 运维挑战)
[1.5.1 监控](#1.5.1 监控)
[1.5.2 部署](#1.5.2 部署)
[1.5.3 问题追查](#1.5.3 问题追查)
[1.5.4 依赖管理](#1.5.4 依赖管理)
[1.5.5 容量管理](#1.5.5 容量管理)
[1.5.6 总结](#1.5.6 总结)
[2.1 概述](#2.1 概述)
[2.2 频繁出现因为需求排队上线而延期的现象](#2.2 频繁出现因为需求排队上线而延期的现象)
[2.3 频繁出现代码提交冲突的现象](#2.3 频繁出现代码提交冲突的现象)
[2.4 频繁出现一个简单功能特性需要同时修改众多文件的场景](#2.4 频繁出现一个简单功能特性需要同时修改众多文件的场景)
一、微服务架构的挑战
1.1 概述
微服务的开发模式和单体服务差异比较大，对设计、开发、测试、运维等研发流程的各个阶段都提出了新的挑战。
1.2 服务拆分
服务拆分是微服务架构过程中最重要的一步，关系到微服务架构的成败，糟糕的服务拆分会影响后续的服务化过程，严重时可能会导致大量的返工，甚至是推倒重来；好的服务化拆分，意味着服务化已经成功了一半。微服务拆分时会遇到很多问题和权衡，是一个开着飞机换引擎的过程，比如拆分粒度和拆分原则如何确定；服务拆分是否需要考虑后向兼容；拆分顺序是怎么样的；服务拆分和业务当前迭代之间的关系怎么权衡等。
1.3 开发挑战
微服务背景下，微服务的定位是实现特定的业务功能，因此会有大量新增微服务的需求。业务写一个在线的服务，除了实现必需的功能外，还有众多非功能需求要考虑，常见的非功能需求有可扩展性（业务流量变大、业务特性复杂度增加时，业务可以方便扩展）、稳定性（可靠性、可用性）、兼容性（上下版本兼容）、健壮性（面对异常流量时，业务需要能够正确处理）、安全性、性能等，如此众多的非功能需求要考虑，给业务的快速迭代带来很多障碍。同时微服务众多，如果大家没有遵循一致的开发模式和通信模式，跨微服务的沟通成本很大，会给开发、测试、运维等环节带来很大的开销，因此微服务架构的第一个挑战是建立一套完善的服务标准化方案，将微服务的通信和服务治理进行标准化。微服务标准化具体包含命名、路由、RPC、IDL、服务治理等，它对于服务开发效率和稳定性提升有重要意义，并且可以有效提升服务的可维护性。
另外一个挑战是微服务分布式通信带来的复杂性，由于分布式通信的特点，需要考虑容错、数据一致性、超时、重试等话题，同时服务注册和发现、集群路由和负载均衡、服务调用链路质量的跟踪等，都是需要考虑的问题。分布式事务的处理，单体服务下的事务处理，到了分布式环境下就变得更为复杂，如果根据具体的业务场景进行折中和权衡，是个很大的问题。
1.4 测试挑战
微服务架构下，整个系统有一系列承载明确功能的微服务，通过一定的微服务通信组成，微服务架构的特点对软件测试也提出了一些挑战。
1.4.1 开箱即用、一键部署的集成环境
微服务架构下，服务和依赖很多，拓扑复杂，服务随时可能会有各种变更，如何快速构建简单易用的测试环境，是一个很大的挑战。
1.4.2 测试场景和测试确定性
微服务架构下，依赖和网络的细微变化，就可能导致测试结果发生变化，给测试场景和测试用例的构造带来很多困难，如何增加测试的确定性，保障测试效率和效果，是摆在大家面前的一个重要问题。
1.4.3 微服务相关的非功能测试
微服务架构对服务治理有很高的要求，微服务治理相关的非功能需求很多，如降级限流、超时熔断、容灾容错设计等，因此需要构建一套针对微服务非功能需求进行测试的基础设施，保证微服务治理相关的非功能需求的有效性，增加微服务的可用性和安全性。
1.4.4 自动化测试
微服务背景下，服务个数变多，服务变更频繁，对自动化测试的要求也会更高，很多线下测试没有问题的服务，线上可能会出问题，如果能够构建一套生产环境可用的自动化测试基础设施，对微服务的测试效率和效果会有很大的帮助。
1.5 运维挑战
1.5.1 监控
单体服务的监控比较简单，微服务背景下，一个服务变为多个服务，需要对多个服务分别进行监控，对多个服务之间的通信也需要监控，监控管理变得非常复杂。
1.5.2 部署
微服务拓扑复杂，有太多服务需要维护和管理，并且服务变更很频繁，对服务的部署和运维提出很高的要求。
1.5.3 问题追查
单体服务的请求在一个服务内完成，微服务的请求由多个微服务协作完成，每个微服务也部署多个节点，整个调用链路很长，业务出现问题时，如何在比较短的时间内快速找出具体问题所在，是个很大的挑战。
1.5.4 依赖管理
微服务依赖众多，如果每个依赖发生故障都会影响系统的整体稳定性，系统就会变得非常脆弱，因此需要对服务的各种依赖进行有效管理，比如哪些是强依赖，哪些是弱依赖，依赖故障对整个系统的影响，这些问题都需要提前预估并制定相应的预案。
1.5.5 容量管理
如何在细粒度的状态下，更有效地管理数量庞大的微服务，如何预估系统的容量，业务爆炸式增长或者通过运营手段导致业务流量突增时，如何快速扩容？如何在保障业务稳定发展的同时，控制成本支出。微服务的容量管理和容量规划是个系统工程，需要在效率和成本之间有很好平衡，需要有完善的基础设施支持。精细化的容量管理需要做到可视化、可量化、可优化，对运维提出了很高的要求。
1.5.6 总结
微服务架构最大的挑战在运维上，微服务的复杂性给微服务运维带来了很多难题。如果不能很好地解决微服务的运维问题，微服务架构的优势就无法体现，微服务改造也很容易陷入泥潭，因此，解决微服务的运维挑战，构建一体化的自动化运维基础设施，是微服务架构的关键一环。
二、微服务化的具体时机
2.1 概述
微服务拆分确实会带来很多实实在在的收益，但同时在开发、测试、运维等多个方面也带来了很多挑战。特别是在业务发展初期，团队人员不多，对微服务周边技术和基础设施的积累不够，贸然采取微服务架构，不仅无法带来预期的收益，还可能严重阻碍业务的快速迭代，严重时甚至可能变成一个灾难。特别是互联网领域，业务迭代效率是第一位的，单个服务开发、测试和部署都相对简单，遇到的技术难度相对较少，如果引入微服务架构，面对的技术问题成倍增加，在技术上就需要进行大的投入，这对于追求业务快速迭代的中小团队来说得不偿失的。正常的做法是微服务改造之前，平常多进行一些微服务架构相关的技术储备，当单体服务的痛点达到一定程度，已经影响业务的正常迭代效率，才需要考虑微服务改造。
架构和技术都是为了业务服务的，因为评估微服务拆分时机，也需要从业务角度出发，而不是从技术角度进行评估。如果当前架构出现如下影响业务快速发展的场景时，可以考虑进行微服务改造。
2.2 频繁出现因为需求排队上线而延期的现象
单个服务下，为了保证线上服务的稳定性，同时更好地监控上线特性的业务效果，不少研发团队都会制定相应的制度，需要上线的人提前提出申请，串行排队上线，如果经常出现因为排队等待而影响到业务的快速迭代，就需要考虑进行微服务拆分了，微服务拆分后，大家可以独享服务的上线窗口，加快并行开发的效率。
2.3 频繁出现代码提交冲突的现象
单体服务下，多人同时在修改同一服务的代码，随着业务越来越复杂，团队的人越来越多，大家平常都在自己的分支上进行开发，分支代码合入主线时，很容易出现merge冲突的现象，或者解决merge冲突时出现代码合入错误。这时就需要考虑是否可以通过微服务拆分提高并行开发的效率，同时减少出错的概率。
2.4 频繁出现一个简单功能特性需要同时修改众多文件的场景
之前团队一个真实的例子，上线一个简单的计价需求，修改文件超过50个，结果实际上线的时候发现还有2处修改遗漏。根本原因是服务代码量太庞大，并且代码结构组织不好，各种时期的历史代码，以及一些临时添加的代码遍布各处，随着业务的长期迭代，业务逻辑耦合很深，相似的判断逻辑分散到项目的各个角落，很少有人能够掌控全部逻辑。由于不了解代码的全貌，每次修改都小心翼翼，一不小心就很容易出错。这种情况下可以考虑进行微服务改造了，不然不仅会影响业务的迭代效率，同时也给整个系统的稳定性带来诸多隐患。
微服务的一大收益是解决业务高并发时带来的问题。高并发场景下，随着业务的快速发展，流量变化很快，对业务的容量评估和快速扩容提出了很高的要求，采用微服务架构拆分业务，不同的业务场景可以独自进行容量评估和扩容，比较灵活，同时可以大大节约成本。因此不少同学认为业务高并发也是微服务的一个重要拆分时机，对此我有不同的看法。对于快速成长的业务，业务迭代效率永远是第一位的，其次才是业务稳定性，成本一般在业务发展到一定阶段，业务成熟并且模式比较固定的时候才会提到一定的高度，成本问题一般情况下不足以成为微服务拆分的一个充分条件。
好了，本次内容就分享到这，欢迎大家关注《微服务架构》专栏，后续会继续输出相关内容文章。如果有帮助到大家，欢迎大家点赞+关注+收藏，有疑问也欢迎大家评论留言！