- 介绍
本博客探讨的内容如下所示
什么是微服务？
什么是springcloud？
微服务和springcloud有什么关系？
首先，没有在接触springcloud之前，我写的项目都是单体结构， 但随着网站的用户量越来越大，需求也会越来越多，流量也会越来越大。单体架构的弊端也就随之浮现了：
后端服务器的压力越来越大，负载越来越高，甚至出现无法访问的情况。
业务场景逐渐复杂，为了满足用户的需求，单体应用也会越来越大，各个业务代码之间的耦合度也会越来越高，并且出现任何一个问题，都需要对整个项目重新编译和发布。
一个微小的问题，可能会导致整个应用挂掉。
以上这三种问题，我打算通过一个例子进行讲解:
比如：现有一个超市，因为服务好价格便宜，而火遍全网，就会用户量越来越大，需求也就会越来越多，上面的问题就会随之出现：
顾客多了，但服务员的数量不变，所以服务员就会忙不过来，甚至有些顾客压根就找不到服务员在哪里。
需求多了，我们就需要对超市进行改进，比如说本来超市只是卖日用品。有些人给出建议，可不可以卖把菜也卖了，我就不需要去别的地方了，所以我们为了满足用户的需求，我们就需要进行的开发，耦合度就是：比如添加一个卖菜市场，此时菜货源就需要问服务员菜放哪里，等问题就需要各个业务的交互。
名气出来了，关注的人就越来越多，突然有一次有人在网上发文，本家超市菜品质量有问题，不新鲜，这时候就会在网上发酵，可能会导致这个超市的销量大幅度下降，因为大家都是绑在一根绳上的蚂蚱，然后部分出现问题都会影响整体。
- 解决方案
横向：添加服务器(集群)
纵向：把一整块业务划分成不同模块(分布式)
应用：最开始机器只有一千个用户，后来增加到了一百万用户
横向：扩容机器。扩展到100台机器，每台承担1000用户。
纵向：按照功能进行划分，分别部署到不同机器中。
上面简单介绍了：什么是分布式什么事集群，下面介绍概念：
2.1 集群和分布式
集群(cluster)是将一个系统完整的部署到多个服务器上,每个服务器都能提供系统的所有服务,多个服务器通过负载均衡调度完成任务.每个服务器称为集群的节点(node)
分布式是将一个系统拆分为多个子系统，多个子系统部署在多个服务器上，多个服务器上的子系统协同合作完成一个特定任务.
举例
餐馆
只有一个厨师,这个厨师负责做饭相关的所有工作
随着餐馆的生意的好转,一个厨师忙不过来
横向: 招聘一个厨师,这两个厨师都可以独立做饭
纵向: 厨师的工作分为: 洗菜,切菜, 配菜,炒菜
招聘一个配菜师,负责洗菜,切菜,配菜
生意更加好了
再招聘多个配菜师,多个厨师
2.2 集群和分布式区别和联系
从概念上看
集群是多个计算机做同样的事,分布式是多个计算机做不同的事
从功能上看
集群的每一个节点功能是相同的,并且可以替代的,分布式也是多个节点组成的系统,但是每个节点完成的业务是不同的,一个节点出现问题,这个业务就不可访问了.
从关系上看
分布式和集群在实践中,很多时候是互相配合使用的
比如分布式的某一个节点,可能由一个集群来代替,分布式架构人多是建立在集群上的,所以实际的分布式架构设计中并不会把分布式和集群单独区分,而是统称:分布式架构.
2.3 微服务
如果你第一次接触微服务，你肯定会想所谓微服务就是微小的服务呗 ！
还不瞒你说，你真猜对了，正是微小的服务，通常情况下，我们认为一个微服务只做一件事。
微服务是一种分布式架构方案，只不过是更加细微的拆分，微服务一般提供的就是个位数的接口。
2.4 微服务和分布式的区别和联系
分布式: 服务拆分,拆了就行.
微服务: 指非常微小的服务,更细粒度的垂直拆分,通常指不能再拆的服务
举例：
岗位划分: 前端,后端, 运维,数据库管理员等等
分布式: 划分了就可以了
微服务: 不仅仅划分,还拆分的很细,比如后端开发,分为: 系统开发,数据开发,策略开发等等...
分布式架构侧重于服务的分散(压力分散)，微服务侧重于能力分散(更加细微的拆分)
微服务是分布式服务的子集
2.5 扩展：架构的发展介绍
架构分为：单体架构 -> 垂直架构 -> 分布式 -> 微服务架构
具体选用什么样的架构，取决于你的业务，有时候需要考虑成本，就比如你在写一个项目本身就少的功能，你还有必要拆分出这么多的微服务接口吗 ？
如果业务增多可以进行拆分成更高的架构
也没必要都又单体进行修改，如果预值到业务比较大，可以选择更大的架构
总之架构没有什么好与坏，都是为了义务来衡量好与坏的。局部的好与坏。
下面是微服务架构的例子
2.6 微服务的优势和挑战(问题)
优势
易开发和维护：每个微服务负责的业务比较清晰，体量小，开发和维护成本降低。
容错性高：一个服务发生故障，可以使故障隔离在单个服务中，不影响整体服务的故障。
扩展性好：每个服务都是独立运行的，我们可以根据项目实际情况进行扩展，按需伸缩。
技术选型灵活，每个微服务都是由单独的团队来运维，可以根据业务特点和团队特点选择适合的技术栈。
简单概括一下上述吧
清晰(见名知意)，体积小，开发和维护就比较简单。
容错性好，一个服务挂了，不太影响整体的服务故障。
扩展性好，每个都是独立运行的，可以在每个模块都自定义需求。
比如说学校系统，保洁和老师上班的时间是不同的，我们可以在不同的服务设置自定义的考勤规则。
也可以按照不同的需求进行，选择扩容，比如商品模板访问量比较大，但订单管理比较少，可以让商品管理部署五台机器，订单管理部署两台机器，可以按需进行伸缩。
技术选型比较灵活
比如一个微服务比较偏业务可以使用java，有些偏算法就可以使用python。
挑战
虽然微服务具备很多的优势，但由于服务数的增加，服务治理也是我们面临的巨大挑战。人多了，管理就比较困难了，各部分工作人员怎么进行沟通呢？
服务依赖：随着服务的数量增多，服务之间的关系也会变得更加复杂，一个服务的更改需要考虑对其他服务的影响。
运维成本：一个业务流程会涉及多个微服务共同完成，有更多的服务需要编译、部署、运行，甚至可能是不同的编程语言、不同的运行环境，当然也需要集群来处理故障转移等，这对于运维人员而言挑战是巨大的。
开发和测试：一个业务流程可能涉及多个微服务共同完成，服务调用引入网络延迟、不可靠的网络，如何进行容错处理等问题，这对开发和测试而言难度也会提升。
服务监控：在一个单体结构中，很容易实现服务的监控，因为所有功能都在一个服务中。微服务架构下，不仅需要对整个链路进行监控，还需要对每一个服务实现监控。
负载均衡：微服务架构中的服务实例数量可能非常庞大，因此需要有效的服务发现和负载均衡机制来管理请求流量和保证高可用性。
什么是负载均衡？
集群部署的时候，到底哪个人来做呢，这就需要负载均衡。
现在你应该会有这样的疑惑？springcloud呢？那么我将介绍springcloud。
2.7 SpringCloud概念
SpringCloud就是为了解决这些自己开发微服务出现的问题。解决方案：使用springcloud提供的工具解决。
Spring Cloud 是一站式的分布式微服务架构的解决方案，集成了多种技术，包括：
Distributed/versioned configuration：分布式版本配置
分布式管理配置：每个版本所有配置的信息都不同。
Service registration and discovery：服务注册和发现
服务注册和发现比如服务挂掉了和新增服务了，都会被记录和通知。
Routing：路由
请求发到哪个服务
Service-to-service calls：服务间调用
服务之间的联系
Load balancing：负载均衡
机器有100个，如何根据流量分配这100个机器均匀不让有些非常忙有些非常闲。
Circuit Breakers：断路器
断路器是一种用于处理分布式系统中服务调用失败的机制，断路器的工作原理类似于电路中的断路器，当检测到服务调用失败率达到一定阈值时，断路器会打开（即触发熔断），停止向该服务发起请求，而是直接返回一个预先定义的错误响应（通常是快速失败），从而避免进一步的资源消耗和降低系统的负载。
Distributed messaging：分布式消息
Spring Cloud 提供了这些功能来帮助开发人员快速构建和部署微服务架构，简化了微服务之间的通信和协调，提高了系统的弹性和可靠性。通过Spring Cloud，开发人员可以更加专注于业务逻辑的实现，而不必过多关注底层的分布式系统架构实现细节。
Spring Cloud 是针对微服务架构中遇到的各种问题，各大公司在寻找解决方案时发现了一些好的模块和技术，而 Spring Cloud 就是基于 Spring Boot 风格，整合了这些优秀的模块和技术，进一步封装了复杂的配置和功能，为开发人员提供了简单而强大的工具，帮助他们更轻松地构建和部署微服务系统。
- 总结
这篇博客详细介绍了微服务架构、SpringCloud以及它们的关系，以及在实际应用中的解决方案和优势挑战。文章通过生动的比喻和实例，清晰地阐述了单体架构的局限性以及引入微服务架构的必要性。此外，还介绍了集群和分布式的概念以及微服务与分布式的区别和联系。最后，对SpringCloud进行了详细介绍，说明其作为一站式的分布式微服务架构的解决方案所涵盖的技术和功能。文章内容全面且通俗易懂，对于想要了解微服务架构和SpringCloud的读者来说是一份很好的参考资料。
此外祝大家六一儿童节快乐玩的开心！
