此次要是讲不明白Spring Cloud核心组件，那我就白编这故事了

原创：小姐姐味道（微信公众号ID：xjjdog），欢迎分享，转载请保留出处。

这几天可真是热啊，泡个海澡是再好不过了。玩的正起劲，忽然脚底绊上一股暗流，而后我就一直在水里旋转旋转旋转...终于眼前一黑。
爱的魔力转圈圈。我穿越了。

邻国相望，鸡犬之声相闻，民至老死不相往来。这个世界被小诸侯给切的七零八落，一锅乱麻。

而现实是，个人国家由于常年打仗，剩下的女人不少，须要打通远嫁他方的通道；而A国盛产长得和猪同样大的耗子，卖的很好。它们能够作成皮大氅，用来取暖。因此交流是在所不免的。

现实是这样的：
1、A国不知道B国身处何方，常常有牧民捧着藏宝图同样的破布，葬身在崎岖的山路上。
2、B国听不懂C国含糊不清的吐词，感受他们在求救，等跑近一看，却发现实际上是在骂娘。
3、C国生产的南瓜就知道卖给D国，剩下的都烂在了地里，E国都开始吃树皮了。
4、F国却是远近闻名，但四面八方蜂拥而至的难民，让他们很是苦恼。其中，G国的难民，最是恶劣。
5、曾有其余大陆板块的使者，5年不得要领。见神粥大地现状，做诗一首：《真TM乱》。

做为一个穿越者，一个怜悯众生的剩人。我要留给这个世界一张蓝图，好让后人记住个人名字：xjjdog。同时，我也想起了，我为何有这种这种强大的自信。

”回忆“的片断将我带回到21世纪。

1、我要聊点技术了：单体应用

咱们刚开始的服务，其实并无那么复杂。我只有一台配置很是低的机器，个人应用，个人代码，个人聪明才智，所有在这一个小小的工程里面。因为我是搞it的，因此个人项目名字就叫jisuanji。有人说我用中文拼音作项目名，太那个。我不听，我就是这么命名。我还把公共模块叫gg，密码字段叫mm，谁管得着呢。

对，看下面的图，就是这么简单。项目能活到用nginx来作负载均衡这一步，就算是小成功了。

这个时候，全部的代码就是一个总体，用户访问什么，我直接给就是。

2、我拆成了两个服务

多是我和我同样二的人有点多，个人项目访问量愈来愈大，这也许就叫臭味相投吧。我本身的开发速度，已经追不上头脑里的idea，是时候招我的对服务进行拆分了。

不能拆的太过火，因此刚开始，我把jisuanji拆成了两个服务。其中的服务B，仅仅部署了一个节点，由于它的压力还不是太大。即便这样，我不得不买上3台服务器来部署服务节点，真是肉痛。我这么抠门的人，数据库固然也是共用的。虽然有时候机器压力有点大，但暂时还死不了人。

这个时候我就面临了一个选择问题：服务A要怎么访问服务B呢？
因为我搞过一段时间的webservice，首先就想到了它。但这玩意过重了，我还不如经过Http访问来的舒爽。经过HttpClient，或者OkHttp，个人服务A，如今能够直接模拟Http请求访问服务B了。

当团队里有第二我的，就开始吐槽个人项目了。如下是他罗列的，个人项目的罪状：一、复杂度过高，代码严重耦合；二、技术债务多，拍脑壳需求一箩筐；三、代码不规范，一坨屎；四、技术创新难，一个类几千行...

至于么？从一个服务拆成两个，就这么吐槽我。不过为了之后能拆出成百上千个服务，这口气我暂时忍了，毕竟我这人仍是比较虚心的。

3、乱成一锅粥了

等过去半年一看，好家伙，服务给我拆了了几十个。当个人同伴把系统结构图拿给我看，我直接懵逼了。我挑了9个能看的服务，画了张图。

首先进行了业务拆分。好比支付业务，订单业务，用户中心，商品中心等，都组建了独立的团队。每一个业务又进行了细分，拆分红不一样的服务。

