罗彬桦的博客

配置管理的前世今生随着技术的发展，配置项管理变得越来越简单，尽管如今它只限于管理业务属性或者配置初始化参数等等，但是当年它可肩负着Spring IOC的光荣使命，风光无限。第一次工业革命这一次由Spring引领，在Spring引入自动装配机制以后，情况发生了天翻地覆的变化。基于注解的自动装配取代了繁重的XML配置，使用@Autowired，@Qualifier，@Primary等一系列自动装配注解，把所有关于“依赖注入”的繁重工作从配置项中解放了出来。现在的项目已经很少看到XML配置..

聚沙成塔 - Turbine收集器Turbine其实也是一个服务节点，它正是借助Eureka的服务发现来完成信息聚合的。配置监控服务和集群：在Turbine里我们需要配置目标服务，也就是需要Turbine实时监控的服务名称。如果应用的部署结构比较复杂，比如说分了几个大集群，这时一个Turbine节点可能就无法监管这么多的服务节点了。我们可以启用多个Turbine聚合服务，每个服务指定一个集群，用来聚合这个集群下所有服务节点的Hystrix状态。在默认单cluster的部署结构下，Turbine默

通常我们都采用基于线程池的实现方式，这也是最容易理解的方案。Hystrix还提供了另一种底层实现，那就是信号量隔离。小时候我们就知道“红灯停，绿灯行”，跟着交通信号的指示过马路。信号量也是这么一种放行、禁行的开关作用。它和线程池技术一样，控制了服务可以被同时访问的并发数量，乍一看好像两种技术并没有多大区别，我们接下来比较一下它们在应用场景上的不同之处。线程隔离原理线程池技术：它使用Hystrix自己内建的线程池去执行方法调用，而不是使用Tomcat的容器线程信号量技术：它直接使用..

线程隔离是个什么概念呢？简单的说，就是将用户请求线程和服务执行线程分割开来，同时约定了每个服务最多可用线程数。说也说不明白，我就举个例子吧。假设我们的服务器就是六扇门总部，那每个用户请求都是来访参观的皇亲国戚。首先我们的Web容器有个线程池用来接收请求，我们把这个线程池可以看做是六扇门的大堂，所有来访的用户都要先到大堂接待。接下来，我们六扇门提供了各种各样不同的服务满足这些官老爷们，比如按摩服务，蒸桑拿服务，美容服务。按照老规矩的话，这些服务都是在大堂现场开展，假如大堂只能接待20个人，结果来了这20人

押入天牢 - 熔断开启非也！我们锦衣卫不是来给你们当门卫的，如果一个服务反反复复调用失败，大半辈子都在fallback里呆着，那还放他出去干什么？索性一直在fallback里呆着就好了。且看我们锦衣卫是如何把这些屡教不改的家伙押入天牢。以上流程中省略了服务降级部分的业务，我们只关注熔断部分。发起调用-切面拦截：由于熔断器是建立在服务降级的基础上，因此在前面的触发机制上和服务降级流程一模一样。在向@HystrixCommand注解修饰的方法发起调用时，将会触发由Aspect切面逻.

最大超时时间=（连接超时时间+接口超时时间）*（当前节点重试次数+1）*（换节点重试次数+1）假如经过上述计算，Ribbon的超时时间是2000ms，那么Hystrix的超时时间应该设置成多少才合理呢？我们先来看看Hystrix的默认全局配置：hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=1000以上全局配置设置了Hystrix的熔断时间为1000ms。这里Hystrix的超时时间设置比Rib

沉默是金 - 静默处理所谓的静默处理，就是什么也不干，在fallback逻辑中直接返回一个空值Null。同学们可能会问，那我用try-catch捕捉异常不也是能达到一样的效果吗？其实不然，首先try-catch只能处理异常抛出的情况，并不能做超时判定。其次，使用try-catch就要在代码里包含异常处理块，我们在程序设计时讲究单一职责和开闭原则。正所谓凯撒的归凯撒，上帝的归上帝，既然有了专门的fallback处理类，那这个工作还是交给fallback来吧，这样你的业务代码也落个清爽。瞒天过海

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

