IDEA中从零开始搭建Spring Cloud微服务

微服务简介

微服务就是将原来的单体应用按义务范围来进行划分，划分为多个小model，每个微服务运行在自己的进程中，不相互影响，通过完全自动化部署来独立部署。并使用轻量级机制通信，通常是HTTP RESTUFUL API。可对各个微服务进行集中管理。这些小model可以使用不同的编程语言，以及不同的存储技术。微服务架构是分布式架构。

目前主流微服务架构有：dubbo与spring could。简单来说他们之间区别在于spring cloud是一整套生态架构，开箱即用，集成了负载均衡、网关服务、熔断器等。

单体式与微服务区别与优缺点

传统单体架构缺点

复杂性逐渐变高：一个项目代码量大模块区别模糊逻辑混乱
技术债务逐渐上升：项目人流量较大无法掌握项目留下的一些坑
部署速度逐渐变慢：项目代码庞大，启动速度慢
阻碍技术创新：更换项目技术困难，因为模块之间有千丝万缕联系
无法伸缩扩展：提升模块性能需要考虑其他模块，不能因扩展某模块导致另一模块性能

微服务架构优点

易于开发和维护
启动速度快
局部修改容易部署
技术栈不受限制
按需伸缩

spring could简介

Spring cloud是基于spring boot实现的微服务架构开发工具。他为微服务架构中涉及的配置管理、服务治理、断路器、只能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了简单的开发方式。
重点介绍五大组件：
服务发现——Netflix Eureka
动态代理机制，根据注解和选择机器,拼接Url地址,发起请求——Feign
客户端负载均衡——Netflix Ribbon
断路器——Netflix Hystrix
服务网关——Netflix Zuul

服务发现架构–Eureka

举例：租房子找中介事情例子
在没有中介的时候我们需要一个一个去寻找是否有房屋要出租的房东，这显然会非常的费力，凭一个人的能力是找不到很多房源供你选择，再者你也懒得这么找下去(找了这么久，没有合适的只能将就)。
这里的我们就相当于微服务中的 Consumer ，而那些房东就相当于微服务中的 Provider 。消费者 Consumer 需要调用提供者Provider 提供的一些服务，就像我们现在需要租他们的房子一样。
这样会出现一些问题，比如：房东找不到房客，房客找不到房东，所以需要引入中介。
房东在中介发布招租信息，租客直接挑房消费
服务发现：其实就是一个“中介”，整个过程中有三个角色：服务提供者(出租房子的)、服务消费者(租客)、服务中介(房屋中介)。
服务提供者：就是提供一些自己能够执行的一些服务给外界。
服务消费者：就是需要使用一些服务的“用户”。
服务中介：其实就是服务提供者和服务消费者之间的“桥梁”，服务提供者可以把自己注册到服务中介那里，而服务消费者如需要消费一些服务(使用一些功能)就可以在服务中介中寻找注册在服务中介的服务提供者。

负载均衡之 —Ribbon

如果这个时候我们没有进行一些 均衡操作 ，如果我们对 秒杀系统1 进行大量的调用，而另外两个基本不请求，就会导致 秒杀系统1 崩溃，而另外两个就变成了傀儡，那么我们为什么还要做集群，我们高可用体现的意义又在哪呢？

所以 Ribbon 出现了，注意我们上面加粗的几个字——运行在消费者端。指的是，Ribbon 是运行在消费者端的负载均衡器，也即是服务之间调用需要采用负载均衡，如下图。

其工作原理就是 Consumer 端获取到了所有的服务列表之后，在其内部使用负载均衡算法，比如：线性轮询、随机算法等，进行对多个系统的调用。

断路器

服务C阻塞了还好，毕竟只是一个系统崩溃了。但是请注意这个时候因为服