服务端架构演进：从单体架构到微服务

前言：Java Web开发架构的演进之路，从Web1.0时期的传统单体架构，到Web2.0时期基于单体架构的集群架构，再到如今分布式的微服务架构时代。

一、单体架构

​ Web 1.0应用程序发展的早期，大部分web工程师将所有的功能模块打包到一起并放在一个web容器中运行，所有功能模块使用同一个数据库，同时，它还提供API或者UI访问的web模块等。各个客户端请求server服务器，所有的业务逻辑都是在这个server端内完成，这是常见的网络请求模型架构，对于小型的服务而已，这个架构是最合适的，因为它稳定且简单。server服务器的更新和维护也很简单。

尽管也是模块化逻辑，但是最终它还是会打包并部署为单体式应用，这种将所有功能都部署在一个web容器中运行的系统就叫做单体架构（也叫：巨石型应用）。

​ 单体架构有很多好处：

​ 开发效率高：模块之间交互采用本地方法调用，并节省微服务之间的交互讨论时间与开发成本。

​ 容易测试：IDE都是为开发单个应用设计的、容易测试——在本地就可以启动完整的系统。

​ 容易部署：运维成本小，直接打包为一个完整的包，拷贝到web容器的某个目录下即可运行。

​ 但是，上述的好处是有条件的，它适用于小型简单应用，对于大规模的复杂应用，就会展现出来以下的不足：

​ 复杂性逐渐变高，可维护性逐渐变差 ：所有业务模块部署在一起，复杂度越来越高，修改时牵一发动全身。

​ 版本迭代速度逐渐变慢：修改一个地方就要将整个应用全部编译、部署、启动时间过长、回归测试周期过长。

​ 阻碍技术创新：若更新技术框架，除非你愿意将系统全部重写，无法实现部分技术更新。

​ 无法按需伸缩：通过冗余部署完整应用的方式来实现水平扩展，无法针对某业务按需伸缩。

---

二、集群架构（单机架构扩展）

Web2.0时期，随着我们的用户数渐渐变多，单台服务器的压力扛不住的时候，我们就要用到负载均衡技术，增加多台服务器来抗压，后端的数据库也可以用主从同步的方式来增加并发量，模型如下图所示:

---

三、 微服务架构

​ 许多大型公司，通过采用微服务架构解决了上述单机架构的不足问题。其思路不是开发一个巨大的单体式的应用，而是将应用分解为小的、互相连接的微服务。​ 一个微服务一般完成某个特定的功能，比如订单服务、用户服务等等。每一个微服务都是完整应用，都有自己的业务逻辑和数据库。一些微服务还会发布API给其它微服务和应用客户端使用。

　　比如，一个前面描述系统可能的分解如下：

         

​ 每一个业务模块都使用独立的服务完成，这种微服务架构模式也影响了应用和数据库之间的关系，不像传统多个业务模块共享一个数据库，微服务架构每个服务都有自己的数据库。

微服务架构的好处：

• 分而治之，职责单一：易于开发、理解和维护、方便团队的拆分和管理

• 错误和故障隔离：当微服务架构隔离功能时，它也会隔离错误。一个微服务中的问题不会关闭整个应用程序，它将包含在该区域中，而其他微服务继续运行。

• 弹性可伸缩：能够单独的对指定的服务进行伸缩

• 局部容易修改，容易替换，容易部署，有利于持续集成和快速迭代

• 不会受限于任何技术栈

微服务核心就是把传统的单机应用，根据业务将单机应用拆分为一个一个的服务，彻底的解耦，每一个服务都是提供特定的功能，一个服务只做一件事,类似进程，每个服务都能够单独部署，甚至可以拥有自己的数据库。这样的一个一个的小服务就是微服务

①比如传统的单机电商应用里面有 订单/支付/库存/物流/积分等模块(理解为servcie)

②我们根据业务模型来拆分,可以拆分为  订单服务，支付服务，库存服务，物流服务，积分服务

③若不拆分的时候，我的非核心业务积分模块 出现了重大bug 导致系统内存溢出，导致整个服务宕机；若拆分之后，只是说我的积分微服务不可用，我的整个系统核心功能还是能使用。

---

参考链接：

微服务起源及实践--微服务哪些事摘录

何为微服务、网关、服务发现/注册？