SpringCloud学习（二、分布式和集群的一些概念的问题）

一、SpringCloud单架构

SpringCloud单架构其实就是我们之前使用的SpringBoot项目，这里我们打开一个SpringBoot项目如下图：

springcloud 我们会使用 Finchley 这个版本，而它对 springboot 的版本依赖是 2.0.3.RELEASE， 所以我们会用 2.0.3.RELEASE 这个版本的 springboot 来做。

运行以后如下图：

表格里面的数据是我们在service里面添加的：

在正式项目中就是我们读取数据库里面的内容。这里手动编辑几个数据举例。

这个项目很简单，就做两件事： 1. 提供数据 2. 展示数据。 这就是一个典型的单体结构。

它把提供数据、展示数据这两个服务放到了一起，这样就会出现固有的弊端：

1. 如果要修改数据部分的代码， 那么必须把整个项目重新编译打包部署。 虽然展示部分，什么都没变但是也会因为重新部署而暂时不能使用，要部署完了，才能使用。
2. 如果提供数据部分出现了问题，比如有的开发人员改错了，抛出了异常，会导致整个项目不能使用，展示数据部分也因此受到影响。
3. 性能瓶颈难以突破
4. 等等。。。

以上就是单体结构的问题，接下来，我们会把这个单体结构的项目，改造成为springcloud 微服务分布式架构，通过观察和参与改造过程，就能够掌握和理解 springcloud啦。

二、分布式和集群

要说springcloud 分布式之前，先引入微服务概念。
1、微服务

简单说，一个 springboot 就是一个 微服务，并且这个 springboot 做的事情很单纯。 比如 product-service 这个项目，就可以拆成两个微服务，分别是 数据微服务，和视图微服务，其实就是俩 springboot, 只是各自做的事情都更单纯~

2、服务注册

那么有了微服务，就存在如何管理这个微服务，以及这两个微服务之间如何通信的问题，所以就要引入一个 微服务注册中心概念，这个微服务注册中心在 springcloud 里就叫做 eureka server, 通过它把就可以把微服务注册起来，以供将来调用。

3、服务访问

在业务逻辑上， 视图微服务 需要 数据微服务 的数据，所以就存在一个微服务访问另一个微服务的需要。 
而这俩微服务已经被注册中心eureka管理起来了，所以 视图微服务 就可以通过 注册中心定位并访问 数据微服务了。

4、分布式的概念

系统改造到现在，就可以说是分布式了~ 简单说，原来是在一个 springboot里就完成的事情，现在分布在多个 springboot里做，这就是初步具备 分布式雏形了。
那么分布式有什么好处呢？ 
4.1. 如果我要更新数据微服务，视图微服务是不受影响的
4.2. 可以让不同的团队开发不同的微服务，他们之间只要约定好接口，彼此之间是低耦合的。
4.3. 如果视图微服务挂了，数据微服务依然可以继续使用

5、集群的概念

原来数据微服务只有这一个springboot, 现在做同样数据微服务的，有两个 springboot, 他们提供的功能一模一样，只是端口不一样，这样就形成了集群。
那么集群有什么好处呢？
1. 比起一个 springboot, 两个springboot 可以分别部署在两个不同的机器上，那么理论上来说，能够承受的负载就是 x 2. 这样系统就具备通过横向扩展而提高性能的机制。
2. 如果 8001 挂了，还有 8002 继续提供微服务，这就叫做高可用 。

6、分布式和集群周边服务

以上是很简单的分布式结构，围绕这个结构，我们有时候还需要做如下事情：

6.1 微服务之间是如何彼此调用的？ sleuth 服务链路追踪

6.2 如何在微服务间共享配置信息？配置服务 Config Server

6.3 如何让配置信息在多个微服务之间自动刷新？ RabbitMQ 总线 Bus

6.4 如果数据微服务集群都不能使用了， 视图微服务如何去处理? 断路器 Hystrix

6.5 视图微服务的断路器什么时候开启了？什么时候关闭了？ 断路器监控 Hystrix Dashboard

6.6 如果视图微服务本身是个集群，那么如何进行对他们进行聚合监控？ 断路器聚合监控 Turbine Hystrix Dashboard

6.7 如何不暴露微服务名称，并提供服务？ Zuul 网关

在接下来的几节博客里面，我们将共同来解决这些问题，大家加油！