微服务(一)之分布式、微服务小结

							✨ 我是喜欢分享知识、喜欢写博客的YuShiwen，与大家一起学习，共同成长！
									  📢 闻到有先后，学到了就是自己的，大家加油！
📢 导读：
本期总共有2个章节，
⛳️ 第一个章节是介绍分布式和微服务以及他们之间的区别。
⛳️ 第二个章节是简要概括微服务的解决方案之一Spring Cloud，其中介绍了它最核心的七大组件以及一些相关的专有名词。

我们会在后面的博文中进行详细讲解，此篇是微服务相关内容的第一篇，先让大家有个大致印象，后续博文在进行详细介绍。
以后笔者会专门写微服务相关的博文对每一个内容进行逐一讲解，如果期待更多干货和知识分享和后续与微服务相关的文章，那就动动小指头点波关注吧！
								

  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
  
9
  
10
 

1.微服务和分布式是什么？

从最开始的单体架构，一个war包或者一个jar包中包含一个应用所有的功能；
到集群，多台服务器部署相同应用构成一个集群;
在到SOA（Service-oriented architecture，面向服务架构）的提出，最后到微服务架构的兴起，它把SOA继续拆分成了更小的服务，一步一步进行着解耦，逐渐方便着我们的开发和管理。

在此期间，我们经常听说微服务、分布式，那么他们是同一个概率吗？首先我们必须清楚：

• 微服务是架构设计方式；
• 分布式有两种概念，即可指架构设计方式也可指系统部署方式。
• 总结就是微服务分散能力 ；分布式分散压力 。

下面为们具体讲解：

1.1.分布式

分布式的核心思想就是拆，然后分开部署。

1.1.1分布式系统部署方式

• 把服务进行拆分，分别部署到不同的机器上。
• 分布式服务顾名思义服务是分散部署在不同的机器上的，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是通过rpc来交互或者是webservice来交互的。
• 系统应用部署在超过一台服务器或虚拟机上，且各分开部署的部分彼此通过各种通讯协议交互信息，就可算作分布式部署。

1.1.2分布式架构设计方式

• 把项目拆分成多个模块，并将这些模块分开部署。
• 拆分有两种方式：
  • 水平拆分，是指按照业务对系统进行划分 。
    比如一个电商项目中包括了交易，用户，导购等系统，按照水平拆分的原则进行拆分，系统可以拆分成 交易系统，用户系统、导购系统系统等。
  • 垂直拆分，是将同样的系统按照应用场景(调用方)进行拆分 。
    比如一个交易系统的支付模块，可以垂直拆分为用户支付和商家支付两个调用流程。按照垂直拆分的规则就可以将支付模块拆分为用户支付和商家支付模块。

分布式架构设计方式主要是指水平拆分。

1.2.微服务

微服务的核心思想是微小的服务，也可以理解为为一种非常细粒度的垂直拆分。

• 微服务架构是垂直的拆分，在1.1.2中我们提到过按照垂直拆分的规则就可以将支付模块拆分为用户支付和商家支付模块。（因为水平拆分后的交易系统它还能再拆，而微服务应该是不能再拆的“微小”服务，类似于“原子性”）。
• 简单来说微服务就是很小的服务，小到一个服务只对应一个单一的功能，只做一件事。这个服务可以单独部署运行，服务之间可以通过RPC来相互交互，每个微服务都是由独立的小团队开发，测试，部署，上线，负责它的整个生命周期。
• 各服务间隔离（分布式也是隔离）。

1.3.微服务和分布式的区别总结

分布式：拆了就行，分布式解决网站高并发带来问题;
微服务：细粒度的垂直拆分，进行了解耦操作。

• 生产环境下的微服务肯定是分布式部署的，分布式部署的应用不一定是微服务架构的，比如集群部署，它是把相同应用复制到不同服务器上，但是逻辑功能上还是单体应用。
• 微服务相比分布式服务来说，它的粒度更小，服务之间耦合度更低，由于每个微服务都由独立的小团队负责，因此它敏捷性更高，分布式服务最后都会向微服务架构演化，这是一种趋势， 不过服务微服务化后带来的挑战也是显而易见的，例如服务粒度小，数量大，后期运维将会很难

2.微服务解决方案之Spring Cloud

2.1.为什么要选用Spring Cloud

为什么要选用Spring Cloud呢？
原因有以下几点：