在这之间，进行了下面的改动：
1、有小伙伴写了个通用的HttpClient调用组件，本身的负载均衡策略。
2、有另一个小伙伴，习惯protobuf，因此选了gRPC。
3、事实证实SOA仍是有市场的，这不，就有几个服务的交互引入了webservice。
4、有人想要用RMI，被我及时发现、否决，腹死胎中了。
5、每次建个新服务，都须要更新一下excel，而后将这个excel周知出去。

如今的整个系统，简直是个四不像。什么通讯方式都有，什么交互格式都不缺。拿最要命的D服务来讲，光通信模块，就引入了20几个jar包。若是应用扩展到上千个...My god...

更要命的是，这么多服务，每次上线一个模块都胆战心惊，由于它不知道到底会有什么连锁反应。

是时候叫出超级飞侠了。哦不，叫出微服务了。

4、微服务来袭

目前，最火的微服务框架，就是SpringCloud了。虽然netflix公司对某些组件的维护常常爽约，但有些核心组件仍是很是经典的。

一、注册中心：Eureka

服务A，怎么找到服务B，有不少种方式。好比你生活在一个小镇上，你问xjjdog是谁，老王可能认识他，但小李可能并不知晓；但小李认识老王，因此经过他最终也能找到xjjdog，只不过麻烦一些。

你能够随便拉小镇上的一我的，来问xjjdog是谁。你还会变戏法同样拿出一个小本本，把你认识的人，都告诉他们。当你脑残式的问了一个遍，到最后全部人都知道xjjdog了。

上面说的就是gossip协议。最终，大家都可以知道彼此，由于都是大嘴巴。好比小郑生了个孩子，过不了多少时间，全镇子的人都把这个孩子记录在本子上了。

用这种方式，服务都可以知道彼此，完成通讯。

---

惋惜这并不美好，从小镇的东头跑到西头，须要很长时间。在这个时间里，小郑刚生的孩子可能由于先天疾病夭折了。咱们须要一种信息集中度和实效性更高的方式。

这就须要一个中心，那里的信息就是权威。 在SpringCloud体系中，最经常使用的注册中心就是Eureka。任何服务启动之后，都会把本身注册到Eureka的注册表中；当服务死亡的时候，也会通知Eureka。

这样，当服务A想要找服务B的时候，只须要问一下Eureka Server就能够了，它什么都知道。

为了达到这个目的，仍是要有一部分工做量的。且看下图。这个注册动做，是由一个叫作Eureka Client的组件来完成的。服务启动和关闭的时候，会经过这个组件推销本身；而当服务A想要调用服务B的时候，直接问Eureka Server就能够了。服务A拿到结果后，会把结果缓存在本地的注册表里。

你能够认为是一个拷贝。因此Eureka Server死掉后，并不影响服务A找到服务B。

二、负载均衡组件：Ribbon

如今问题来了。服务A拿到服务B的实例列表之后，发现有两台。

10.0.0.12
10.0.0.16

接下来麻烦了，该调哪台机器呢？这就是SpringCloud中组件Ribbon的做用。其实Round Robin是一个通用的计算机术语。它是最经常使用的负载均衡策略，请求会均匀的分配给后面的每台服务器。

Ribbon工做时，会作下面四件事：
一、优先选择在一个Zone且负载较少的Eureka Server，进行链接。
二、按期从Eureka更新、过滤服务和实例列表。
三、根据负载均衡策略，从注册表中选择一个真正的实例地址。
四、经过RestClient对服务发起调用。

能够看到，Ribbon背后，仍是采用的Http协议进行交互。看如下代码，就能够直接实现对远端服务的调用。

@Bean
@LoadBalanced
RestTemplate restTemplate(){
    return new RestTemplate();
}
...

 @Autowired
RestTemplate restTemplate;
public String test() {
    return restTemplate.getForObject("http://test-service/test", String.class);
}

Ribbon的Filter会查找test-service，并替换成相应的实例地址。

策略
Ribbon不只仅提供了轮询的策略，还有其余的，好比：
一、随机Random
二、根据响应时间加权
三、自定义

拿轮询来讲，最终的选择逻辑就在RoundRobinRule类中。

