基于分布式的微服务架构满足哪些维度？
服务注册与发现
服务调用
服务熔断
负载均衡
服务降级
服务消息队列
配置中心管理
服务网关
服务监控
全链路追踪
自动化构建部署
服务定时任务调度操作
什么是springcloud？
官方：
分布式服务架构的一站式解决方案，是多种微服务架构落地技术的集合体，俗称微服务全家桶。
个人理解：
以前的服务器就好像，一个会语数外全能的老师，为学生提供服务，这个老师生病了，那全校停课。现在微服务流行后，学校有了数学教研组，语文教研组，外语教研组，每个教研组有一群老师具体负责某科的教学，缺了谁，学校都照样运转。
而这个变化中，那些改变历史的程序员就是把一个服务器中的众多服务，或好几台服务器中的众多服务，分类出来，解耦合出来，把他们类似的功能交给同一个集群来做，把互相耦合在一起的功能剥离出来，按业务，按功能来把他们作为一个个微服务放在服务器上，而这个服务器就只提供一个服务，或较少的服务。让一个超大的服务逻辑，解耦合为一个个小服务，均匀的分布在各自的服务器中。微服务就微在这。
每个教研组就是一个微服务集群。他们提供同样的服务，而注册中心Eureka就是这个存放这个教研组老师名单的地方，学生们想先访问这个注册中心获取教师名单，然后根据相应的负载方法去访问各自老师。不至于让集群中某一老师累死也不至于让某一老师闲死。
Zuul网关呢，就是学校的门卫，某些学生来学校找谁，它负责指引（路由），并且通过一些非常简单的配置，达到阻拦一些人进入（身份验证），或者控制想学数学的人只能去数学教研组，不能去核能教研组学怎么造原子弹（权限验证）。
Hystrix熔断器呢，可以把它当成学校的志愿者，当一个教研组集体罢课后，学生找不到老师了，这些志愿者及时的告诉来访问的学生，相应的结果，异常信息等，免得大量的学生在学校等待，这些志愿者赶快把这些等待的学生梳理出去，学生一直在学校等待，那其他需要学生的学校，也会等待学生，最后造成大面积的学校瘫痪。这里学生我们看成一个个请求。熔断器就是把某事故的蔓延即使熔断了。
当然这些组件也是微服务需要注册到Eureka注册中心
Spring Cloud 就可以看成是这个学校了。众多上面提到的组件相当于都是这个学校的各职能部门。
springboot和springcloud版本对应选择
spring boot
源码地址：https://github.com/spring-projects/spring-boot/releases/
中文开发文档：https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.0-Release-Notes
官方推荐：使用2.0+版本——Java 8-Java9
spring cloud
中文开发文档：https://www.bookstack.cn/read/spring-cloud-docs/docs-index.md
官方推荐：G版 H版（过早的版本不再维护）
本系列文章使用的各组件版本：
springcloud各功能组件升级那些事
1,Eureka停用,可以使用zk作为服务注册中心
2,服务调用,Ribbon准备停更,代替为LoadBalance
3,Feign改为OpenFeign
4,Hystrix停更,改为resilence4j
或者阿里巴巴的sentienl
5.Zuul改为gateway
6,服务配置Config改为 Nacos
7,服务总线Bus改为Nacos
