微服务架构学习与思考(12)：从单体架构到微服务架构的演进历程

Posted 2023-01-28 九卷技术录--关注技术架构，管理，产品

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了微服务架构学习与思考(12)：从单体架构到微服务架构的演进历程相关的知识，希望对你有一定的参考价值。

从单体架构到微服务架构的演进历程

一、单体架构

1.1 什么时候用单体架构

在创业初期或项目开始时，项目整体功能比较少，开发人员也少，且项目需要用最少时间开发出来，用 MVP 方式快速进行市场验证是否可行，这时候就可以用单体架构进行快速开发。

1.2 单体架构设计举例-电商应用

功能分析：

拿淘宝网来举例，现代电商网站功能是很复杂的，有多少功能呢？可以看看我前面的文章《电商产品设计全攻略》读书笔记(https://www.cnblogs.com/jiujuan/p/14452748.html#1574269892) 里的电商管理系统和电商平台产品结构 2 小节。

拿淘宝网举例的话，当然是最早期的淘宝网 - -！，它最简单的 3 个功能：商品展示，用户下单，订单中心。这三个功能构成一个最简单的电商业务流程。

展示给用户看的商品页面以及用户购买商品的操作功能。那我们需要对用户和订单进行管理，怎么办？

就需要一个管理后台来对用户订单进行管理。如此简单分析过后，就知道了电商网站应用功能。

应用功能架构图：

程序架构设计：

这时候我们开发的单体应用程序，部署在应用服务器上。程序架构可能采用 MVC 这种程序架构模式。

当然也有可能什么架构都不用，直接撸代码了，所有的程序都混合在一起，这就是所谓的“大泥球”单体，这是一种糟糕的开发方式。

java 里最常用的 MVC 框架，比如 SpringMVC 框架。

划分模块

比如根据上面电商功能架构图，在程序里可以把电商功能划分为相对应的模块，如用户模块，订单模块，商品模块。

这时程序里不管是前台功能，后台功能都有这些模块。

（应用程序模块）

这时候应用程序模块都在一个大的单体项目里，前台功能和管理后台共用一套代码。

模块里的功能

比如前台商品模块，就有商品列表，商品详情页等页面功能。

程序开发

编写程序时可能应用 MVC 这种程序设计模式来进行程序代码开发。

程序部署架构图：

编写的程序代码部署到应用服务器上，用户的所有数据存储到 MySQL 数据库里。

程序和 MySQL 都部署在同一台服务器上。

二、单体架构演进

2.1 MySQL 性能瓶颈-缓存

随着项目上线，公司对项目加大力度推广和运营，用户数越来越多。

有一天，用户投诉说，商品详情页面浏览好慢。如是你一番操作猛如虎，发现详情页显示慢，性能瓶颈出现在数据库 MySQL 上，

MySQL 在用户访问高峰时，扛不住那么大的访问量。这时你想到的解决方法，可以用缓存来缓存一部分数据，不必每次都到 MySQL 取数据，

可以用 Redis 来缓存部分商品信息数据。如是，增加一个 Redis 缓存，架构图如下：

2.2 MySQL 读写分离

这时候，你也可能想到另外的一种方法：数据的读写分离，减轻对 MySQL 访问压力。

经过上面 2 种措施改进后，商品详情页访问速度开始变快，访问正常了。

但是这种舒服日子没过几个月，又有用户开始反馈页面访问比较慢。

你又一番埋头辛苦分析，发现是单台服务器负载高，单台服务器的性能已经到了极限，它已经承载不了那么多用户的访问。

如是你想，把数据存储和应用程序部署到 2 台服务器上，减轻服务器的负载压力。

2.3：数据存储和应用程序服务器分离

于是你申请买了一台服务器，把 MySQL 和 Redis 都部署在这台新买的服务器上，让原来那台服务器负载得到缓解。

新的架构部署成功后，用户访问页面又恢复正常。

但是随着业务发展越来越好，新增用户越来越多，应用服务器的负载又居高不下了。

这时候要增加新的应用服务器了，这样做是最简单的。多台应用服务器形成集群，那怎么访问这些应用服务器？才能使每台服务器负载保持平衡，或者性能好的多接受一些用户访问？这时候就要用到负载均衡了。

2.4 集群-分布式

集群-负载均衡(多台应用服务器)

部署多台应用服务器形成一个应用服务器集群，前面用户通过负载均衡器来进行服务的访问。

比较常用的负载均衡软件有 Nginx、LVS、KeepAlived 等等。

还有硬件负载均衡，比如 F5 等。

部署后，页面访问又恢复了正常。

过了几个月，数据服务器也出现负载过高情况，这时候可以把 Redis 缓存和 MySQL 分离，部署到不同服务器上。

随着数据量增加，把 Redis 部署为分布式缓存。

数据库分离和 Redis 分布式缓存

把 MySQL 和缓存 Redis 部署到不同的服务器上。

随着缓存数据的增多，Redis 也部署为主从模式，然后到 Redis Cluster 集群模式，也就是 Redis 的分布式缓存。

此时数据存储服务器负载得到缓解，访问恢复正常。

由于业务发展太快，用户变得更多，数据库又出现了性能瓶颈，这时可以对数据库进行分库分表

分库分表

为了进一步的降低数据库由于数据量太多，访问太大而造成的瓶颈，可以对数据库进行分库分表，减轻数据库的访问压力。

三、应用程序发展演进

3.1 应用程序功能变化-硬件发展

上面画的架构图都是后端技术部分，服务端架构从单体到集群再到分布式的演进。

那么前面给用户使用的应用程序呢？也是在变化之中。

比如在《淘宝技术这十年》里的淘宝网的发展变化，刚开始时是一个很简单的 PC 端页面，到后来随着手机普及，移动互联网发展起来，

手机应用就出现了。淘宝 APP 也随之出现。随着国民应用微信逐渐发展壮大，小程序也成为第三种互联网程序应用形式。当然，还有其它终端，比如平板 ipad，自动售货机等等各种终端。

上面是不同硬件出现，程序应用承载出现不同形式。

（多终端用户出现后的架构图）

那么淘宝网的功能呢？当然增加了很多。

还孵化出了多种不同的业务应用，比如天猫，1688，支付宝，聚划算，淘宝旺旺等等很多应用。

在今年 2013.1 再去打开淘宝 APP 看看，里面的功能多到眼花缭乱。

现在的电商系统有哪些子系统，系统里都有啥功能，可以看看我之前发布的这篇文章。

3.2 多端程序单体架构

多种终端的出现，当然不是一下子就出来的，都有一个发展过程，只不过到写这篇文章为止，出现了上面说的PC，手机 APP、小程序，平板等多个终端，最常用的还是前面 3 种。

最开始开发程序时，应用程序要适应多个终端，最简单的方式就是拷贝 PC 端的代码到多个终端程序里。按照上面 1.2 小节的电商最简单业务功能模块实现，多终端应用程序功能架构如下：

（后端功能模块架构图）

上面的三种终端程序应用，还是使用同一个 MySQL 数据库，也及是说订单数据、用户数据等都存储在一个库中。

可能会问，怎么区分订单来自哪一个终端？

可以给订单数据一个类型标识来进行区分，订单是从哪一个终端过来的。

那管理后台呢？

多终端程序可以共用一个管理后台。

多终端的后台功能模块都搞起来了，但是这种程序模块架构有什么弊端缺点呢？

代码重复

增加/修改功能复杂：比如说要修改一个订单模块的功能，需要修改 3 个终端的后台代码

代码维护复杂：每次维护代码都需要动 3 个后端的代码

那有没有办法可以改进上面所说的情况？

能不能把 3 个后端重复模块代码合并为一个，统一向前端提供服务，当然是可以的。怎么做？

前后端分离 - 把前后端代码进行分离，前端展示操作页面和后端功能模块分离

抽象公共模块 - 把多个后端公共模块进行抽象为一个模块，为前端提供统一服务