private int incrementAndGetModulo(int modulo) {
        for (;;) {
            int current = nextServerCyclicCounter.get();
            int next = (current + 1) % modulo;
            if (nextServerCyclicCounter.compareAndSet(current, next))
                return next;
        }
}

三、为简化代码而生：Feign

能够看到，Ribbon须要本身构建http请求，模拟http请求而后使用RestTemplate发送给其余服务，步骤至关繁琐。并且返回类型不安全，也表达不出什么语义。

其实，经过Ribbon方式，已经可以完成微服务之间的调用了。但SpringCloud的开发语言是Java，确定要进行更加高级的封装，才能体现它的逼格。

Feign得益于Java的动态代理机制，最终封装出一套简洁的接口调用方式，将须要调用的其余服务的方法定义成抽象方法便可，不须要本身构建http请求。

首先，Feign会根据@FerignClient注解，经过动态代理，建立一个动态代理类。接下来，你只要经过调用接口的方式，就能够构造上面提到的Ribbon调用参数，这个过程会自动填充。最后，经过构造的Ribbon请求，发起真正的调用，并经过反射组装返回值。

因此，Feign只是一层皮，最终仍是要经过Ribbon进行调用。在我看来，把Ribbon和Feign合成一个组件，也是合理的。

它们有一个比较通用的名词，就叫作RPC（远程调用）。

四、异常的保护伞：断路器

下面以一个支付请求为例，说一下不是风平浪静的状况下，服务会有什么反应。

每个真正的支付请求，都会调用其余四个服务。首先，使用鉴权服务，获取用户的支付权限；而后，风控服务会作一些规则验证；为了更好的推销产品，会调用营销业务，获取一些推荐信息；最后，调用聚合支付服务，进行真正的支付。

其中，营销业务实际上是无关紧要的。让用户首先把钱花出去，是咱们的首要任务。

考虑下面一种场景，营销业务因为系统故障或者负载问题，发生了大面积的不可用或者超时。而后，全部的请求都卡在了获取营销信息的代码上。

如图所示，鉴权和风控都已经经过了。由于一个旁路功能：营销业务，致使真正的支付没法进行。这个时候，若是有人调用支付请求，会发现支付请求也完蛋了。

由于它们最终都卡在了营销这一段小代码上。

因此，对于营销业务这种不是链路上必备的服务提供者，要有一个手段，让它在发生问题的时候，隔离它一段时间。

负责这个功能的组件，就叫作Hystrix。

以咱们编程的思惟来讲，这就是个if条件。

if(服务发生问题){
    return "暂时不要处理";
}

但咱们不能这么编码在业务代码里。因此Hystrix对每一个服务开了一个线程池，并有比较复杂的规则，来控制这些出问题的服务的行为。好比，在2分钟内，直接返回营销业务的默认结果，而不是一直卡在那里。

这个过程，就叫熔断。就像电源同样，出了问题，先切断保险丝，别把电器给烧了。

五、此网关非彼网关：zuul

API网关是一个反向的路由，它屏蔽了内部的细节，为调用者提供了统一的入口。网关，实际上是一堆过滤器的几何，能够实现一系列和业务无关的横切面功能。

熟悉Spring的都知道AOP，路由的一个功能，就是针对于分布式服务的一个AOP。

仍是先说下网关的职责吧。简单罗列几个：
一、安全认证。提供统一的认证方式和鉴权功能，避免重复开发。
二、熔断，限流。针对问题服务，进行熔断操做；对流量进行预估，限制访问。
三、日志监控。统一流量入口，进行流量分析和监控。
四、屏蔽内部细节，对外提供一致的接口。
五、实现灰度。使用自定义策略实现分流，达到测试的目的。

网关的位置，大致就以下图。

能够看到，咱们日常用的nginx，就能够看成网关。但对于微服务来讲，nginx的配置实在是太麻烦了。不是说nginx功能不够强大，而是由于它们不是一个体系的，就存在整合成本（好比kong）。

