大型单体系统
在整个软件架构演进的历史进程里，单体架构是出现时间最早、应用范围最广、使用人数最多、统治历史最长的一种架构风格。但“单体”这个名称，却是从微服务开始流行后，才事后追认所形成的概念。在这之前，并没有多少人会把“单体”看成一种架构。
在许多微服务的研究资料里，单体系统往往是以“反派角色”出现，比如《微服务架构设计模式》第一章就是“逃离单体的地狱”。而这些材料所讲的单体系统，其实都有一个没有明说的隐含定语“大型的单体系统”。
对于小型系统，也就是用单台机器就足以支撑其良好运行的系统来说。单体不仅易于开发、测试、部署，而且各个功能、模块、方法的调用过程都在进程内进行。不会发生进程间通讯，所以运行效率比分布式系统要高。
进程间通讯：IPC，RPC属于IPC的一种特例，但请注意这两个PC不是同个单词的缩写
所以讨论单体系统的缺陷，必须基于软件的性能需求超过了单机，软件开发人员规模超过“2 Pizza Teams”范畴的前提下，才有讨论的价值
2 Pizza Teams：如果一个团队的成员不能用2个披萨喂饱，就说明人数过多了
可拆分的单体系统
单体系统也被称为巨石系统，尽管巨石（Monolithic）这个单词带有一些“不可拆分”的隐含意味。但单体系统并未不可拆分。
从纵向角度来看，在现代信息系统中，所有大型系统都是分层的。分层架构是所有信息系统建设中都普遍认可、采用的软件设计方式。在所有的架构风格中，都会对代码进行纵向拆分，收到的外部请求在各层之间、以不同的数据结构进行流转传递，到达底层后依次返回响应。
从横向角度来看，单体架构也可以支持按技术、功能、职责的角度，把软件拆分为各个模块，以便重用和团队管理。如果要在负载均衡后，同时部署多个单体系统的副本，以达到分摊流量压力的效果，也是轻而易举可以实现的。
非独立的单体
单体系统真正的缺陷并不是如何拆分，而是拆分后会存在隔离和自治能力的缺失。 单体架构的所有模块、方法调用都在同一个进程空间内，获得简单、高效的好处的同时。一旦代码中出现内存泄漏、线程爆炸等问题，就会影响整个程序的运行。 而同样的，代码无法隔离意味着无法做到单独停止、更新、升级某一部分代码。所以从动态可维护的角度来说，单体系统是有所不足的。
需要权衡的问题，获得同一进程内简单、高效的代价，是损失各个功能模块的自治、隔离能力。两者孰轻孰重。换句话说：微服务、单体架构哪种更好用、优秀？
当系统规模小时，单体架构优势，当系统规模大时，微服务优势。
单体架构的潜在观念是希望系统的每一处代码都尽量可靠，少出错误。构造一个7*24小时不间断的可靠系统。在小规模软件上可行，当系统越来越大时，这是不可能实现的。
即使是为了允许运行程序出错、获得隔离、自治能力，也并不意味一定要依靠微服务架构。人们曾探索过几种服务的拆分方法，把一个大的单体系统拆分为若干个更小的、不运行在同一进程的独立服务，这些服务拆分的方法，后面导致了面向服务架构的兴盛，称为SOA时代。