1. 因为产出于Spring大家族，有很多人去维护，可以保证后续的更新、完善。
2. 基于Spring Boot ，对于我们之前学过Spring Boot的更容易上手。
3. 作为一个微服务治理的大家伙，考虑的很全面，几乎服务治理的方方面面都考虑到了，方便开发开箱即用。
4. 轻轻松松几行代码就完成了熔断、均衡负责、服务中心的各种平台功能。
5. Spring Cloud用的人多，教程很丰富，遇到问题很容易找到解决方案。

2.2.Spring Cloud七大核心组件

2.2.1注册中心

注册中心可以说是微服务架构中的”通讯录“，它记录了服务和服务地址的映射关系。在分布式架构中，服务会注册到这里，当服务需要调用其它服务时，就到这里找到服务的地址，进行调用。

• provider（服务提供者）: 启动的时候向注册中心上报自己的网络信息。
• consumer（服务消费者）: 启动的时候向注册中心上报自己的网络信息，拉取provider的相关网络信息。

常见的注册中心组件有：Eureka、Zookeeper、Consul和Nacos。
关于注册中心，笔者接下来的博文会重点讲解其中的Nacos。

2.2.2配置中心

• 在微服务架构中，由于服务较多，相同的配置（如数据库信息、缓存、开关量等）会出现在不同的服务上，如果一个配置发生变化，则可能需要修改很多的服务配置。
• 分布式系统中，为了方便服务配置文件统一管理，方便所有的微服务能够实时更新，所以需要分布式配置中心组件。

常见的配置中心有：Spring Cloud Config、阿里Nacos、携程Apollo、谷歌Consul。
关于配置中心，笔者接下来的博文会重点讲解Nacos。可以看到Nacos目前已经在占据了其中的二大核心了。

2.2.3负载均衡

负载均衡是指将访问流量根据负载均衡算法分发到后端服务器，从而让所有的请求都能够得到很快的响应，从而提高微服务的性能。
常见的负载均衡算法：

• 简单轮询
• 加权轮询
• 简单随机
• 加权随机
• 一致性哈希
• 最小活跃数

这些算法在之后的博文中笔者会进行详细讲解。
常见的的负载均衡有：lvs、ribbon、nginx。

2.2.4RPC调用

• 首先我们要明白Http协议是在TCP协议之上，http这个过程是发生在应用层的，Restful风格就可以通过Http协议来实现。
• RPC，即远程过程调用，直接基于TCP进行远程调用，数据传输在传输层TCP层完成，更适合对效率要求比较高的场景，底层实现比REST更复杂，但是这样减少了一层协议的封装，使得传输效率更改。

常见的RPC有：Dubbo、gRPC、Thrift、Feign。

2.2.5服务网关

• 服务网关是整个微服务架构中对外的统一入口。
• 服务网关可以这样简单理解：服务网关 = 过滤器
  即在服务网关中可以完成一系列的横切功能，例如权限校验、限流以及监控等，这些都可以通过过滤器完成（其实路由转发也是通过过滤器实现的）。

常见的网关有：Kong、Zuul、Spring Cloud Gateway。

2.2.6服务熔断

当某个服务单元发生故障之后，通过断路器的故障监控（类似于物理的熔断保险丝）， 向调用方返回一个符合预期的、可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方无法处理的异常 ，这样就保证了服务调用方的线程不会被长时间、不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

常见熔断器有：Hystrix、Sentinel。

2.2.7控制总线

• 控制总线也称为消息总线，是微服务架构中用来连接系统中所有节点的，微服务中所有的服务节点可以通过控制总线来进行通讯。
• 微服务一般都采用集群方式部署，而且在高并发下经常需要对服务进行扩容、缩容、上线、下线的操作。比如我们需要更新配置，又或者需要同时失效所有服务器上的某个缓存，需要向所有相关的服务器发送命令，此时就可以选择使用 Spring Cloud Bus 了。

常见的控制总线有：Spring Cloud Bus 、Nacos。

2.3其他名词

• 服务降级
• 服务限流
• 全局锁（分布式锁）
• 分布式事务
• 服务安全
• 链路追踪
• 集群管理
• 事件驱动
• 云连接器
• 函数计算

关于上述2.2章节和2.3章节提到的七大核心组件和一些相关名词，我们会在后面的博文中进行详细讲解，此篇是微服务相关内容的第一篇，先让大家有个大致印象，后续会写很多篇微服务相关的博文对上述内容进行详细讲解，如果期待更多干货和知识分享，可以先点个关注，笔者后续会对上述内容做详细讲解。

文章来源: blog.csdn.net，作者：Mr.Yushiwen，版权归原作者所有，如需转载，请联系作者。

原文链接：blog.csdn.net/MrYushiwen/article/details/123195486