LoadBalancerLoadBalancer下面更底层的7种内置的负载均衡策略RandomRule - 随性而为RoundRobinRule - 按部就班RandomRule是随性而为挑选节点，RobinRule却按部就班从一个节点一步一步地向后选取节点，既不会跳过一个，也不会原地踏步，每一次只向后移动一步。同学也许会问了，假如在多线程环境下，两个请求同时访问这个Rule是否会读取到相同节点呢？不会，这靠的是RandomRobinRule底层的自旋锁+CAS的同步操作。.

客户端负载均衡服务端负载均衡模式比较

负载均衡的核心概念雨露均沾 不能让某个人特别累 要累就一起累淘系UMP应用其实就是将压力分散开来

启动心跳健康检查配置客户端心跳和续约间隔服务端自保配置模拟服务剔除场景spring.application.name=eureka-clientserver.port=30002eureka.client.serviceUrl.defaultZone=http://localhost:20000/eureka/#eureka.client.serviceUrl.defaultZone=http://peer2:20000/eureka/,http://peer1:20001/eur

服务自保服务剔除，服务自保，这两套功法一邪一正，俨然就是失传多年的上乘心法的上卷和下卷。但是往往你施展了服务剔除便无法施展服务自保，而施展了服务自保，便无法施展服务剔除。也就是说，注册中心在同一时刻，只能施展一种心法，不可两种同时施展。心法总决服务剔除 把服务节点果断剔除，即使你的续约请求晚了一步也毫不留情，招式凌厉，重在当断则断，忍痛割爱。心法总决简明扼要：欲练此功，必先自宫服务自保 把当前所有节点保留，一个都不能少，绝不放弃任何队友。心法的指导思想是，即便主动删除，也许并不能解决问题，且放之任

服务续约建立在心跳机制之上的保活功能，服务续约。在了解服务续约之前，我们先来理一理心跳、续约和剔除之间的爱恨纠葛。这三弟兄都紧紧围绕在注册中心里的服务同步时间周围，意图霸占。我们先来说说续约和心跳的关系，服务续约分为两步第一步 是将服务节点的状态同步到注册中心，意思是通知注册中心我还可以继续工作，这一步需要借助客户端的心跳功能来主动发送。第二步 当心跳包到达注册中心的时候，那就要看注册中心有没有心动的感觉了，他有一套判别机制，来判定当前的续约心跳是否合理。并根据判断结果修改当前instance在

心跳检测与服务剔除社保中心的忧桑今天社保中心来了一位钉子户，90多岁的王大爷又兴高采烈的来给自己快120岁的老父亲领社保了！工作人员这一想，好像哪里不对啊，这老父亲120岁的年纪都可以上吉尼斯世界纪录了，要不咱帮老爷子去申请一下？王大爷一听可慌了，连连表示使不得使不得，就来领个社保而已。但是本着负责的态度，社保中心还是决定实地走访一下。眼看要穿帮，王大爷只好老实交代，原来王大爷的老父亲早就没了十好几年，坟头草都快长成非洲大草原了，但是在社保中心没有销户，这才造成了这么一个BUG。不光社保中心有这个

创建服务消费者创建eureka-consumer子项目添加pom依赖创建启动类和Controller向eureka-client发起调用pom.xml<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" x

注册服务提供方创建eureka-client子项目添加pom依赖创建启动类和服务内容瞅瞅你在注册中心页面长啥样外部pom.xml<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLo

解读注册中心UI页面长啥样？这满眼洋文哪是哪儿啊？我注册的实例跑哪了？我自己跑了？

注册中心服务注册是为了解决Who are you这个问题，即获取所有服务节点的身份信息和服务名称，从注册中心的角度来说我们有以下两种比较直观的解决方案:三顾茅庐 由注册中心主动访问网络节点中所有机器等待戈多 注册中心坐等服务节点上门注册大家来思考一个问题，为什么目前主流的注册中心都选择第二种方案，而不是第一种呢？那我们先来看看三顾茅庐的方式有哪些弊端模型复杂：网络环境浩如烟海，轮询每个节点的做法通常是注册中心发局域网广播，客户端响应的方式，这种方式就像你对着全世界喊我爱你，顿时感到有种无力感。现实

Eureka2.0停工对技术选型的影响Eureka 2.0漫谈拥抱变化技术选型

