单体架构、微服务架构讲解

三层架构

        三层架构分为表现层，业务逻辑层，数据访问层。三层架构的出现，解决了系统间调用复杂，职责不清的问题，也有效降低了层与层之间的依赖关系，称为软件架构的经典模式之一。

        虽然三层架构将系统在逻辑上分成了三层，但它并不是物理上的分层。也就是说，对不同层的代码而言，经历编译、打包、部署后，所有的代码最终还是运行在同一个进程中。

对于这种功能集中、代码中心化、一个发布包、部署后运行在同一进程的应用程序，我们通常称之为单体架构应用。

单体架构

优势：

1、易于开发

        对单体架构的应用程序而言，开发方式相对简单。首先从概念上，现有的大部分工具、应用服务器、框架都是这类单体架构应用程序，容易理解而且为人所熟知。如果从实践角度出发。现有的集成开发工具比如NetBeans，IDEA，Eclipse等工具非常适合开发单体应用程序。它们能有效的加载并配置整个应用程序的依赖，方便开发人员开发、运行、调试。

2、易于测试

        单体架构应用程序也非常容易被测试，因为所有的功能都运行在一个进程中，启动集成开发环境或者将发布包部署到某一环境，一旦启动该进程，就可以立即开始系统测试或功能测试。

3、易于部署

        实际上，所有的功能最终都会打成一个包，因此只需复制软件包到服务器相应的位置即可。

4、易于水平伸缩

        实际上，所有的功能最终都会打成一个包，且只能运行在一个进程中，因此单体架构的水平伸缩，更确切地理解其实就是克隆，即新建一个服务器节点，配置好该节点的运行环境，复制软件包到相应的位置，运行该应用程序。当然，必须要确保负载均衡器能采取某种分发策略，有效的将请求分发到新创建的节点。

面临的挑战

1、维护成本增加

        随着应用程序的功能越来越多，团队越来越大，相应的沟通成本、管理成本、人员协调成本必然会显著增加。譬如，对于使用Java编写的中型应用而言，当代码量为几万行时，可能只需要几人左右的团队维护。当代码量上升到几十万行级别时，可能需要几十人甚至是上百人的团队。

        随着应用程序功能的增多，当出现缺陷时，有可能引起缺陷的原因组合就会比较多，这也会导致分析缺陷、定位缺陷、修复缺陷的成本相应增高，也就意味着缺陷的平均修复周期可能会花费更长时间。

        另外，随着代码量的增加，在开发人员对全局功能缺乏深度理解的情况下，修复一个缺陷，还有可能引入其他缺陷。在自动化测试机制不完善的情况下，很有可能导致该过程陷入“修复越多，缺陷越多”的恶心循环，最终导致维护成本高居不下，如图所示：

 2、持续交付周期长

        随着应用程序的功能越来越多，代码越来越复杂，构建和部署时间也会相应增加。在现有部署流水线稳定工作的情况下，对单体架构应用程序做任何细微的修改以及代码提交，都会触发部署流水线，令其对整个应用程序进行代码编译、运行单元测试、代码检查、构建并生成部署包、验证功能等。这就意味着流水线的反馈周期变长，单位时间内构建的效率变低了。

        另一方面，团队人员的增多，部署流水线运行的时间增加，开发人员能够提交代码的时间窗口就相应减少（因为在流水线运行的过程中是禁止提交代码的），可能出现长时间等待代码提交却无法提交的情况，极大的破坏了团队的灵活性并降低了团队的工作效率。        

 3、新人培养周期长

        随着应用程序的功能越来越多，代码变的越来越复杂，对于新加入团队的成员而言，了解行业背景、熟悉应用程序业务、配置本地开发环境这些看似简单的任务，将会花费越来越长的时间。

4、技术选型成本高

        对单体架构的应用而言，初始的技术选型严重限制了其将来采用不同语言或框架的能力。如果想尝试新的编程语言或者框架，没有完备的功能测试集，很难平滑完成替换，而且系统规模越大，风险越高。

5、可拓展性差

        无论是水平拓展还是垂直拓展都存在不同程序的问题；

----2022/3/12   后面微服务架构再补充