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

2022-11-22 16:36:46 浏览数 (1)

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

项目架构演变史

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

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

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

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

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

应用架构体系演进

单体应用架构

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

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

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

单体架构：所有模块均在同一工程节点

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

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

垂直应用架构

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

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

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

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

分布式系统架构

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

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

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

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

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

SOA系统架构

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

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

服务雪崩

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

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

服务依赖

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

由于服务依赖导致部分服务不可用

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

服务雪崩

微服务架构

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

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

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

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

Spring Cloud发展史

Spring Cloud版本演进

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」 组件。

这给Spring Cloud Alibaba成为微服务开发的主流选择提供了机会。

Spring Cloud Alibaba成为微服务开发的主流选择

初识Spring Cloud Alibaba

「Spring Cloud Alibaba」 致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。

依托 Spring Cloud Alibaba，只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里微服务解决方案，通过阿里中间件来迅速搭建分布式应用系统。

Spring Cloud Alibaba主要功能及其组件

Spring Cloud Alibaba 的主要功能及相应的组件介绍在其开源项目有详细的介绍，参考：Spring Cloud Alibaba

小结

  • 系统应用架构从单体架构逐步演变成微服务架构，期间经过单体应用架构、垂直应用架构，分布式架构、SOA架构以及微服务架构。
  • 微服务落地方案之Spring Cloud拥有极强的生命力，其生态非常强大。
  • Spring Cloud Alibaba加入微服务主流生态圈Spring Cloud，将是我们落地微服务方案的主流选择。

后续，我将从 「注册中心和配置中心 Nacos」 开始，从实战到原理一步步掌握 「Spring Cloud Alibaba」 微服务技术栈，敬请期待。

微服务 spring springcloud 系统架构

0 人点赞