1.2 微服务架构与整体式架构的区别

如果是一个小型项目，则使用整体式（单体式）架构设计，其好处非常明显，因为它的设计和开发，以及测试和部署，都可以在一个项目上完成。

如果一个业务复杂的大型项目也使用整体式架构设计，就会存在很多问题。可能刚开始的时候，还感觉不到什么，但是随着时间的推移，加入的功能越来越多，一个项目就变成了一块巨大的石头，笨重而丑陋。

面对一个巨大的项目，开发人员想要弄清楚它的代码逻辑，就必须花费很多的时间。而针对某一项功能的更改，极有可能“牵一发而动全身”，这会让实施人员变得举步维艰。所以这种项目将会变得越来越难以维护，越来越不便更新。

整体式架构的稳定性也不能得到有效的保障，如果其中的一个模块出现问题，将会影响整个系统的正常运行，甚至造成整个系统的崩溃。而在对问题进行跟踪时，因为系统庞大，往往难上加难。

另外，一个巨大的项目，也不方便进行持续开发，它不能适应需求的快速变更，无法使用快速迭代的敏捷开发方法，也不便在某些方面进行新技术的更替，所以这样的项目最终就变成了业务发展的绊脚石。

相比之下，大型项目使用微服务架构的优势非常明显。

微服务架构设计，就是把复杂事情进行简单化处理。它将一个复杂的系统，拆分成一些小型的应用来开发，首先就将问题进行了分层和简化。因为小型而变得简单，代码的逻辑会变得更加清晰，这无疑解放了程序员繁重的劳动；因为简单，所以能够专注，能够将每一件事情都做好，做到极致。

微服务架构中独立的小型应用，非常适合使用敏捷开发方法，即快速响应需求的变化，进行快速的更新、迭代。

因为每个微服务都是独立自治的，即一个服务的故障不会影响全局系统的正常运行，或者说可以将这种影响降到最低。并且，微服务架构的容错设计，可以避免这种情况的发生。

微服务架构高可用的特点，是系统稳定性的最好保障。微服务能够支持高并发的调用、高流量的访问，能够持续满足平台规模化发展的要求，可以很容易地使用弹性化设计，所有这些是整体式架构无法做到的。

如果我们用一个六边形结构来表示整体式架构，则可以绘制出如图1-1所示的结构图。

图1-1

这个六边形的核心是整体式架构的领域业务模型，它通过系统接口使用各种适配器，如数据库适配器、文件适配器等，与外部管理系统进行连接；然后又通过接口，使用诸如REST API适配器、Web UI适配器等给外部App和终端用户提供接口调用和Web访问等服务。

从图1-1中可以看出，整体式架构是一个大而全的系统。在微服务架构设计中，我们可以使用一个小正方体来表示每个微服务，它相当于对整体式架构进行拆分之后得到的结果，如图1-2所示。

图1-2

小正方体的微服务同样使用接口，同样通过各种适配器连接外部管理系统，而微服务之间也可以通过接口，使用REST API适配器进行通信。对于App用户和终端用户，将分别由不同的微服务提供相应的适配器及服务。

通过对上面这两种结构图形的比较可以非常明显地看出整体式架构与微服务架构的区别。