认识达内从这里开始

单体架构应用是许多软件编程开发程序员都需要熟练掌握的一个编程开发技术，而本文我们就通过案例分析来简单了解一下，单体架构应用都有哪些不足之处。

一般在业务发展的初期，整个应用涉及的功能需求较少，相对比较简单，单体架构的应用比较容易部署、测试，横向扩展也比较易实现。

然而，随着需求的不断增加，越来越多的人加入开发团队，代码库也在飞速地膨胀。慢慢地，单体应用变得越来越臃肿，可维护性、灵活性逐渐降低，维护成本越来越高。

下面分析下单体架构应用存在的一些弊端：

1、复杂性高

在项目初期应该有人可以做到对应用各个功能和实现了如指掌，随着业务需求的增多，各种业务流程错综复杂的揉在一起，整个系统变得庞大且复杂，以至于很少有开发者清楚每一个功能和业务流程细节。

这样会使得新业务的需求评估或者异常问题定位会占用较多的时间，同时也蕴含着未知风险。更糟糕的是，这种极度的复杂性会形成一种恶性循环，每一次更改都会使得系统变得更复杂，更难懂。

2.技术债务多

随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越积越多。比如，团队必须长期使用一套相同的技术栈，很难采用新的框架和编程语言。有时候想引入一些新的工具时，就会使得项目中需要同时维护多套技术框架，比如同时维护Hibernate和Mybatis，使得成本变高。

3.错误难隔离

由于业务项目的所有功能模块都在一个应用上承担，包括核心和非核心模块，任何一个模块或者一个小细节的地方，因为设计不合理、代码质量差等原因，都有可能造成应用实例的崩溃，从而使得业务全面受到影响。其根本原因就是核心和非核心功能的代码都运行在同一个环境中。

4.项目团队间协同成本高，业务响应越来越慢

多个类似的业务项目之间势必会存在类似的功能模块，如果都采用单体模式，就会带来重复功能建设和维护。而且，有时候还需要互相产生交互，打通单体系统之间的交互集成和协作的成本也需要额外付出。

再者，当项目大到一定程度，不同的模块可能是不同的团队来维护，迭代联调的冲突，代码合并分支的冲突都会影响整个开发进度，从而使得业务响应速度越来越慢。

5.扩展成本高

随着业务的发展，系统在出现业务处理瓶颈的时候，往往是由于某一个或几个功能模块负载较高造成的，但因为所有功能都打包在一起，在出现此类问题时，只能通过增加应用实例的方式分担负载，没办法对单独的几个功能模块进行服务能力的扩展，从而带来资源额外配置的消耗，成本较高。

针对以上痛点，近年来越来越多的互联网公司采用“微服务”架构构建自身的业务平台，而“微服务”也获得了越来越多技术人员的肯定。

微服务其实是SOA的一种演变后的形态，与SOA的方法和原则没有本质区别。SOA理念的核心价值是，松耦合的服务带来业务的复用，按照业务而不是技术的维度，结合高内聚、低耦合的原则来划分微服务，这正好与领域驱动设计所倡导的理念相契合。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。