目录
一、微服务架构的挑战
1.1 概述
1.2 服务拆分
1.3 开发挑战
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 频繁出现代码提交冲突的现象
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处修改遗漏。根本原因是服务代码量太庞大，并且代码结构组织不好，各种时期的历史代码，以及一些临时添加的代码遍布各处，随着业务的长期迭代，业务逻辑耦合很深，相似的判断逻辑分散到项目的各个角落，很少有人能够掌控全部逻辑。由于不了解代码的全貌，每次修改都小心翼翼，一不小心就很容易出错。这种情况下可以考虑进行微服务改造了，不然不仅会影响业务的迭代效率，同时也给整个系统的稳定性带来诸多隐患。
微服务的一大收益是解决业务高并发时带来的问题。高并发场景下，随着业务的快速发展，流量变化很快，对业务的容量评估和快速扩容提出了很高的要求，采用微服务架构拆分业务，不同的业务场景可以独自进行容量评估和扩容，比较灵活，同时可以大大节约成本。因此不少同学认为业务高并发也是微服务的一个重要拆分时机，对此我有不同的看法。对于快速成长的业务，业务迭代效率永远是第一位的，其次才是业务稳定性，成本一般在业务发展到一定阶段，业务成熟并且模式比较固定的时候才会提到一定的高度，成本问题一般情况下不足以成为微服务拆分的一个充分条件。
好了，本次内容就分享到这，欢迎大家关注《微服务架构》专栏，后续会继续输出相关内容文章。如果有帮助到大家，欢迎大家点赞+关注+收藏，有疑问也欢迎大家评论留言！