软件架构（四）单体架构(Monolithic Architecture)

系列目录

软件架构（一）概览

软件架构（二）编程语言的历史

软件架构（三）名词解释：架构、设计、风格、模式

软件架构（四）单体架构(Monolithic Architecture)

软件架构（五）分层架构

软件架构（六）MVC架构历史

一、软件发展趋势

• 模块化（Modular）

模块化编程是在20世纪60年代末和70年代提出的解决方案。它是从类到更粗粒度的代码单元显式定义的演变。编程语言以不同的显式等级实现模块化。
例如，JAVA中默认级别意味着类只在其package中可见，而public意味着类在其package内外都可见。一直到JDK9，模块化直接作为重大特性发布。其实就是将JDK中类，模块化拆分。

• 组件化（Componentized）

组件是另一种模块化风格。组件是按照业务领域划分的模块。理想情况下，它们是可以组成应用的独立的“应用程序”。微服务可以理解为应用的组件。

组件化，也是早在 20 世纪 60 年代末就已经存在了。

二、现代单体架构

2.1 单体架构介绍

　　相信大部分程序员接触的第一个程序都是：一个工程中，一个文件，打印 "Hello World ! "。当初的喜悦仿若还在身边。实际上这就是一个单体架构。

　　如今，单体架构意味着代码被部署并作为单个节点上的单个进程运行。有可能进行初步的模块化拆分（类级别），但由于整个工程一起打包部署，所以还是一个组件。如下图所示：

2.2 单体架构缺点

• 领域组件无法独立可伸缩：例如订单模块访问频率最高无法做到单独给订单模块独立水平拓展。
• 不同的领域组件，适合用不同编程语言实现时，无法拆开组件实现；
• 各组件无法做到单独发版，只能一起发布。拖慢研发节奏。

Anti-pattern: 大泥球（Big Ball of Mud）/ 意大利面（Spaghetti）架构

单体架构可能会演变成“大泥球”，又名意大利面条架构。其中包的结构和关系不显式，结构内聚和封装程序低，依赖不遵循规则，很难进行更改和重构。系统是不透明的，粘性的，脆弱的和僵硬的，就像一个大的泥球!

2.3 解决方案

将单体架构按照面向服务的架构风格拆分成不同的应用程序。即服务拆分，微服务化。国内15年开始火，一直延续至今。但很多传统企业内部仍存在很多单体架构服务，这无所谓好坏，只有合适否。有时候，能很好的支撑运行就够了，毕竟改造是需要成本的。

 

==========参考=============

2017 – hgraca – Monolithic Architecture

1997 – Brian Foote, Joseph Yoder – Big Ball of Mud

2017* – Wikipedia – Modular programming

2017* – Wikipedia – Component-based software engineering