系统由单体架构到微服务架构到底是如何演进的？
source link: https://my.oschina.net/bingheteam/blog/5071317
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
大家好，我是冰河~~
随着互联网的发展，互联网企业的业务也在不断的飞速发展，进而导致系统的架构也在不断的发生着变化。总体来说，系统的架构大致经历了：单体应用架构—>垂直应用架构—>分布式架构—>SOA架构—>微服务架构的演变。当然，很多互联网企业的系统架构已经向Service Mesh(服务化网格)演变。今天，我们就一起来聊聊关于系统架构的演变这个话题。
单体应用架构
在企业发展的初期，一般公司的网站流量都比较小，只需要一个应用，将所有的功能代码打包成一个服务，部署到服务器上就能支撑公司的业务。这样也能够减少开发、部署和维护的成本。
比如，大家都很熟悉的电商系统，里面涉及的业务主要有：用户管理、商品管理、订单管理、支付管理、库存管理、物流管理等等模块，初期我们会将所有模块写到一个Web项目中，然后统一部署到一个Web服务器中。
这种架构特点有其优点：
- 架构简单，项目开发和维护成本低。
- 所有项目模块部署到一起，对于小型项目来说，维护方便。
但是，其缺点也是比较明显的：
- 所有模块耦合在一起，虽然对于小型项目来说，维护方便。但是，对于大型项目来说，却是不易开发和维护的。
- 项目的各模块之前过于耦合，如果一旦有一个模块出现问题，则整个项目将不可用。
- 无法针对某个具体模块来提升性能。
- 无法对项目进行水平扩展。
正是由于单体应用架构存在着诸多的缺点，才逐渐演变为垂直应用架构。接下来，我们就来看看垂直应用架构。
垂直应用架构
随着企业业务的不断发展，发现单节点的单体应用不足以支撑业务的发展，于是企业会将单体应用部署多份，分别放在不同的服务器上。但是，此时会发现不是所有的模块都会有比较大的访问量。如果想针对项目中的某些模块进行优化和性能提升，此时对于单体应用来说，是做不到的。于是乎，垂直应用架构诞生了。
垂直应用架构，就是将原来一个项目应用进行拆分，将其拆分为互不想干的几个应用，以此来提升系统的整体性能。
这里，我们同样以电商系统为例，在垂直应用架构下，我们可以将整个电商项目拆分为：电商交易系统、后台管理系统、CMS管理系统等。
我们将单体应用架构拆分为垂直应用架构之后，一旦访问量变大，我们只需要针对访问量大的业务增加服务器节点即可，无需针对整个项目增加服务器节点了。
这种架构的优点：
- 系统进行了拆分，可根据不同系统的访问情况，有针对性的进行优化。
- 能够实现应用的水平扩展。
- 各系统能够分担整体访问的流量，解决了并发问题。
- 一个系统发生了故障，不应用其他系统的运行情况，提高了整体的容错率。
这种架构的缺点：
- 拆分后的各系统之间相对比较独立，无法进行互相调用。
- 各系统难免存在重叠的业务，会存在重复开发的业务，后期维护比较困难。
分布式架构
我们将系统演变为垂直应用架构之后，当垂直应用越来越多，重复编写的业务代码就会越来越多。此时，我们需要将重复的代码抽象出来，形成统一的服务供其他系统或者业务模块来进行调用。此时，系统就会演变为分布式架构。
在分布式架构中，我们会将系统整体拆分为服务层和表现层。服务层封装了具体的业务逻辑供表现层调用，表现层则负责处理与页面的交互操作。
这种架构的优点：
- 将重复的业务代码抽象出来，形成公共的访问服务，提高了代码的复用性。
- 可以有针对性的对系统和服务进行性能优化，以提升整体的访问性能。
这种架构的缺点：
系统之间的耦合度变高，调用关系变得复杂，难以维护。
SOA架构
在分布式架构下，当部署的服务越来越多，重复的代码就会越来越多，对于容量的评估，小服务资源的浪费等问题比较严重。此时，我们就需要增加一个统一的调度中心来对集群进行实时管理。此时，系统就会演变为SOA（面向服务）的架构。
这种架构的优点：
使用注册中心解决了各个服务之间的服务依赖和调用关系的自动注册与发现。
这种架构的缺点：
- 各服务之间存在依赖关系，如果某个服务出现故障可能会造成服务的雪崩（关于穿透、击穿和雪崩的问题，小伙伴们可以参见我之前写的《 【高并发】面试官：讲讲什么是缓存穿透？击穿？雪崩？如何解决？》一文）。
- 服务之间的依赖与调用关系复杂，测试部署的困难比较大。
微服务架构
随着业务的发展，我们在SOA架构的基础上进一步扩展，将其彻底拆分为微服务架构。在微服务架构下，我们将一个大的项目拆分为一个个小的可以独立部署的微服务，每个微服务都有自己的数据库。
这种架构的优点：
- 服务彻底拆分，各服务独立打包、独立部署和独立升级。
- 每个微服务负责的业务比较清晰，利于后期扩展和维护。
- 微服务之间可以采用REST和RPC协议进行通信。
这种架构的缺点：
- 开发的成本比较高。
- 涉及到各服务的容错性问题。
- 涉及到数据的一致性问题。
- 涉及到分布式事务问题（小伙伴们可以参见我后续会持续更新的【 分布式事务】专题）。
好了，今天就到这儿吧，我是冰河，大家有啥问题可以在下方留言，也可以加我微信：sun_shine_lyz，我拉你进群，一起交流技术，一起进阶，一起进大厂~~
Recommend
-
54
我在Martin Fowler网站上读到一篇名为 How to break a Monolith into Microservices 的微服务文章，作者为ThoughtWorks的咨询师Zhamak Dehghan...
-
54
-
19
“微服务”是时下热门技术话题，今天云片联手网易云、网易云音乐、美洽技术大咖，在武汉光谷一起探讨，企业要落地微服务架构将跨过多少坑？ 本次活动邀请嘉宾网易云企业解决方案资深架构师 袁梓超 、云片 Java 技术专家 刘斌、网易...
-
4
传统的中小企业应用中，使用oracle的系统占比较多。迁移到云环境mysql数据库的情况下，需要考虑诸多因素，可用性、效率等。针对阿里云上的系统迁移情况来看，中小企业为主，迁移的应用数量比较大，所用技术五花八门，人肉处理的工作量非常大，效率较低。...
-
7
本文介绍 GitHub 如何从单体架构迁移到微服务架构，并对其中一些最佳实践做了详细...
-
5
货拉拉应用架构演进，堪称单体落地微服务避坑指南 徐少敏 2022-04-28 10:48:00 本文根据徐少敏
-
8
从单体架构到微服务架构的演进历程 一、单体架构# 1.1 什么时候用单体架构
-
6
从单体架构向微服务迁移：模块化单体是如何提供帮助的 作者：小技术君 2023-12-19 22:29:37 从单体架构迁移到微服务的最大障碍是耦合，耦合是变更的阻止者。因此，这是你需要解决的第一件事。
-
7
V2EX › 程序员 2024 年了, 有多少公司和系统由微服务/云原生转为了单体架构?
-
6
受到商家喜爱的小程序商城系统由哪些板块构成？ 增长黑客,
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK