eureka

文章首发于公众号《程序员果果》 地址 : https://mp.weixin.qq.com/s/FfJrAGQuHyVrsedtbr0Ihw 简介 上一篇文章 《Eureka 源码分析之 Eureka Client》 通过源码知道 ，eureka Client 是通过 http rest来 与 eureka server 交互，实现 注册服务，续约服务，服务下线 等。本篇探究下eureka server。 源码分析 从 @EnableEurekaServer 注解为入口分析，通过源码可以看出他是一个标记注解： /** * Annotation to activate Eureka Server related configuration {@link */ @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented @Import(EurekaServerMarkerConfiguration.class) public @interface EnableEurekaServer { } 从注释可以知道，用来激活 eureka server 的 配置类 EurekaServerAutoConfiguration 中相关配置，EurekaServerAutoConfiguration

文章首发于公众号《程序员果果》 地址 : https://mp.weixin.qq.com/s/FfJrAGQuHyVrsedtbr0Ihw 简介 上一篇文章 《Eureka 源码分析之 Eureka Client》 通过源码知道 ，eureka Client 是通过 http rest来 与 eureka server 交互，实现 注册服务，续约服务，服务下线 等。本篇探究下eureka server。 源码分析 从 @EnableEurekaServer 注解为入口分析，通过源码可以看出他是一个标记注解： /** * Annotation to activate Eureka Server related configuration {@link */ @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented @Import(EurekaServerMarkerConfiguration.class) public @interface EnableEurekaServer { } 从注释可以知道，用来激活 eureka server 的 配置类 EurekaServerAutoConfiguration 中相关配置，EurekaServerAutoConfiguration

简介 Eureka是一种基于REST（Representational State Transfer）的服务，主要用于AWS云，用于定位服务，以实现中间层服务器的负载平衡和故障转移。我们将此服务称为Eureka Server。Eureka还附带了一个基于Java的客户端组件Eureka Client，它使与服务的交互变得更加容易。客户端还有一个内置的负载均衡器，可以进行基本的循环负载均衡。在Netflix，一个更复杂的负载均衡器包含Eureka基于流量，资源使用，错误条件等多种因素提供加权负载平衡，以提供卓越的弹性。 先看一张 github 上 Netflix Eureka 的一架构图，如下： 从图可以看出在这个体系中，有2个角色，即Eureka Server和Eureka Client。而Eureka Client又分为Applicaton Service和Application Client，即服务提供者何服务消费者。 每个区域有一个Eureka集群，并且每个区域至少有一个eureka服务器可以处理区域故障，以防服务器瘫痪。 Eureka Client 在 Eureka Server 注册，然后 Eureka Client 每30秒向 Eureka Server 发送一次心跳来更新一次租约。如果 Eureka Client 无法续订租约几次，则会在大约90秒内 Eureka

一、spring cloud简介 鉴于《史上最简单的Spring Cloud教程》很受读者欢迎，再次我特意升级了一下版本，目前支持的版本为Spring Boot版本2.0.3.RELEASE,Spring Cloud版本为Finchley.RELEASE。 Finchley版本的官方文档如下： http://cloud.spring.io/spring-cloud-static/Finchley.RELEASE/single/spring-cloud.html spring cloud 为开发人员提供了快速构建分布式系统的一些工具，包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等。它运行环境简单，可以在开发人员的电脑上跑。另外说明spring cloud是基于springboot的，所以需要开发中对springboot有一定的了解，如果不了解的话可以看这篇文章： 2小时学会springboot 。另外对于“微服务架构” 不了解的话，可以通过搜索引擎搜索“微服务架构”了解下。 二、创建服务注册中心 在这里，我还是采用Eureka作为服务注册与发现的组件，至于Consul 之后会出文章详细介绍。 2.1 首先创建一个maven主工程。 首先创建一个主Maven工程，在其pom文件引入依赖，spring Boot版本为2.0.3.RELEASE

现如今微服务架构十分流行，而采用微服务构建系统也会带来更清晰的业务划分和可扩展性。同时，支持微服务的技术栈也是多种多样的，本系列文章主要介绍这些技术中的翘楚——Spring Cloud。这是序篇，主要讲述我们为什么选择Spring Cloud和它的技术概览。 1、为什么微服务架构需要Spring Cloud 简单来说，服务化的核心就是将传统的一站式应用根据业务拆分成一个一个的服务，而微服务在这个基础上要更彻底地去耦合（不再共享DB、KV，去掉重量级ESB），并且强调DevOps和快速演化。这就要求我们必须采用与一站式时代、泛SOA时代不同的技术栈，而Spring Cloud就是其中的佼佼者。 DevOps是英文Development和Operations的合体，他要求开发、测试、运维进行一体化的合作，进行更小、更频繁、更自动化的应用发布，以及围绕应用架构来构建基础设施的架构。这就要求应用充分的内聚，也方便运维和管理。这个理念与微服务理念不谋而合。 接下来我们从服务化架构演进的角度来看看为什么Spring Cloud更适应微服务架构。点击 这里 查看Spring系列教程集合。 1.1 从使用nginx说起 最初的服务化解决方案是给提供相同服务提供一个统一的域名，然后服务调用者向这个域名发送HTTP请求，由Nginx负责请求的分发和跳转。 这种架构存在很多问题： Nginx作为中间层

