形象化认识Spring Cloud相关组件

一、整体认识

1. Spring framework架构的项目就像一栋高楼大厦，一栋大厦里租用者各色各样的公司和企业为用户提供各种各样的服务。
2. 大厦里的每间办公室都是一个容器，对应着一个docker容器，空办公室对于用户来说是没有任何意义的，只有里面入住了企业(Spring boot)，跑了各种程序，才叫一个微服务结点。
3. 房间号可以理解成容器的ip和端口，企业名理解成微服务的服务名，如果一家企业规模较大，需要租多间办公室才可以，那就是多个容器共同组成一个高可用性的微服务组群。
4. 大厦有一本企业列表，有哪些企业提供哪些服务，对应的房间号是什么，这本列表就是Spring Cloud Eureka。
5. 大厦的大门是所有企业的对外的gateway，用户只能通过大门进去然后进行安检后保安会帮你指路告诉你要找的企业在哪里，这里的大门和门卫就是Spring Cloud Zuul。
6. 也不是所有的房间都是给企业准备的，也有弱点室、茶水间等为所有企业准备的公共设施，这就是Spring Cloud Hystrix的Dashboard、redis、MQ等这些独立的辅助服务。
7. 如果要访问大厦里的某一个企业你只知道企业名，你是不知道具体在哪一楼层哪一房间的，需要去看楼层的导航图或者电梯附近的企业列表（Eureka），如果一个企业有多个房间，客户自己决定进哪一个房间去获取服务，这就是Spring Cloud Ribbon。
8. 如果你今天一连几次都没有在某一个企业获得自己想要的服务，你会过段日子再来试试运气（熔断了），或者约几个人一起来拜访（请求聚合和拆解），这就是Spring Cloud Hystrix。
9. 如果你是有头有脸的重要人物，以上访问一个企业的流程不够上档次，大厦会安排专门的礼仪小姐在电梯口迎接，提高客户满意度，这就是Spring Cloud Feign。
10. 如果你一次性进入这个大厦是要拜访不止一个企业，什么时候进入哪个房间什么时候出来，什么时候又进入了其他的房间这些通过摄像头都有记录，而且都给你拍照留念，这个机制就是Spring Cloud Sleuth。
11. 这座大厦的物业公司叫GitHub，所有企业的保洁阿姨等都是Git上给分配的，每个企业每天换什么样的地毯、卫生程度如何都是保洁阿姨决定的，他们是独立于所有企业但是又影响到所有企业的一个组织，这货就叫Spring Cloud Config。
12. 当然如果物业公司福利足够好，保洁阿姨住集体公寓，每天上下班都有巴士接送，那就成了Spring Cloud Bus。
13. 恰巧房间号701是生产皮革的企业，而房间703是生产LV包包的企业，俩家签订协议后一开始701的人搞到材料就给703送去，结果总是因为703手上活还没干完而且没多余的空间存放又让701给抱回去，于是两家商量好租下了702这个房间，皮革生产上把生产好的皮革直接送到702房里去，LV企业一旦加工完手上的这批包包就去702房里取新的材料来处理，这里702房就相当于一个Kafka或者RabbitMQ，而701和703之间与702之间的集成就是Spring Cloud Stream。

二、服务治理

示例1

现在有很多创业公司，很多城市都有一些经济开发区，在经济开发区有很多写字楼，多个创业公司（类比为一个服务）都会注册进经济开发区大楼（类比为注册中心），租一间写字楼作为办公基地。每个创业公司都要定期向开发区负责人或者机构交房租和物业费，如果某个创业公司不交物业费了，那么该开发区大楼负责人员就会去要，若多次不给，那么就会将其移出开发区大楼。这就是 Eureka 的心跳机制

示例2 租户与房东通过中介租房

​没有中介的时候我们需要一个一个去寻找是否有房屋要出租的房东，这显然会非常的费力，一你找凭一个人的能力是找不到很多房源供你选择，再者你也懒得这么找下去(找了这么久，没有合适的只能将就)。这里的我们就相当于微服务中的 ​​​Consumer​​​​ ，而那些房东就相当于微服务中的 ​​​Provider​​​ 。消费者 ​​​Consumer​​​ 需要调用提供者 ​​​Provider​​​ 提供的一些服务，就像我们现在需要租他们的房子一样。

但是如果只是租客和房东之间进行寻找的话，他们的效率是很低的，房东找不到租客赚不到钱，租客找不到房东住不了房。所以，后来房东肯定就想到了广播自己的房源信息(比如在街边贴贴小广告)，这样对于房东来说已经完成他的任务(将房源公布出去)，但是有两个问题就出现了。第一、其他不是租客的都能收到这种租房消息，这在现实世界没什么，但是在计算机的世界中就会出现资源消耗 的问题了。第二、租客这样还是很难找到你，试想一下我需要租房，我还需要东一个西一个地去找街边小广告，麻不麻烦？

那怎么办呢？我们当然不会那么傻乎乎的，第一时间就是去找 中介 呀，它为我们提供了统一房源的地方，我们消费者只需要跑到它那里去找就行了。而对于房东来说，他们也只需要把房源在中介那里发布就行了。

但是，这个时候还会出现一些问题。

房东注册之后如果不想卖房子了怎么办？我们是不是需要让房东定期续约 ？如果房东不进行续约是不是要将他们从中介那里的注册列表中移除 。

租客是不是也要进行注册 呢？不然合同乙方怎么来呢？

中介可不可以做连锁店 呢？如果这一个店因为某些不可抗力因素而无法使用，那么我们是否可以换一个连锁店呢？

针对上面的问题我们来重新构建一下上面的模式图

三、断路器/熔断器

比如去银行办理业务，本来有四个窗口都可以办理，现在3号窗口和4号窗口的办理人员有事要离开(服务异常)，那么自然地，用户就会跑去1号窗口或者2号窗口办理，所以1号和2号窗口就会承担更多的压力。

3号窗口和4号窗口的人有事走了，不能让人还在这排队等着吧，否则就出现了上文说的雪崩了，所以会挂一个牌子：暂停服务。这个牌子好比上文提到的熔断，然后返回一个默认的信息，让用户知道。等3号和4号窗口的人回来了，就会把这个牌子拿走，这两个窗口又可以继续回复服务了。

​

​

​

​