服务治理技术选型分布式系统CAP定理一致性强一致性：一次更新终身有效弱一致性：更新过后有一半份，拿不到更新数据最终一致性：经过一段时间后，最后的数据能保持一致我们的C代表的是强一致性可用性我们一般用宕机当作指标要保证99.999%，宕机<5min分区容错性异地机房做容灾，CAP大定理：分布式系统只能三选二，不能全占。服务治理的三大门派服务治理组件比较...

Foodie-SearchFoodie-ItemFoodie-CartFoodie-UserFoodie-OrderFoodie-Auth

Domain外部划分Domain内部划分

Foodie微服务化的构想现有结构拆迁通知项目结构

进击的Spring Cloud（以曾经的F版为例）SpringCloud维护策略升版的利弊权衡为了什么而找借口，不是为新而新推荐方式

三大门派有Spring Cloud的地方就有江湖，我们就来看一看在这个江湖中都有哪些独霸一方的门派！Netflix是先有Spring Cloud还是先有Netflix？这是一个好问题。Netflix是一家大名鼎鼎的互联网传媒公司，但为什么它在开源软件领域有这么大的名声呢？这就不得不说起它和Spring Cloud的渊源了。很久很久以前，天和地还没有分开，宇宙混沌一片。有个叫Netflix的公司，在这混沌之中，拿自身的业务动手，开启了一段微服务的改造之旅。在这段漫长的过程中，沉淀出了一系列优秀的微服务

SpringCloud整体架构解析Spring Cloud整体架构Spring Cloud的中文名我们就暂且称呼它为“春云”吧，听上去是多么朴实无华的名字，不过呢一般名字起的低调的都是厉害角色，我们就看看Spring Cloud都提供了哪些靠谱功能吧。技多不压身我们前面说过，Spring Cloud是一款微服务架构的一站式解决方案，你在微服务化过程中碰到的任何问题，都可以从Spring全家桶里找到现成的解决方案，而且方案还不止一种。我们先来看一幅Spring Cloud的全景图，再来详细解释其中的

服务间调用介绍现有的服务调用方式利用拼接的方式。虽然上面有的用不错就很好了Feign解决了什么问题Feign的调用方式Feign体系架构解析-武装到牙齿上一节我们了解了feign的主要功能，它就像一个自拍杆一样，方便了Eureka的远程调用。可是怎么看都觉得Feign的功能很简单嘛，职责也比较单一，那它和Ribbon一样，都是大闲人了？正所谓麻雀虽小五脏俱全，HTTP调用看着简单，实则下面隐藏的是一套非常复杂的流程。从上古时代jsp+servlet，到后面的SpringMVC，在HT

微服务架构所面临的技术问题前面我们了解了微服务化的拆分原则，以及从架构师角度如何权衡微服务化的利弊。这一小节我们对微服务架构所要考虑的技术难点做一番探讨。微服务架构可不是打嘴炮，它实打实地考验一个公司的综合技术实力，这不仅关乎架构层面的技术选型，团队成员对微服务体系的理解也决定着微服务化在执行层面的深度，而这套架构后面各个组件的线上部署维护也需要强大的运维能力。所以说，在项目中应用微服务架构可谓是蜀道艰险，青天没上成，可能先去了西天。架构师是一个很神奇的职业，为什么这么说呢，因为我工作中遇到的架构

新零售业务商品中心微服务化过程业务背景多元业务方业务需求初代的短命版本老城区改造计划 - 抗压维度老城区改造计划 - 业务维度老城区改造计划 - 指导方针新城区全貌 - 简图

【架构思考】如何权衡微服务的利弊相亲大会吐槽大会合适不合适业务角度

微服务需要学习的几大组件Eureka 服务治理Ribbon 负载均衡Hystrix 服务容错Feign 服务间调用Config 分布式配置中心BUS 消息总线Gateway 服务网关Sleuth 调用链追踪Stream 消息驱动Sentinel 限流

微服务介绍Teenage Sex微服务是什么？杜克大学教授Dan Ariely说过一段非常出名的话，用来表述Big Data的发展现状。我觉得把这句话放到微服务身上也极其贴切。Micro-services is like teenage sex:Everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are