　　前面我们介绍了SpringCloud注册中心Eureka，但是存在一个单点故障的问题，一个注册中心远远不能满足实际的生产环境，现在我们介绍一下如何搭建一个Eureka集群。 一：集群环境搭建 　　我们先建两个注册中心工程，一个叫eureka_register_master，一个叫eureka_register_salve。master的端口是7998，salve的端口是7999。 　　eureka_register_master的配置文件application.properties如下： server.port= 7998 eureka.client.register -with-eureka= false eureka.client.fetch -registry= false spring.application.name =eureka- server eureka.instance.hostname = master eureka.client.service -url.defaultZone=http: // salve:7999/eureka 　　eureka_register_salve的配置文件application.properties如下： server.port= 7998 eureka.client.register -with-eureka=

配置中心用于统⼀管理配置， 快速切换各个环境的配置。 常用的配置中心 百度开源的disconf https://github.com/knightliao/disconf 阿⾥开源的diamand https://github.com/takeseem/diamond springcloud开源的Config http://cloud.spring.io/spring-cloud-config/ zookeeper Config是一个分布式的配置管理中心，由config server、config client2部分组成，每个要从config server是获取配置的服务节点都是config client。 使用git仓库存储配置 config默认使⽤git仓库来存储配置，可以使用公司自己搭建的git服务器，也可以使⽤github、码云上的私人仓库。 不推荐使用github上的仓库来存储配置，因为在国内使用github访问速度很慢，个人开发者建议使用码云。 新建私人仓库，名称比如config-mall，不同环境的配置有2种方式 （1）文件名指定 配置文件都放在master分支下，比如用户服务的配置：user-service-dev.yml user-service-test user-service-prod.yml dev是开发环境，test是测试环境，prod是生产环境 （2

把 14 亿中国人民都拉到一个微信群里在技术上能实现吗？ 先说结论：也许可以实现，但你会什么都看不见。 根据 2017 年《微信数据报告》的公开数据 [参考 1] ： 2017 年 9 月，微信日均登陆 9.02 亿人，日均发送消息 380 亿次。 这意味着平均每人每天发送信息 42 条，如果全国人民（对了，现在全国人口已经接近 14 亿）在同一个群里说话，这个群每天出现的信息就高达： 这么多信息仅仅是匀速发送的话，考虑到大家的睡眠，睡觉的 8 小时不算，那么手机里每秒要接收的信息就是： 哇塞，每秒超过 100 万条啊！目前主频最高的手机 CPU 之一，高通骁龙 845有 2.8GHz 的处理能力[参考 2] ，一共是 8 核。 如不计算安卓系统、显示刷新、网络 IO 等 CPU 操作的话，每条信息能分配到的计算能力是： 这是什么概念？全球第一款微处理器是 1971 年英特尔推出的 Intel 4004[参考 3]，这个老古董的主频也有 108KHz 啊。所以 21.9KHz 就是啥也干不了。 幸好 IT 界有个摩尔定律： 每 18 个月 CPU 性能就能翻倍（或者价钱是一半）。虽然现有科技已经很难让主频提升（某牙膏厂拼命挤也只有 5 Ghz）。 但假设我们使用了黑科技提升主频。等到了 2025 摩尔定律失效时[参考 4]，我们的手机 CPU 主频应该达到： 看起来不错嘛

前面已经学习了两个Spring Cloud 组件： Eureka：实现服务注册功能； Ribbon：提供基于RestTemplate的HTTP客户端并且支持服务负载均衡功能。 通过这两个组件我们暂时可以完成服务注册和可配置负载均衡的服务调用。今天我们要学习的是Feign，那么Feign解决了什么问题呢？ 相对于Eureka，Ribbon来说，Feign的地位好像不是那么重要，Feign是一个声明式的REST客户端，它的目的就是让REST调用更加简单。通过提供HTTP请求模板，让Ribbon请求的书写更加简单和便捷。另外，在Feign中整合了Ribbon，从而不需要显式的声明Ribbon的jar包。 前面在使用Ribbon+RestTemplate时，利用RestTemplate对http请求的封装处理，形成了一套模版化的调用方法。但是在实际开发中，由于对服务依赖的调用可能不止一处，往往一个接口会被多处调用，所以通常都会针对每个微服务自行封装一些客户端类来包装这些依赖服务的调用。所以，Feign在此基础上做了进一步封装，由他来帮助我们定义和实现依赖服务接口的定义。在Feign的实现下，我们只需创建一个接口并使用注解的方式来配置它(以前是Dao接口上面标注Mapper注解,现在是一个微服务接口上面标注一个Feign注解即可)，即可完成对服务提供方的接口绑定，简化了使用Spring

SpringCloud 学习总结（一） SpringCloud 学习总结（二） 服务容错保护Hystrix Hystix是Netflix开源的一个延迟和容错库，其中提供了基础的熔断功能，用于隔离访问远程服务、第三方库，防止出现级联失败。关于Hystrix更详细的原理，可以参考官方文档： https://github.com/Netflix/Hystrix/ 雪崩问题： 在微服务框架中，系统间都通过微服务进行调用，在微服务之间会存在这相互依赖关系。假设每个微服务运行在不同的进程中，依赖的调用只则需要使用远程调用方式。如果其中一个网络出现问题，或者延迟，此时，调用方式在不断的调用，后方的依赖会出现故障。当响应过多时，就可能出现雪崩效应，造成系统的崩溃。 下图中，我们可以看到微服务中，服务间复杂的调用关系，一个请求，可能需要调用多个微服务接口才能实现，会形成非常复杂的调用链路： 如图，一次业务请求，需要调用A、P、H、I四个服务，这四个服务又可能调用其它服务。如果此时，某个服务出现异常： 例如：微服务I发生异常，请求阻塞，用户不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞： 服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，形成雪崩效应。 Hystix解决雪崩问题： 线程隔离(服务降级)