单体应用不是过街老鼠，微服务也未必是济世良方

2022-09-14 21:02:20random

开发测试评论144字数 2039阅读6分47秒阅读模式

摘要单体应用是长期以来，在竖井式IT的大格局下，我们所形成的的程式化思维的产物，在现在微服务大行其道的形势下，我们依然很难说单体应用一无是处。

最近有不少企业都不约而同的在关注原有应用的迁移上云和应用改造的事情，都在纠结一个问题，那就是是否有必要把单体应用做微服务拆分和架构改造。大家所处行业不同、自身情况不同、业务对IT的诉求也不同、对技术的理解和拥有成本也不一样，所以说，这个问题没有标准答案，也不会有标准答案。但是有一些共性的原则是可以梳理借鉴的。

一、单体应用不是过街老鼠，微服务也不一定是济世良方

首先我们来看单体应用和微服务的基本特征：文章源自玩技e族-https://www.playezu.com/240754.html

微服务架构是采用化整为零的架构原则，将应用程序表示为细粒度的、松散耦合的服务集合。由于整体的复杂性从整体的功能耦合被转移到了服务的协调级别上，因此每个服务都代表了一种业务细粒度的功能，可以更加容易地去做管理和协同。
而单体架构是在统一的功能框架下，将离散的功能点用一定的流程编排到一起，形成一个不可拆分单元，作为一个整体进行测试、部署和扩展。由于所有组件都有较强的依存关系，各个组件很难单独运行，形成了一荣俱荣一损俱损的格局。

单体应用是长期以来，在竖井式IT的大格局下，我们所形成的的程式化思维的产物，在现在微服务大行其道的形势下，我们依然很难说单体应用一无是处。比如单体应用部署、运维、测试都很简便，在业务功能逻辑和性能要求没有高到一定程度的时候，单体应用帮我解决了很多问题。当然，随着后互联网时代的到来，单体应用越来越不适应敏捷快速的需求变化，越来越难以承接大流量和大并发的考验。文章源自玩技e族-https://www.playezu.com/240754.html

从传统的经验来看，单体应用适合用于简单业务场景简单，功能不复杂，研发易于管理，还有一些对性能苛刻的场景也同样适合用单体应用，这可能会颠覆一部分人的认知。另外，如果业务的需求非常稳定，基本不会变化，也同样可以继续沿用单体应用架构。文章源自玩技e族-https://www.playezu.com/240754.html

再来说微服务，在现在的需求格局下（所处背景很重要，在单体应用大行其道的时候，没人会怀疑它的正确性），微服务很显然易于扩展，而且应用组件相互独立，有清晰的边界，通讯方式更便捷，对多种语言都很友好，还有，开发过程可以被分开管理，实现多团队协同，服务组件之间独立部署，易于独立部署和维护。但是随着微服务的广泛应用，短板也随之暴露，比如技术成本畸高、服务管理、调度、测试、部署、监控、排障都变得比较复杂，就像肥皂一样，看似简单，其实很难以握持。文章源自玩技e族-https://www.playezu.com/240754.html

什么时候需要考虑引入微服务呢？

如果用单体应用能轻松解决的问题就没必要用微服务架构。一般来说，如果发生以下情况，就可以考虑引入微服务了：文章源自玩技e族-https://www.playezu.com/240754.html

业务需求开始频繁变化，功能或者系统交付速度远远跟不上需求变化；
代码变得非常臃肿，非常庞大，测试、维护和修改都变得小心翼翼；
访问量激增，对分布式和弹性扩展有较强需求；
有大量单体应用同时提供服务，通过简单集成封装已经无法实现调度和管理；
原有单体应用系统生命周期结束，需要重新开发。

由于微服务架系需要众多的基础设施平台和基础组件支撑，才能发挥微服务架构的优势，所以在基础设施比较落后的情况下，采用微服务可能无法展现其价值，反而使管理任务变得更多、更繁琐。一定得明白，微服务不是银弹，这世界上也没有银弹。文章源自玩技e族-https://www.playezu.com/240754.html

二、微服务拆分始终都是让人头疼的问题

单体应用的上云的难度系数是10，那单体应用的拆分难度就是100。无论什么时候对待微服务拆分都要谨慎，不到万不得已，不要轻举妄动。如果一定要动，有一条铁律要谨记，不能为了拆分而拆分，一定得收益，重要性从低到高，分别是业务上的、IT管理上的和技术实现上的。文章源自玩技e族-https://www.playezu.com/240754.html

微服务的拆分，有两个前提条件，一是回答为什么拆分，二是做好充分调研。文章源自玩技e族-https://www.playezu.com/240754.html

为什么拆分，可以从业务驱动和技术驱动两个方面回答。理由，就像世上的路，世上本无路，走得多了就有了路。有了理由，更重要的是准备工作，首先要搜集业务和应用的所有信息，明确工作的整体基线和基本原则。文章源自玩技e族-https://www.playezu.com/240754.html

拆分时机的选择也是一个重要的问题，随着业务复杂度的上升单体应用的成本和代价在急剧飙升，但是当业务发展期初期，微服务的整体成本也远比单体应用高，这个拐点出现在时候，每个客户的情况都不一样，需要仔细甄别和判断。文章源自玩技e族-https://www.playezu.com/240754.html

微服务拆分的落地还要提前准备好配套的基础设施，如服务描述、注册中心、服务框架、服务监控、服务追踪、服务治理等几大基本组件，以上每个组件缺一不可，每个组件展开又包括很多技术门槛，比如，容器技术、持续部署、DevOps 等相关概念，以及人才的储备和观念的变化，微服务不仅仅是技术的升级，更是开发方式、组织架构、开发观念的转变。