最近很多公司都在关注原有应用的上云和应用改造，都在纠结于一个问题，就是是否需要将单体应用拆分成微服务，进行架构改造。每个人所处的行业不同，自身情况不同，业务对IT的要求也不同，对技术和拥有成本的理解也不同。所以，这个问题没有标准答案，也不会有标准答案。但是有一些共同的原则可以整理出来供参考。1.单体应用不是过街老鼠，微服务也不一定是万灵药。首先我们来看一下单体应用和微服务的基本特征：微服务架构采用了化整为零的架构原则，将应用表达为细粒度、松耦合服务的集合。由于整体的复杂性从整体的功能耦合转移到服务协调层面，每个服务代表一个细粒度的业务功能，更容易管理和协调。单体架构是将离散的功能点和一定的流程安排在统一的功能框架下，形成一个不可分割的单元，作为一个整体进行测试、部署和扩展。由于所有组件都具有很强的依赖性，每个组件很难独立运行，形成盛衰格局。单体应用程序是我们长期以来在孤岛式IT环境下形成的程式化思维的产物。在现在微服务大行其道的情况下，我们还很难说单体应用没有用。比如单体应用的部署、运维、测试都非常简单。在业务功能逻辑和性能要求不够高的时候，单体应用帮我解决了很多问题。当然，随着后互联网时代的到来，单体应用越来越无法适应敏捷快速的需求变化，越来越难以承担大流量、大并发的考验。从传统经验来看，单体应用适用于简单的业务场景、简单的功能、易于管理的研发，一些性能关键的场景也适合单体应用，这可能会颠覆一些人的认知。知道。另外，如果业务需求非常稳定，基本不会发生变化，也可以继续使用单体应用架构。再来说说微服务。在现在的需求模式下（背景很重要，单体应用流行时没有人会怀疑它的正确性），微服务显然容易扩展，应用组件之间相互独立。界限清晰，沟通方式更便捷，对多种语言友好。另外，开发过程可以单独管理，实现多团队协作，服务组件独立部署，独立部署维护方便。然而，随着微服务的广泛应用，缺点也暴露出来，技术成本异常高昂，服务管理、调度、测试、部署、监控、排障等都变得越来越复杂，就像肥皂一样，看似简单，实则难抓住。什么时候应该考虑引入微服务？如果问题可以通过单体应用轻松解决，则无需使用微服务架构。一般来说，如果出现以下情况，可以考虑引入微服务：业务需求开始频繁变化，功能或系统交付速度远远跟不上需求的变化；代码变得非常臃肿庞大，测试、维护和修改都变得谨慎；访问量激增，分布式弹性扩容需求强烈；存在大量同时提供服务的单体应用，无法通过简单的集成和打包实现调度和管理；原来单体应用系统的生命周期结束了。需要重新开发。由于微服务架构需要很多基础设施平台和基础组件的支持才能发挥微服务架构的优势，当基础设施相对落后时，微服务的使用可能无法体现其价值，反而会使管理任务变得更加复杂.很多，比较麻烦。你必须明白，微服务不是灵丹妙药，这个世界上没有灵丹妙药。2、微服务的拆分一直是个头疼的问题。单体应用上云难度系数为10，单体应用拆分难度系数为100。凡是对待微服务拆分都要谨慎，不到万不得已不要轻举妄动。如果一定要搬家，有一条铁律要牢记，不能为了拆分而拆分，一定要得到利益，重要性从低到高，分别是业务、IT管理和技术实施。微服务的拆分有两个前提条件。一是回答为什么要拆分，二是做好调研。为什么拆分可以从两个方面来回答：业务驱动和技术驱动。道理就像世界上的道路。世界上没有路。如果你走很多路，你会找到一条路。有了原因，更重要的是准备工作。首先，要收集业务和应用的所有信息，明确工作的总体基线和基本原则。分裂时机的选择也是一个重要的问题。随着业务复杂度的增加，单个应用的成本和成本急剧飙升。但在业务发展初期，微服务的整体成本远高于单体应用。当拐点出现时，每个客户的情况都不一样，需要仔细筛选判断。微服务拆分的实现需要提前准备好配套的基础设施，比如服务描述、注册中心、服务框架、服务监控、服务跟踪、服务治理等几个基础组件。以上每一个组件都缺一不可，每一个Component的部署也包含了很多技术门槛，比如容器技术、持续部署、DevOps等相关概念，以及人才储备和概念转变。微服务不仅仅是技术的升级，更是开发方式、组织架构、开发理念的升级。改变。微服务的拆分应该遵循哪些原则？1、单一性原则：单个服务的内部功能是高内聚低耦合的。每个服务只完成自己职责范围内的任务，不属于自己职责的功能交给其他服务完成；2、封闭原则：当我们需要改变一个微服务时，所有的依赖都在这个微服务的组件内，不需要去修改其他微服务；3、服务自治原则：尽量消除对其他服务的强依赖，可以降低通信成本，提高服务稳定性。服务通过标准接口隔离，隐藏内部实现细节；4.适度粒度原则：从微服务的角度看，服务的粒度似乎足够小了，但是服务太多了就会出问题，就像传统哲学中的中庸之道，就像是老板的儿子。增一分就太胖了，减一分就太瘦了。太难了！！5、最小影响原则：拆分的过程要尽量避免影响产品的日常功能迭代。也就是说，在完成服务拆分的同时，还需要迭代产品功能；6、可扩展性原则：服务接口的定义必须是可扩展的，万物皆有余地，这是一个传统的理念。7、避免双向依赖原则：服务之间尽量不要有循环或双向依赖。究其原因，这种情况的存在，说明我们的功能边界没有明确界定，或者说还有一些通用的功能没有下沉。3、万物皆有法分享几个微服务拆分相关的方法论和原则：1.AKFScalableCube2.ArcheryPrinciple3.三剑客原则
