Spring Cloud开篇-CSDN博客

本文链接：https://blog.csdn.net/m0_74166099/article/details/142762699

学习spring cloud，就先要了解微服务，以及微服务的发展史，下面介绍一下服务架构从单体应用逐渐转变为微服务应用的过程：

单体架构

在早期，公司和企业会把业务的所有功能实现都打包在一个项目，这就是单体架构，业务的所有功能实现都打包在一个war包或者jar包中，这种方式就称为单体架构。

但是当网站的用户量越来越大，需求也会越来越多，流量也越来越大，服务就会面临以下问题：

当然，出现问题就会有优化方案，比如：

集群是将一个系统完整的部署到多个服务器上，每个服务器都能提供系统的所有服务，多个服务器通过负载均衡调度完成任务，每个服务器称为集群的节点。

分布式是将一个系统拆分为多个子系统，多个子系统部署在多个服务器上，多个服务器上的子系统协同合作完成一个特定任务。

从概念上. 集群是多个计算机做同样的事, 分布式是多个计算机做不同的事。
从功能上. 集群的每⼀个节点功能是相同的, 并且可以替代的. 分布式也是多个节点组成的系统, 但是每个节点完成的业务是不同的, ⼀个节点出现问题, 这个业务就不可访问了.
从关系上. 分布式和集群在实践中, 很多时候是互相配合使⽤的. ⽐如分布式的某⼀个节点, 可能由⼀个集群来代替. 分布式架构⼤多是建⽴在集群上的. 所以实际的分布式架构设计中并不会把分布式和集群单独区分, ⽽是统称: 分布式架构.

在分布式架构下, 当部署的服务越来越多, 重复的代码就会越来越多, 服务的调⽤关系也会越来越复杂.我们可以把⼀些通⽤的, 会被多个上层服务调⽤的共享业务, 提取成独⽴的基础服务, 组成⼀个个微⼩的服务. 这就是微服务.

简单来说：微服务就是很小的服务，小到一个服务只对应一个单一的功能，只做一件事，这个服务可以单独部署运行。

分布式: 服务拆分, 拆了就⾏.

微服务: 指⾮常微⼩的服务, 更细粒度的垂直拆分, 通常指不能再拆的服务。

分布式架构侧重于压⼒的分散, 强调的是服务的分散化. 微服务侧重于能⼒的分散, 更强调服务的专业化和精细分⼯. 从实践的⻆度来看, 微服务架构通常是分布式服务架构, 反之则未必成⽴. 所以, 选择微服务通常意味着需要解决分布式架构的各种难题.

微服务带来好处的同时，也面临一些挑战，从单体服务转向微服务意味着管理更加复杂，下面我从优势和挑战两个方面分析一下微服务架构。

服务依赖，随着服务的数量增多，服务之间的关系也会变得更加复杂，一个服务的更改，需要考虑对其他服务的影响。
运维成本：一个业务流程会涉及对多个微服务共同完成，有更多的服务需要
编译, 部署, 运⾏, 甚⾄可能是不同的编程语⾔, 不同的运⾏环境, 当然也需要集群来处理故障转移等. 这对于运维⼈员⽽⾔, 挑战是巨大的。
开发和测试：⼀个业务流程可能涉及多个微服务共同完成, 服务调⽤引⼊⽹络延迟, 不可靠的⽹络, 如何进⾏容错处理等问题. 这对开发和测试⽽⾔, 难度也会提升。
服务监控：在⼀个单体结构中, 很容易实现服务的监控. 因为所有功能都在⼀个服务中, 微服务架构下, 不仅需要对整个链路进⾏监控, 还需要对每⼀个服务实现监控
负载均衡：微服务架构中的服务实例数量可能⾮常庞⼤，因此需要有效的服务发现和负载均衡机制来管理请求流量和保证⾼可⽤性。