zuul就不同了，它和SpringCloud的其余组件，是一家子的。一家子的，固然会特殊照顾。Zuul自己就是一个Servlet，外部请求通过一系列Filter后，会达到真正的服务。上面说的熔断器，就是高度集成的。

六、一张聚合图

有了上面关键组件，事情就明了的多了。咱们把它放在一张图中，就是下面的样子。

咱们将其简化一下，就能够获得一张更简洁的图。能够看到，只须要3个关键点：
一、服务注册中心，统一管理全部服务的信息，默认组件是Eureka。
二、RPC，网络通讯组件，服务A怎么调用服务B。在SpringCloud中，就是Ribbon+Feign。
三、网关，拆分的服务怎么暴露接口，最终见人的样子。 默认组件是Zuul。

征途

一点道理

处理杂乱无章的事情，最有效的途径，就是集权和中心化。集权和中心化的核心就是受权或者认同，不然注定失败。受权是对上，各位当权者应该赞成个人作法，因此我须要用及其易懂的语言，去说服他们接受这个体系；认同，是对下，最好是从人民的抱怨声中，出具的改善措施，因此要权威专业。

和微服务同样，须要给一些陈旧的概念，强行赋予看起来比较天然的新意义。好比我把统一语言，叫作文化融合，就显得高大上一些。

第二个，就是把职责拆的足够细。够细才可以精，每一个位置上的人才能各司其职。

还有一点，整个过程，要可以系统化，可以进行推演。若是一件事有着不可预料的后果，那是冒险家干的事情。

一些途径

为了对世界进行初步的了解，我成立了资源统计部，对山川河流进行了初步的勘查，绘制出有章可循的地图。对社会的现状和错综复杂的关系进行了摸底。我把这些信息出版成图书，遭到藏宝图收藏者们的嫉妒和憎恶。他们躲藏在鲜为人知的角落，龌龊行事。

我还选了一个本身以为好听的方言，统一了每一个诸侯国的语言。在推行的过程当中，屡次受到土著们强烈的反对，拒不改正。被我强行斩首了几个以后，之后的推行，就快的多了。

对于全部的重要商品，进行了集中管控。这个世界贵重的不是黄金，而是食物，因此我还修建了四通八达的道路和无孔不入的交易中心。今后以后，不多饿死过人。因为这部分是在个人控制范围内，因此进行的很顺畅。

G国的民风比较彪悍，常常发生暴力事件。这也不免，从刚开始，这个国家就难以驯化。好在缺了他们，这个系统也能循环的下去。前不久G国又发生了重大的事件，全部其余国家联合抵制，禁止G国国民入境。但时间是化解伤痛的良药，我估计这样的限制不会持续好久。

但糟粕仍是有的。有人的地方，就有江湖，就有压迫。但这样的糟粕我是不想让其余人看到的。来访的使者，应该只可以看到歌舞升平、安居乐业，这注定了不能让他们和底层接触，不然就发现金玉其外败絮其中的现状了。

他们和外交官打的不亦乐乎，我很欣慰。

End

我清楚的知道，为了创建一个和谐天然的系统，曾经花费了多大的代价。这其中的组成部分，并不能老是天衣无缝的运行。并且，在这个看似平和的总体上，就滋生了其余无数使人头痛的问题 ，不过这是另一个话题了。

就是这样。我所作的一切，我全部的指望，只不过是为了：当新的机会在我身后，我可以从容的、华丽的转身。

这就是我为了有一天可以穿越，所作的准备。​

做者简介： 小姐姐味道 (xjjdog)，一个不容许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构，日百亿流量，与你探讨高并发世界，给你不同的味道。个人我的微信xjjdog0，欢迎添加好友，​进一步交流。​

近期热门文章​

《必看！java后端，亮剑诛仙》
后端技术索引，中肯火爆

《Linux上，最经常使用的一批命令解析（10年精选）》
CSDN发布首日，1k赞。点赞率1/8。

《此次要是讲不明白Spring Cloud核心组件，那我就白编这故事了》
用故事讲解核心组件，包你满意

《Linux生产环境上，最经常使用的一套“Sed“技巧》
最经常使用系列Sed篇，简单易懂。Vim篇更加易懂。