程序员波特

Actuator 是一个轻巧的监控组件，通过 REST 接口的方式可以供外部调用，访问服务节点下的 “/actuator”路径可以查看当前开放的服务。Actuator 也是一个相当贴心的组件，当你引入的其他组件依赖到 pom 中以后（比如 Config 或 BUS），这部分组件会通过将自己的核心服务提供出去（比如 Config 和 BUS 的 refresh 功能）。假如同学们访问/actuator后只能看到health和info。

随着技术的发展，配置项管理变得越来越简单，尽管如今它只限于管理业务属性或者配置初始化参数等等，但是当年它可肩负着Spring IOC的光荣使命，风光无限。想当年刚入行的时候还是的天下，那时远没有如今这些丰富的开源组件，一个标准的 Java 程序员就是靠 SSH 这三把刷子打天下，正所谓学好数理化，走遍天下都不怕，但那时候的配置管理是一件让人头疼的事情。早先SSH的配置管理可以说是相当复杂，每个项目的 XML 配置文件大大小小几十个。如果有过Struts1的使用经验就能理解这种痛苦，创建一个Form。

作为 SpringCloud 中的执法部门-六扇门，Hystrix 监管着服务的一举一动，不管是超时还是异常抛出，但凡有违法乱纪的现象发生，就会被强制放到 fallback 里进行改造。可是，每个应用都有一长串的服务，那全部都交给 Hystrix 这能管得过来吗？Hystrix 可不是所有服务都监督，毕竟六扇门人力有限，他们只盯梢一些关键人物，给每个关键人物指派一个锦衣卫，但凡有异常发生，立即动手。接下来，我们就来看看六扇门的锦衣卫是如何秉公执法的。

正所谓麻雀虽小五脏俱全，HTTP 调用看着简单，实则下面隐藏的是一套非常复杂的流程。从上古时代 jsp+servlet，到后面的 SpringMVC，在 HTTP 请求解析和封装上同样是煞费苦心。我们在学习中经常会碰到这种 case，有些开源组件不显山来不露水，乍一看功能很简单，配置起来也不麻烦，让人感觉实现起来也不难。实际上我们所看到的只是冰山上的一角，在冰山下面隐藏的巨大基座才是这套技术的全貌。就像 Feign 一样，往往以一个注解开场的项目，背后的故事都不简单。

前面已经介绍了服务治理相关组件，接下来趁热打铁，快速通关 Ribbon！前面我们了解了负载均衡的含义，以及客户端和服务端负载均衡模型，接下来我们就来看下SpringCloud 下的客户端负载均衡组件 Ribbon 的特点以及工作模型。

前面讲了一堆续约，剔除和自保，都是由注册中心在控制，在Eureka的价值观中，难道服务节点的生死就如同浮萍一样，只能被动接受注册中心安排的命运吗?不!服务节点还可以选择一条自己的路，做一回命运的主人，只不过这条路是一条“不归路”-服务下线

这样就避免了被服务剔除给错杀。在实际应用里，并不是所有无心跳的服务都不可用，也许因为短暂的网络抖动等原因，导致服务节点与注册中心之间续约不上，但服务节点之间的调用还是属于可用状态，这时如果强行剔除服务节点，可能会造成大范围的业务停滞。这就是服务自保开启后的警告，意思是说，挂掉的服务有可能会被错误的当做UP，(在一定时间内)续约成功的节点个数占已注册总服务的比值，已经低于限定值，因此所有节点都不会过期，服务自保开启。把服务节点果断剔除，即使你的续约请求晚了一步也毫不留情，招式凌厉，重在当断则断，忍痛割爱。

服务剔除并不会和心跳以及续约直接打交道，而是通过查验服务节点在注册中心记录的同步时间，来决定是否剔除这个节点

本节带大家学习关于心跳检测和服务剔除的知识

在Eureka的圈子混，做什么都要仰仗着注册中心，前面我们说到注册中心的一大作用就是收集所有节点的注册信息，那么大家思考一个问题，注册中心收集这么多服务节点的信息做什么用呢?难道三天两头主动去找人家麻烦?NoNoNo，服务发现的故事还要从一部电影说起

在互联网公司做业务团队，老板只会关注你是不是能及时满足业务发展的要求，何曾见到业务团队把架构设计当做一项KPI?正所谓大家只关心你飞的高不高，而不关心你飞的累不累。

是先有SpringCloud还是先有Netflix？这是一个好问题。Netflix是一家大名鼎鼎的互联网传媒公司，但为什么它在开源软件领域有这么大的名声呢?这就不得不说起它和SpringCloud的渊源了。

在Java悠久的历史长河中(其实也就十来年)，有一个框架自诞生之初就成了Java企业级开发领域的弄潮儿，它以开放的姿态不断引领着技术改革(我们管他叫Java领域的“改革开放”)，它就是久经考验的企业级开发框架，改革开放的总设计师SpringFramework。

与服务治理搭档的还有负载均衡，面对茫茫多的服务器，如何将海量用户请求分发到不同的机器。考虑到有的机器性能比较弱，或者机房带宽不大，网络响应慢，如何根据实际情况动态地分发服务请求?这个领域就是负载均衡需要解决的事情。

相比Ribbon负载均衡策略里的十八般兵器，Dubbo就显得低调的多了，它只提供了负载均衡四件套，让我们先来简单了解一下:

同学们以为Dubbo只有一个RPC协议吗?非也，既然是阿里巴巴出品的开源项目，那自然秉承了“包罗万象”的一贯传统。Dubbo的底层有支持多达9种通信协议，并且他们都有各自的适用场景。我们快速的一扫而过:

Dubbo是一个精耕服务治理领域的框架，秉承了阿里一贯的大而全风格，和Eureka相比复杂度有不小的提高，这一节我们选了Registry和Remoting两个核心模块，从功能层面做个简单的了解

Dubbo是一款轻量级+高性能的RPC框架，所谓天下武学殊途同归，Dubbo的很多理念和Spring Cloud中的组件都差不多。我们就来看一下Dubbo的几个核心特性，顺带和SpringCloud中的组件关联对比一下

Spring Cloud是一款微服务架构的一站式解决方案，你在微服务化过程中碰到的任何问题，都可以从Spring全家桶里找到现成的解决方案，而且方案还不止一种。我们先来看一幅Spring Cloud的全景图，再来详细解释其中的每个组件的功能。

前面我们了解了什么是微服务和为什么需要做微服务架构(What & Why)，这一节我们就来探讨如何做微服务架构的拆分(How)

随着互联网行业的飞速发展，个人的衣食住行几乎全依赖各种APP来满足。每天早上起来刷刷淘宝，地铁，上用视频app看个短句，一天微信不离手，睡前刷个抖音一不小心就刷到了后半夜.......

微服务是什么?杜克大学教授DanAriely说过一段非常出名的话，用来表述Big Data的发展现状。我觉得把这句话放到微服务身上也极其贴切。