学习笔记-架构的演进之单体系统-2月day03

单体系统

在许多微服务的研究资料里，单体系统往往是以“反派角色”的身份登场的。但是，对于小型系统，也就是用单台机器就足以支撑其良好运行的系统来说，这样的单体不仅易于开发、易于测试、易于部署，而且因为各个功能、模块、方法的调用过程，都是在进程内调用的，不会发生进程间通讯，所以程序的运行效率也要比分布式系统更高，完全不应该被贴上“反派角色”的标签。

所以，当我们在讨论单体系统的缺陷的时候，必须基于软件的性能需求超过了单机，软件的开发人员规模明显超过了“2 Pizza Teams”范畴的前提下，这样才有讨论的价值。

可拆分的单体系统

虽然，从wiki的定义上看，不可拆分似乎构成了单体系统最大的缺点！

Monolithic Application
Monolith means composed all in one piece. The Monolithic application describes a single-tiered software application in which different components combined into a single program from a single platform.

但是，从纵向角度来看，在现代信息系统的实际生产环境里，似乎没有哪个大型的系统是完全不分层的。

分层架构（Layered Architecture） 已经是现在几乎所有的信息系统建设中，都普遍认可、普遍采用的软件设计方法了。无论是单体还是微服务，或者是其他架构风格，都会对代码进行纵向拆分，收到的外部请求会在各层之间，以不同形式的数据结构进行流转传递，在触及到最末端的数据库后依次返回响应。

而在横向角度的“可拆分”上，单体架构也可以支持按照技术、功能、职责等角度，把软件拆分为各种模块，以便重用和团队管理。

非独立的单体

在“拆分”这方面，单体系统的真正缺陷实际上并不在于要如何拆分，而在于拆分之后，它会存在隔离与自治能力上的欠缺。

在单体架构中，所有的代码都运行在同一个进程空间之内，所有模块、方法的调用也都不需要考虑网络分区、对象复制这些麻烦事儿，也不担心因为数据交换而造成性能的损失。可是，在获得了进程内调用的简单、高效这些好处的同时，也就意味着，如果在单体架构中，有任何一部分的代码出现了缺陷，过度消耗进程空间内的公共资源，那所造成的影响就是全局性的、难以隔离的。

• 一旦架构中出现了内存泄漏、线程爆炸、阻塞、死循环等问题，就都将会影响到整个程序的运行，而不仅仅是某一个功能、模块本身的正常运作；而如果消耗的是某些更高层次的公共资源，比如端口占用过多或者数据库连接池泄漏，还将会波及到整台机器，甚至是集群中其他单体副本的正常工作。
• 因为所有代码都共享着同一个进程空间，如果代码无法隔离，那也就意味着，我们无法做到单独停止、更新、升级某一部分代码，因为不可能有“停掉半个进程，重启 1/4 个进程”这样不合逻辑的操作。所以，从动态可维护性的角度来说，单体系统也是有所不足的，对于程序升级、修改缺陷这样的工作，我们往往需要制定专门的停机更新计划，而且做灰度发布也相对会更加复杂。
• 由于隔离能力的缺失，除了会带来难以阻断错误传播、不便于动态更新程序的问题，还会给带来难以技术异构等困难。

技术异构
马丁 · 福勒（Martin Fowler）提出微服务的9 个特征，技术异构就是其中之一。它的意思是说允许系统的每个模块，自由选择不一样的程序语言、不一样的编程框架等技术栈去实现。单体系统的技术栈异构不是一定做不到，比如 JNI 就可以让 Java 混用 C/C++，但是这也是很麻烦的事，是迫不得已下的选择。

从根本上看，单体这种架构风格，潜在的观念是希望系统的每一个部件，甚至每一处代码都尽量可靠，不出、少出错误，致力于构筑一个 7×24 小时不间断的可靠系统。 这种观念在小规模软件上能运作良好，但当系统越来越大的时候，交付一个可靠的单体系统就会变得越来越有挑战性。记得一句话，随着代码量越来越庞大，系统的腐化是必然的。

架构的继续演进

正是随着软件架构的不断演进，我们构建可靠系统的观念，开始从“追求尽量不出错”，转变为了正视“出错是必然”。实际上，这才是微服务架构能够挑战，并且能逐步开始代替运作了几十年的单体架构的根本驱动力。

附

此文章为2月Day3学习笔记，内容来源于极客时间《周志明的软件架构课》