02单体应用真的是地狱吗

一句话导读

        不能直接说单体应用是地狱，要看业务场景和团队大小而定，业务场景本来就很简单，用户都不到1000个，并发长期在10个左右的应用，或者团队就那么2-3个人，单体是最适合的。

目录

一句话导读

一、单体应用的定义

二、优势与挑战：（上篇博客也提到了）

三、适用场景：

四、如何充分利用单体应用的优势

五、举例说明：

       1. 利用单体应用的低成本、快速启动、快速迭代特点，快速形成业务应用，支撑业务运营（单应用单服务器阶段）

        2.业务快速发展，服务器遇到性能瓶颈（单应用多服务器阶段）

       3.并发量越来越高，性能要再次提高（单应用集群部署阶段）--session共享问题、负载均衡问题

        4.用户量越来越大，数据库性能跟不上（单应用集群部署数据库读写分离）

        5.用户对响应速度要求越来越高（单体应用分布式部署阶段）

        6.单体应用“地狱”形成

---

一、单体应用的定义

        单体应用（Monolithic Application）是指将整个应用程序作为一个单一的代码库和部署单元的软件架构模式。在单体应用中，所有的功能模块、组件和服务都集中在一个应用中，它们共享同一个数据库和资源。

二、优势与挑战：（上篇博客也提到了）

        优点：容易部署（只用部署一个）、测试方便、技术单一、用人成本低

        缺点：单点故障、启动慢、容错性查、可扩展性低、复杂度越来越高、并发量有限

三、适用场景：

        技术栈单一

        团队规模较小

        公司初创或者规模较小

        业务简单

        并发不高

        IT投入不大

        快速启动、快速迭代

四、如何充分利用单体应用的优势

        在软件开发领域，单体应用是一个众所周知的概念。然而，随着互联网的快速发展，越来越多的声音质疑单体应用的可持续性和灵活性，甚至有人称之为“地狱”。但是，单体应用真的如此糟糕吗？根据上面我们提到的单体应用的优缺点以及适用场景，谈谈如何在适当的情况下维护和改进单体应用，充分利用单体应用的优势，完成我们的业务活动，以及单体应用如何逐步形成“地狱”模式的。

五、举例说明：

       1. 利用单体应用的低成本、快速启动、快速迭代特点，快速形成业务应用，支撑业务运营（单应用单服务器阶段）

        小王和小任一个后台开发一个前端开发。想成立个公司，要做一个儿童教育类的APP，已经想好了从儿童的加减计算起步，逐步发展公司的业务。初期的功能很简单，用户注册，生成10以内计算题，记录计算成绩，形成周报表。小王和小任商量，我们前期用户量不大、也没有太多钱投入，而且业务模式是否能成功需要不断的修改业务模式，快速迭代，最好的架构方式就是单体应用，能够快速形成应用并运营，只要租个云服务器就搞定了。

 

图1 服务器上的单体应用

        2.业务快速发展，服务器遇到性能瓶颈（单应用多服务器阶段）

        经过了几个月的推广，用户量逐渐上升，他们想做更多的功能，几乎每个天都在更新应用，业务需求也不断在变化，好在他们用的是单体应用，技术单一，开发简单，随着业务的发展，用户量越来越多，逐渐发现单个服务器经常CPU打满，于是他们买了新的服务器，将前端页面、后台应用、数据库都分不同的服务器部署。

图2 单应用多服务器阶段

       3.并发量越来越高，性能要再次提高（单应用集群部署阶段）--session共享问题、负载均衡问题

        最近他们做了学习竞赛业务，受到大量用户的欢迎，并发持续增高，导致后台应用的服务器逐渐不堪重负，于是他们考虑将后台应用服务器做横向扩展，将后台服务做成了集群模式部署，提高了系统的并发、可用性、和可扩展性，此时也带来一个问题，就是多集群中的session共享问题，他们又引入了redis做session共享，同时通过Nginx做后台应用的负载均衡（技术单一性逐渐被打破）

 

图3 单应用集群部署阶段

        4.用户量越来越大，数据库性能跟不上（单应用集群部署数据库读写分离）

        小王、小任他们的业务发展的非常好，用户量也越来越大，之前通过分机器、集群部署等扩容后，业务容量是上去了，但是还是所有业务都在一个数据库里面，读写都在一起，大量的读取数据库操作将数据库连接占满，导致正常的业务无法获取到连接而超时。这时他们想到了将数据库做读写分离，读和写分开相互隔离。（维护成本逐渐增高）

 

图4 数据库读写分离

        5.用户对响应速度要求越来越高（单体应用分布式部署阶段）

        随着业务发展壮大，用户对响应速度的要求也越来越高，小王、小任也聘请了很多程序猿、架构师一起帮忙开发，引入各种缓存、负载均衡、cdn、搜索引擎、nosql数据库等提高系统性能，优化用户体验。单体应用逐渐按分布式方式部署，Nginx集群、CDN、SLB、Tomcat多服务、数据库HA、redis集群等等，引入了大量的新技术，技术复杂度越来越高。

 

图5 单应用分布式部署阶段

        6.单体应用“地狱”形成

        虽然经历了很多个阶段，但是业务仍然是单体服务，只是做了横向扩展，并没有对单体服务进行拆分，此处也体现出单体应用也是可以利用各种技术逐步优化，去应付业务的不断发展。同时，单体应用随着业务需求的迭代，功能的追加扩展，最终成为一个庞然大物。变得更加复杂，逻辑耦合严重，难以理解，团队开发 人员职责不清，部署困难，回归测试成本巨大，交付效率大大降低。单体应用的地狱逐渐形成。这时他们已经在考虑整个项目是否有必要做一次重构，换成更符合当前公司环境的微服务架构了。