[Java知识库]微服务架构演变之路

时间：2021年12月11日

作者：小蒋聊技术

大家好，欢迎来到小蒋聊技术。小蒋准备和大家一起聊聊技术的那些事。

今天小蒋准备回顾自己从接触互联网开始，软件行业这十多年里的软件架构演变之路。俗话说“温故而知新”，咱们一起来看看软件架构究竟是如何走到今天“微服务架构”的。

一.单一应用架构

小蒋是在2000年左右开始接触互联网的，当时也是因为自己好奇，想看一看究竟什么是Internet。

那个时候上网，主要是通过Web浏览器。当时网站的流量，如果和现在比可以说是非常小的。同一时刻并发人数，最高可能也就是10人左右。

Web应用程序的早期，大部分Web应用是将所有的功能模块打包到一起，放在一个Web容器中运行，所有的功能模块使用同一个数据库。

因为当时网站流量很小，而且所有功能又都打包放在一起，这样就可以减少部署节点和成本。这个时期ORM框架是关键，它的作用是提供“增删改查”能力。

小蒋拿当时电商系统的架构图举例说明：

优点：

1. 项目架构简单，ORM架构是关键。前期开发成本低、周期短、小型项目首选。
2. 所有功能直接打包在一个完整的部署包内，直接放在Web容器运行目录内即可运行。
3. 容易部署，运维成本小。

缺点：

1. 全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。
2. 版本迭代速度逐渐变慢，修改一个地方就要将整个应用全部重新编译、打包、部署。开发及测试周期逐渐变长。
3. 性能扩展难，无法按需伸缩。只能通过集群的方式实现水平扩展，无法针对业务进行按需扩容。

二.垂直应用架构

随着互联网行业的兴起，上网的人数也是逐渐增多。这就意味着网站的访问量，也是逐渐增大的。

这个访问量的增大，通常并不是所有功能的访问量平均增长的，而是跟着业务，单项功能的需求随着时间而几何级增长的。

例如，系统内的“订单”需求不断增长、“用户”需求不断增长、“商品”需求不断增长，等等。

为了适应市场需求的变化，为了解决“单一应用架构”的不足，同时也为了适应逐渐变大的项目开发需求。

许多公司将“单一应用架构”按业务，垂直拆分成为若干系统。系统之间通过网络交互来完成用户的业务交互。

这个时期，主要快速完成前端开发，也就是建站是关键。加速前端开发的Web MVC架构自然也就成为技术的关键了。

优点：

1. 按业务垂直拆分，拆分成一个一个的单一应用架构系统。
2. 将大系统，拆分成若干小系统。功能简单、前期开发成本低，周期短。
3. 每个子系统可以独立部署，按需扩容，降低了维护和部署的难度。
4. 每个子系统可以交给不同团队维护，使用不同技术。团队各司其职，开发和管理也更加方便和有针对性。

缺点：

1. 公共模块无法重复利用，开发资源存在浪费。
2. 子系统之间存在冗余数据，功能也存在冗余，系统耦合度高。
3. 子系统仍旧是单体架构，子系统内部各部分，按需伸缩能力仍旧不足。

三.面向服务的架构

当垂直应用越来越多，将核心业务抽取出来，作为独立的服务，这种架构叫做“面向服务的架构”（SOA）。

例如，订单服务、用户服务、商品服务、单点登录，等等。将这些公共的基础服务，提取出来。以接口的方式暴露出来给其他系统调用。

这个时期，分布式服务框架是关键，例如RPC或者Web Service。

优点：

1. 基于面向服务的架构思想（SOA），将重复且公用的功能抽取为组件，以服务的方式向各个系统提供服务。
2. 重复功能抽取为服务，提高系统可重用性和可维护性。
3. 每个子系统变成小型系统，将功能简单化，减少前期开发成本，缩短开发周期。

缺点：

1. 系统与服务之间可能边界比较模糊。可能会导致服务抽取的粒度过大，系统与服务之间耦合度高。
2. 服务的接口协议不固定，例如有RPC 和 Rest 。具体的协议种类繁多，不利于系统维护。
3. 系统被按业务和服务进行拆分，那么事务也不得不引入“跨资源的分布式事务”。这也是一个技术难点。

四.微服务架构

接下来小蒋带大家来看看，现在比较流行的“微服务架构”，“微服务架构”又是什么呢？

微服务架构，其实就是基于“面向服务的架构”（SOA）的思想。为了进一步满足现在移动互联网对多客户端的需求。

对“服务层”再进一步，进行细粒度的拆分。拆分出的服务，只完成某个特定的业务功能。提炼成更细粒度的服务，并以接口的形式对外提供服务，即“微服务”。

究竟，SOA和微服务有什么区别呢？

小蒋是这样认为的：

1. SOA侧重于系统集成。
2. 微服务侧重于最小粒度拆分。

微服务要做到高内聚、低耦合。方便后续的服务细粒度的复用与伸缩。

优点：

1. 微服务的职责单一。
2. 服务拆分粒度更细，有利于资源重复利用，提高开发效率。
3. 可更加精准的定制每个服务的优化方案，按需伸缩。
4. 适用于互联网时代，产品迭代周期更短。

缺点：

1. 技术的复杂性增加，一个业务流程要经过多个微服务通过网络交互完成。
2. 微服务过多，服务治理成本上升，不利于系统维护。
3. 这么多微服务，有效的监控和管理将成为一项巨大的挑战。
4. 分布式事务，也是重要的一个难题。

总结:

单体应用如何拆分为微服务，然后上云，使用Kubernetes管理？等等问题，是需要温故而知新的。

通过小蒋今天的回顾，小蒋意识到“架构也是随着其缺陷不断演变而来的”。

在使用微服务架构设计系统的时候，会涉及到分布式基础知识的方方面面：

1. 分布式事务处理
2. 分布式锁
3. 分布式ID
4. 分布式缓存
5. 分布式搜索
6. 消息队列
7. ……

这些基础知识，小蒋将会和大家一起来探索的，咱们一起来“温故而知新”。

年龄的增长不可怕，可怕的是从未成长！

感谢大家支持小蒋，小蒋希望和大家共同成长，谢谢。

音频版地址：

微服务架构演变之路https://www.ximalaya.com/keji/51588599/481779891