系统架构展现层采用技术

转载

level 2024-11-07 23:04:27

文章标签 系统架构展现层采用技术大数据 spring cloud 后端系统架构 文章分类 架构后端开发

系统架构演进与Spring Cloud Alibaba微服务架构体系

项目架构演变史

“不是我不明白，这世界变化快”。

随着互联网世界的快速发展，网站应用的规模也在不断地扩大，这种规模的扩大必然会影响这我们研发的项目的架构体系。

早期的一个单体架构的模块已然不能满足不断复杂的业务逻辑和不断增长用户数量，直到如今微服务架构体系的发展才有效、丝滑的解决了这一问题。

从互联网早期的单体架构到如今的微服务架构，项目系统架构大致经历了如下几个过程：

单体应用架构
垂直应用架构
分布式架构
SOA架构
微服务架构

系统架构展现层采用技术_大数据

单体应用架构

回想我们早期开发的项目，系统的每个功能模块都放在一个应用中，一个数据库，甚至一个开发人员都能搞定。

单体架构的开发、部署以及维护成本较低，这也是其优点所在。

当然任意模块的BUG都会影响整个应用，系统的可靠性及性能明显不高。

系统架构展现层采用技术_后端_02

优点：项目架构简单，适合用户量少的项目，开发成本低。项目部署在 一个节点 上，维护方便。
缺点：功能集中在一个工程中，项目模块紧耦合，单点容错率低，无法对不同的模块功能进行针对性的优化和水平拓展。

垂直应用架构

所谓垂直应用架构，其实就是把之前的单体应用拆分成多个应用，以提升效率，比如原来单体应用中的后台、电商、CMS等功能模块可以拆分成：后台系统、电商系统、CMS管理系统。

系统架构展现层采用技术_系统架构展现层采用技术_03

优点：项目拆分实现了流量分担，解决了并发问题，而且可以针对不同模块进行优化和水平拓展，同时不同的系统之间不会互相影响，提高容错率。
缺点：系统之间互相存在，无法进行相互调用，系统之间互相独立，会造成一部分功能的冗余。比如每个单独的系统可能都要写一套用户登录的代码。

分布式系统架构

垂直架构带来的问题是会带来功能代码的冗余，而随着业务的增加，拆分的应用越多，冗余的代码就越来越多。

那咋整？没错你猜对了，我们可以把冗余部分的代码再次拆解出来，做成统一的业务层供其他地方调用，该业务层就变成了一个单独的服务。

控制层调用不同的业务层服务从而完成不同的业务功能，其具体表现就是一个项目拆分成 表现层 和 服务层 两个部分，服务层中包含业务逻辑，表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现，这就是 分布式架构 。

系统架构展现层采用技术_大数据_04

在分布式架构中，我们把重复的代码抽取出来作为一个公共的服务，提高了代码复用率。同时，我们从图中也可以看到，业务服务之间的调用变复杂了，这就给维护增加了成本。

小结一下分布式系统架构的优缺点：

优点：抽取公共的功能作为服务层，提高代码复用率。
缺点：系统之间的耦合性变高了，调用关系错综复杂，比较难以维护。

SOA

通过前文分析得知，分布式架构中的缺点就是 调用复杂 ，而且当服务越来越多，或者当某一个服务压力过大需要水平拓展和负载均衡时，对于资源的 调度和治理 就需要用到治理中心 **SOA（Service Oriented Architecture）**为核心来解决，同时治理中心还可以帮助 解决服务之间协议不同的问题 。

举个栗子，比如电商系统去调用用户服务时，用户服务的负载均衡中轮询到的那一台主机宕机了，那么治理中心会自动忽略掉这个挂掉的节点，找到健康的节点提供服务。

系统架构展现层采用技术_后端_05

但是，由于服务间有依赖关系，一旦某个环节出现问题，对整个系统的影响较大，也就是常说的 服务雪崩 ！

这种服务关系的复杂，也带来了运维、测试、部署的困难。

服务雪崩

当一个依赖的服务宕机，导致整个应用系统都无法访问的现象就是服务雪崩。

举个例子，服务A和B分别依赖服务C和D，而C和D均依赖服务E：

系统架构展现层采用技术_大数据_06

当这几个服务都正常的时候，调用没有任何问题，当服务E 出现问题无法正常给服务C 和服务D 提供正常的服务时，C和D执行超时重试机制，但是当A和B不断新增请求的时候，C和D对于E的调用请求会 大量积压 ，最终它也会耗尽资源扛不住而倒下的！

系统架构展现层采用技术_系统架构展现层采用技术_07

C和D倒下了，A和B就会不断消耗资源，最终也会宕机下线！直至最后整个应用系统不可访问，服务雪崩。

系统架构展现层采用技术_系统架构展现层采用技术_08

微服务架构

微服务架构是在SOA的基础上进一步拆分，它强调服务应该 彻底拆分 ，从而提高效率。

在微服务架构中，每个服务必须独立部署，并且互不影响，这种架构更加轻巧。

SOA和微服务的不同点在于：

微服务更细，专业人做专业事！
微服务中每个服务独立部署，互不影响。
SOA架构中的数据库可能会发生数据共享，而为服务中每个服务都有自己的数据库。
微服务架构更是个敏捷开发和快速迭代版本。

Spring Cloud发展史

系统架构展现层采用技术_系统架构_09

2020-12-22日Spring 官方博客宣布，Spring Cloud 2020.0.0 正式发布。2020.0.0是第一个使用新的版本号命名方案的Spring Cloud 发行版本。在此之前Spring Cloud 使用英国伦敦地铁站的命名方式来命名一个大版本（train version），如果不按照新的版本号命名的话，本次的版本号应该是Ilford。

更新版本本来是产品的常规操作，但是Spring Cloud的本次更新却正式开启了 Spring Cloud Netflix 体系的终结进程。

Netflix 公司是目前微服务落地中最成功的公司。
它开源了诸如Eureka 、Hystrix 、Zuul 、Feign 、Ribbon 等等广大开发者所知微服务套件，统称为Netflix OSS 。
在当时Netflix OSS 成为微服务组件上事实的标准。
但是在2018年Netflix 公司宣布其核心组件Hystrix 、Ribbon 、Zuul 、Eureka等进入维护状态 ，不再进行新特性开发，只修BUG。
这直接影响了Spring Cloud 项目的发展路线，Spring 官方不得不采取了应对措施，在2019年的在 SpringOne 2019 大会中，Spring Cloud 宣布 Spring Cloud Netflix项目进入维护模式 ，并在2020年移除相关的Netflix OSS 组件。