最近有不少企业都不约而同的在关注原有应用的迁移上云和应用改造的事情，都在纠结一个问题，那就是是否有必要把单体应用做微服务拆分和架构改造。大家所处行业不同、自身情况不同、业务对IT的诉求也不同、对技术的理解和拥有成本也不一样，所以说，这个问题没有标准答案，也不会有标准答案。但是有一些共性的原则是可以梳理借鉴的。
一、单体应用不是过街老鼠，微服务也不一定是济世良方
首先我们来看单体应用和微服务的基本特征：
- 微服务架构是采用化整为零的架构原则，将应用程序表示为细粒度的、松散耦合的服务集合。由于整体的复杂性从整体的功能耦合被转移到了服务的协调级别上，因此每个服务都代表了一种业务细粒度的功能，可以更加容易地去做管理和协同。
- 而单体架构是在统一的功能框架下，将离散的功能点用一定的流程编排到一起，形成一个不可拆分单元，作为一个整体进行测试、部署和扩展。由于所有组件都有较强的依存关系，各个组件很难单独运行，形成了一荣俱荣一损俱损的格局。
单体应用是长期以来，在竖井式IT的大格局下，我们所形成的的程式化思维的产物，在现在微服务大行其道的形势下，我们依然很难说单体应用一无是处。比如单体应用部署、运维、测试都很简便，在业务功能逻辑和性能要求没有高到一定程度的时候，单体应用帮我解决了很多问题。当然，随着后互联网时代的到来，单体应用越来越不适应敏捷快速的需求变化，越来越难以承接大流量和大并发的考验。
从传统的经验来看，单体应用适合用于简单业务场景简单，功能不复杂，研发易于管理，还有一些对性能苛刻的场景也同样适合用单体应用，这可能会颠覆一部分人的认知。另外，如果业务的需求非常稳定，基本不会变化，也同样可以继续沿用单体应用架构。
再来说微服务，在现在的需求格局下（所处背景很重要，在单体应用大行其道的时候，没人会怀疑它的正确性），微服务很显然易于扩展，而且应用组件相互独立，有清晰的边界，通讯方式更便捷，对多种语言都很友好，还有，开发过程可以被分开管理，实现多团队协同，服务组件之间独立部署，易于独立部署和维护。但是随着微服务的广泛应用，短板也随之暴露，比如技术成本畸高、服务管理、调度、测试、部署、监控、排障都变得比较复杂，就像肥皂一样，看似简单，其实很难以握持。
什么时候需要考虑引入微服务呢？
如果用单体应用能轻松解决的问题就没必要用微服务架构。一般来说，如果发生以下情况，就可以考虑引入微服务了：
- 业务需求开始频繁变化，功能或者系统交付速度远远跟不上需求变化；
- 代码变得非常臃肿，非常庞大，测试、维护和修改都变得小心翼翼；
- 访问量激增，对分布式和弹性扩展有较强需求；
- 有大量单体应用同时提供服务，通过简单集成封装已经无法实现调度和管理；
- 原有单体应用系统生命周期结束，需要重新开发。
由于微服务架系需要众多的基础设施平台和基础组件支撑，才能发挥微服务架构的优势，所以在基础设施比较落后的情况下，采用微服务可能无法展现其价值，反而使管理任务变得更多、更繁琐。一定得明白，微服务不是银弹，这世界上也没有银弹。
二、微服务拆分始终都是让人头疼的问题
单体应用的上云的难度系数是10，那单体应用的拆分难度就是100。无论什么时候对待微服务拆分都要谨慎，不到万不得已，不要轻举妄动。如果一定要动，有一条铁律要谨记，不能为了拆分而拆分，一定得收益，重要性从低到高，分别是业务上的、IT管理上的和技术实现上的。
微服务的拆分，有两个前提条件，一是回答为什么拆分，二是做好充分调研。
为什么拆分，可以从业务驱动和技术驱动两个方面回答。理由，就像世上的路，世上本无路，走得多了就有了路。有了理由，更重要的是准备工作，首先要搜集业务和应用的所有信息，明确工作的整体基线和基本原则。
拆分时机的选择也是一个重要的问题，随着业务复杂度的上升单体应用的成本和代价在急剧飙升，但是当业务发展期初期，微服务的整体成本也远比单体应用高，这个拐点出现在时候，每个客户的情况都不一样，需要仔细甄别和判断。
微服务拆分的落地还要提前准备好配套的基础设施，如服务描述、注册中心、服务框架、服务监控、服务追踪、服务治理等几大基本组件，以上每个组件缺一不可，每个组件展开又包括很多技术门槛，比如，容器技术、持续部署、DevOps 等相关概念，以及人才的储备和观念的变化，微服务不仅仅是技术的升级，更是开发方式、组织架构、开发观念的转变。
微服务的拆分需要秉持什么原则呢？
1. 单一性原则：单一服务内部功能高内聚低耦合，每个服务只完成自己职责内的任务，对于不是自己职责的功能交给其它服务来完成；
2. 封闭性原则：当我们需要改变一个微服务的时候，所有依赖都在这个微服务的组件内，不需要修改其他微服务；
3. 服务自治原则：尽量消除对其他服务的强依赖，这样可以降低沟通成本，提升服务稳定性。服务通过标准的接口隔离，隐藏内部实现细节；
4. 粒度适中原则：从微服务这几个字来看，服务的粒度貌似应该足够小，但是服务多了也会带来问题，就像传统哲学中的中庸之道，又好比东家之子，增之一分则太肥，减之一分则太瘦，好难！！
5. 最小影响性原则：拆分的过程尽量避免影响产品的日常功能迭代。也就是说要一边做产品功能迭代，一边完成服务化拆分；
6. 可扩展性原则：服务接口的定义要具备扩展性，凡是要有留余地，又是传统哲学。
7. 避免双向依赖原则：尽量不要有服务之间的环形依赖或双向依赖，原因是存在这种情况说明我们的功能边界没有划分清楚或者有通用的功能没有下沉下来。
三、凡事都有方法
分享几个跟微服务拆分有关的方法论和原理：
1、AKF可扩展立方体
2、弓箭原理
3、三个火枪手原则
