Spring Cloud 是实现微服务架构的一中工具与方法。该篇文章目的主要是使读者对Spring Cloud工具系具有一个整体的认识，便于后面微服务思想的讲解。
前言
微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模组化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通讯。 （未完待续），有关框架进化的部分请看：1.1 从传统单体架构到服务化架构 ，1.2 从服务化到微服务 。
微服务简单项目示例
首先要强调的是，在一开始就放一个示例是很不友好的，但我放这个例子的目的是便于读者一开始对于Spring Cloud构建的微服务框架又一个整体的认识，之后带着问题阅读本文效果最佳。当然，我们完全可以忽略该章节，改节并不影响整体的阅读。
功能架构
该示例的功能架构如上，大体上是一个OA系统，即自动化办公的项目。过多不介绍，知道有什么功能就好。
逻辑架构
上述是示例项目的逻辑架构，方便大家了解框架的逻辑结构和采用的相关技术。
物理架构
物理架构稍微透露出微服务的意思。
部署架构
个人认为部署架构是最能体现 Spring Cloud 构架下的微服务框架思想。
Spring Cloud 中常见组件以及功能
| 组件 | 功能 |
|---|---|
| Eureka | 服务注册和发现 |
| Ribbon | 负载均衡 |
| Spring Cloud Config | 服务配置中心 |
| Spring Cloud Bus | 消息总线 |
| Zuul | 路由网关 |
Eureka服务注册和发现
服务治理，将服务之间的直接依赖转化为服务对服务中心的依赖
首先，让我们看一下最简单的Eureka的逻辑图。
下面这是Eureka源码的架构逻辑图。
下面我们用一个通俗的例子解释Eureka的作用。
假如把一个项目比做一个班级的话，那么Eureka同学起到的作用：班级内所有事务的处理都需要找Eureka同学获得详细事务对接人，比如同学A需要知道他的语文成绩是多少，于是他就找Eureka同学。
同学A：Eureka同学，我想看下我的语文成绩。
Eureka：我这边所有的事情对应的对接人都在这个名单里面（紧接着Eureka拿出一份名单交给了同学A）。
同学A查阅了名单，发现负责查询语文成绩的同学是语文课代表，于是同学A就找到了语文课代表获得了他的语文成绩。
Ribbon负载均衡
继续上面的故事。
过了一阵子，仍旧是Eureka同学和同学A，同学A发现他的语文成绩不对，想找语文老师，但不知道语文老师来了没来。
同学A：Eureka同学，我想看看语文老师来了没来。
Eureka：我这边所有的事情对应的对接人都在这个名单里面（紧接着Eureka拿出一份名单交给了同学A）
同学A查阅名单，发现查看语文老师在不在这个事情有两个人可以做分别是语文课代表和学习委员，由于事情比较急。 同学A第一次问了语文课代表，没有来，第二次问了学习委员，没有来，第三次又问了语文课代表，还没来。。。轮询这两个负责人。
Spring Cloud Config服务配置中心
上面的故事其实是有点缺陷的，缺陷在哪里呢？ 我们看负载均衡的这个故事。
同学A在拿到名单后，发现查看语文老师在不在的两个对接人-语文课代表和学习委员，但是语文课代表和学习委员是两个职位，负载均衡的场景默认了同学A知道这两个职位对应的具体的人是谁， 但是，实际情况是，对于新同学这两个职位对应的是谁他们是不知道的，也有可能这两个职位会换人，所以我们就需要Config（服务配置中心）同学，这种情况下，Config同学知道语文课代表是那个同学，学习委员是那个同学，所以同学A一入学上课的时候就通过Config同学获取了这一对应的信息。
Spring Cloud Bus消息总线
上面的故事仍有缺陷，我们来看看消息总线的故事。
同学A在拿到名单后，由于Config同学知道语文课代表是那个同学，学习委员是那个同学，并且同学A一入学上课的时候就通过Config同学获取了这一对应的信息。但是，现实情况下一定会出现这个情况：
突然有一天换了语文课代表，当同学A再次去询问原来的语文课代表却发现原来的语文课代表已经不管这个了，不能给你找语文老师了。那么这种情况下，同学A只能总是去问学习委员语文来是来没来，但学习委员可能一下子忙不过来不能及时回复你。
出现这种状况以该怎么办呢？Spring Cloud给出的方案大致如下：
班级里面有一个叫Bus的同学，当每次Config手里的班级职务和对应的人更换时（这里就是语文课代表换人了），Bus同学就会通知全部的同学说，“班级的班委换人了，你们快去问Config同学啊！”，于是乎，同学A听到了Bus同学的通知后，就去主动问Config同学。
同学A：Config同学，听说咱班的班委换了，都换了谁啊。
Config同学： 我给你一份新班委的名单，你自己查看吧。
Config同学给了同学A班级里面的名单，同学A查看新的名单后知道了新的语文课代表是谁，以后同学A就可以继续轮询着问学习委员和现任的语文课代表语文老师来没来了。
Zuul路由网关
上图一个用Spring Cloud实现的相对完善的最基本构成，其中Zuul组件是项目对外暴露的唯一接口，也可以认为Zuul组件是联系项目内与项目外的媒介。官方的Github：Zuul，官方的解释为：
Zuul is a gateway service that provides dynamic routing, monitoring, resiliency, security, and more.
翻译过来就是Zuul是一种提供动态路由，监控，弹性，安全性等的网关服务。 涉及到路由那么就涉及到系统的业务范围，即系统边界了。既然涉及到了系统边界，那么下面的故事也就不会仅仅局限于一个班级里的故事了。
情境一：路由
在班级A里，班长小Z负责对接所有的班外认识对班级的事务处理，有一天，教务老师联系小Z。
教务老师：小Z，我们现在需要你们班的名单和联系方式。
小Z：好的，老师，请您稍等。
之后，班长小Z找了Eureka同学拿到了班级事务和负责人的对应名单，找到了具体负责班级名单和联系方式的同学，并问他要到了名单以及联系方式，并交给了教务老师。
又是一天，学工部的老师联系小Z。
学工部老师：小Z，麻烦你把你们班办理助学贷款的同学名单给我。
小Z：好的，老师，请您稍等。
之后，班长小Z查阅了从Eureka同学拿到了班级事务和负责人的对应名单，找到了具体负责班级助学贷款事务的同学，并问他要到了助学贷款的同学名单，并交给了学工部老师。
由上可知，班长小Z是接收班级之外所有的事务请求，并且根据请求选择班内相应的同学处理的人。
情景二：网关
由上面的故事可以知道，班长小Z是接受班级外部请求并且决定请求由班级内那个同学处理的角色，然而，班长小Z并不是谁的外部请求都接受的，例如：学工部老师找班长小Z要助学贷款的名单，班长小Z在知道对方身份并且有权限给他的情况下将名单给了他，还有，假如校外一家补习机构的某个员工前来问小Z班级的名单，小Z会坚决的回绝他们。并不给他们做事情，即并不处理他们的请求。这种有条件性的选择是否给某个人的某一请求进行服务的行为，映射到Zuul上就是网关。
文章评论