SpringCloud学习-01

了解集群/分布式/微服务/SOA

集群

本人语言水平不高，通俗易懂的理解。多个单体计算机互相沟通工作，把所有该工作的下计算机群体叫做集群。而每个单体计算机称为一个节点。就像树形结构，思维导图一样，树形结构中的节点是每个计算机，而整个树形结构图称为一个集群。
但集群不光只有一种分工连接方式，只是通过多个计算机完成同一工作，也可以两台计算机完成同样工作，其中一台做备用计算机。也可以做负载均衡，俩台计算机同时作为服务器为不同位置的人服务同一个项目。

分布式

分布式的原理就更简单了，分布式是指一种工作模式和项目上线后的部署思路。
相当于在集群的基础上分清各计算机(程序员)的业务和业务模块。看到个例子挺有意思的，目前的前后端分离举例，其中一个人前端不会，只会写JAVA。一个人只会写前端，而JAVA并不是很会。那么如何分配呢？。。。。。 这也是一种分布式，当然前后端分离并不是因为要分布式而分，而是多方面，包括技术，实际业务上来说的。而前后端分离的模式，降低了技术多面需求，如业务中即要改前端页面又要改后端业务逻辑，这样自己做一项业务一方面容易耦合度过高，另一方面也增加了人力资源，所以前后端分离是不可避免的普及，而且大家要珍惜还在干全栈的人才。说的有点多但总结下来 分布式系统 就是一种由通讯线路稳定，来把系统分开到不同的资源计算机中的来达成项目的耦合度降低，甚至耦合度几乎变的松散，实现物理的解耦和软件的解耦。 计算机可以分别放在随意位置，只有通讯线路来做整合。

微服务

还是自我理解上的。微服务是在分布式上的基础来架构出来的一种思想，分布式架构相当于在物理层面分开业务需求，实现的是不同计算机（服务器）的区域性不需要统一。 而微服务是在软件上的分布式思想的架构风格，把一个实际项目中的需求，按照业务需求，实际情况来解耦，来避免统一的集中式的服务管理机制。 好处是可以实现一个项目中，不同业务需求甚至可以按照不同的开发语言，不同的开发环境 来构成一个项目的后台。

通常微服务都是以Http中的 Restful API风格来相互沟通信息。 就每个业务服务中 只暴露接口 来达成信息的交互和互相业务逻辑调用。
技术层面上，微服务拆分了所有业务，分开业务所有数据库，每个业务逻辑包含在该业务的微服务模块中，数据库每个业务单独存在。就像前后端分离，只不过这里只有俩个服务，一个叫前端，只管接收数据提供给用户来交互，另一种叫后端，提供给前端所需要的数据，这里也是通过接口信息Restful风格来进行数据交互，只不过并没有按照实际业务来划分模块化。这里只说后台，把后台模块化根据业务来划分就达到了微服务的架构风格。

字打的有点多，但毕竟不是专业的，所以把自己的想法和专业的知识糅杂在一起，实现自己的理解，就容易记。但这些基础知识可能在实际中并起不到关键作用，但这就像多出去旅游，听导游介绍一样，多介绍多长见识，记不记得住不是关键，而是理解各种专业知识后，可能会开拓自我视野，给自己提供一种思路。

SpringCloud

SpringCloud 就是以 Spring 全家桶中 为了微服务而提供的开发框架，与SpringBoot来说，相当于分成了多个Boot微服务项目。 提供了统一的通讯模式和接口的统一管理。 毕竟SpringBoot 是为了单个项目的快速开发。
SpringCloud和Dubbo 类似，但dubbo功能相比不如Cloud 简便功能全。

SpringCloud 提供了微服务管理中心来做管理，

1.服务注册中心
提供了 zookeeper consul nacos 注册中心，以前也提供Eureka ，但Eureka 现在不提供开源版本，SpringCloud 貌似已经不支持eureka了。
2.服务调用
ribbon 和 loadBalancer 有些东西是学完才能理解，之后在补详情吧。

下图SpringCloud 提供的模块技术

SpringBoot 与SpringCloud版本兼容以及对应关系
附上链接一条。该链接为Spring 官网提供的对应关系

目前找下来基本可以用zookeeper 来替代eureka 来进行注册中心的管理框架。而且阿里也推出了一款 Nacos 微服务注册中心。
那就来学习zookeeper 吧

zookeeper

Zookeeper 是一种分布式协调服务，用于管理大型主机。在分布式环境中协调和管理服务是一个复杂的过程。zookeeper通过其简单的架构和API 解决了这个问题。zookeeper 允许开发人员专注于核心应用程序逻辑，而不必担心应用程序的分布式特征。
zookeeper框架最初是在 yahoo！上构建的，用于以简单而文件的方式访问他们的应用程序。
简单的背景故事和简介，人眼复制手打的。 用于了解下背景故事，比较容易在脑中形成一个事件映射，还能了解一些偏门的故事。还有eureka的背景故事也挺有意思的，好像是网飞开发的，本身网飞找到的路是线下光盘转成线上点播模式，但模式刚转变后爆火，钱没到位没办法只能加负载均衡所以碰巧开发出的一个框架，后序被应用到了SpringCloud上。yahoo也是差不多的故事，淘宝应该也有类似的情况，当时开发的东西在后续中被应用到了其他方面上。

zookeeper 架构图

Leader： zookeeper 集群工作核心，事务请求的唯一调度和处理者，保证集群事务处理的顺序性，作为数据唯一性的关键服务器。且Leader 有自己的选举机制。
Follower： 处理客户端非事务请求 转发事务请求给Leader进行处理。当Leader服务器丢失后，Follower会投票进行集群中新的Leader 选出。
Observer ： 为了处理集群中的并发请求而存在，主要处理非事务请求。对于事务请求，也会转发到Leader 来进行处理，不会参与任何形式投票。 主要以处理非事务请求来增加集群中的并发请求处理。

zookeeper的特性

1.全局数据的一致性： 每个server都保存一分相同的数据副本，client无论连接哪个server，展示的数据都是一致的
2.可靠性： 如果数据被一个server 接收，则其他server必须接受
3.顺序性： 包括 全局有序和偏序 两种：俩个消息，一台服务器中 a消息先发布b消息后发布，其他服务器必须都是a先b后，这是全局有序，一台服务器接受顺序，其他服务器都接受顺序。 偏序是指同一发布者的顺序，a先b后 ，a必须排在b的前面。（偏序不是特别理解为什么这么写，可能在实际使用情况中会发生一些乱序问题，可能像线程？当无锁线程在执行时，会发生那种顺序并不是根据代码顺序来执行的情况，但他既然这么写，只能理解成ab消息必有先后顺序，且有序后必备其他服务器接受顺序）
4.数据更新原子性： 一次数据更新要么成功，要么失败，不存在中间状态。（事务，要么提交，要么回滚）
5. 实时性：zookeeper 保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。（集群确保每个server在一定时间中更新服务器状态，是有更新信息还是服务器失效信息。）

分布式的缺点

1. 竞争条件 俩个或多个服务尝试执行特定任务时候，实际情况上只需要在任意给定时间由单个机器完成。例如 :共享资源只能在任意给定时间由单个机器修改。
2. 死锁 两个或多个操作等待彼此无限期完成
3. 不一致 数据的事务部分失败

如果任务需求直接学习RestTemplate 写法即可，分布式中不同模块基本沟通实现都是采用，提供接口，不同服务之间发送请求来进行沟通。 zookeeper 相当于项目中的不同模块服务器的总控。