凤凰架构阅读笔记

在博客阅读本文

架构演变史

原始分布式时代

主要讲述在单体架构出现前早期分布式架构的设想以及实现。这里主要通过介绍早期UNIX的系统设计向我们强调两点：

单体系统时代

定义

单体架构指：

单体架构是我们都学过的一种软件架构，（最基本的 springboot 项目 应该就可视为单体架构）。

单体系统又被称为 “巨石系统” 。

单体系统的优劣

虽然当今时代，微服务系统更加贴切真实生产环境，但是我们不能一味地否定单体系统。

对于小型系统，即一台机器即可完好支撑运行的系统，使用单体架构易于开发，易于测试，易于部署且系统中的各个功能、模块、方法的调用过程都是进程内调用，不会发生进程间通信，因此执行效率非常高。在这种情况下，它是一种很不错的架构风格。

不少微服务书籍之所以将其视为“反派角色”，是因为其在大型系统上使用一言难尽罢了。

前文提到单体系统又被称作“巨石系统”即 Monolithic Application ，

巨石一词似乎已经在暗示单体系统的不可拆分性（其实不然），但我们将其理解为“自给自足”更好。

单体架构真的不可拆分么？

纵向角度来看，现实生产环境中没有系统是完全不分层的，分层架构是系统建设中被人普遍认可和采用一种设计方法。

无论是单体还是后面要提及的微服务架构，都会对代码进行纵向层次的划分。收到的外部请求在各层之间以不同形式的数据结构进行传递直到触及到最底层的数据库层再进行反弹回馈。在这个层面上，单体系统是“可拆分的”。而且整个规划非常的清晰，便于开发、部署、测试。

横向角度来看，单体架构也按照技术、功能、职责等将软件分为各种模块，以便重用和管理代码。单体结构也不意味着只能将整个程序一次封装。我们当然可以将模块封装。

单体系统真正的缺陷不在如何拆分，而在于拆分之后的隔离与自治能力的缺陷。

由于代码都位于同一进程空间之内，我们无需考虑对象复制、网络分区等复杂的操作，在调用简单、高效等好处的同时，同时面临着因部分代码有缺陷而导致整个程序无法使用。而且维护也需要花费时间，正因为所有代码共享同一进程空间。无法隔离，因此我们没有办法单独修改或者更新某一部分代码，我们必须专门停机更新。测试时也非常的不方便。

如果说共享同一进程获得简单、高效的代价是同时损失了各个功能模块的自治、隔离能力，那这两者孰轻孰重呢？这不是绝对的，视情况而定，如果你需要设计的系统为小型系统，那么其实我们无需过度设计，单体架构就足够了。但是当我们的系统定位为大型系统时，我们就不能选择单体架构了，因为一个大型系统的更新以及维护都是需要很大的代价的。

当然微服务之所以取代单体系统成为潮流的根本原因还是因为单体系统难以兼容“Phoneix”特性。小型系统开发时，它的缺点并不明显。但是当系统越来越庞大时，它的更新以及修改非常的麻烦，使得项目难以维护。而随着软件架构的演进，构筑可靠系统从“追求尽量不出错”，到正视“出错是必然”的观念转变，才使得单体系统逐渐被取代。