Spring Cloud Netflix

1.x版本 /** * @author Spencer Gibb */ @Configuration @Import({ PropertyPlaceholderAutoConfiguration.class, ArchaiusAutoConfiguration.class, UtilAutoConfiguration.class, RibbonAutoConfiguration.class }) @RibbonClients(defaultConfiguration = DefaultRibbonConfig.class) public class RibbonClientDefaultConfigurationTestsConfig { public static class BazServiceList extends ConfigurationBasedServerList { public BazServiceList(IClientConfig config) { super.initWithNiwsConfig(config); } } } @Configuration class DefaultRibbonConfig { @Bean public IRule ribbonRule() { return new BestAvailableRule(); } @Bean

1. 什么是微服务？ “微服务”一词来自国外的一篇博文，网站： https://martinfowler.com/articles/microservices.html 如果您不能看懂英文文档，可以跳转到搜简体中文的文档 这是国人翻译的文档，可以学习参考： 引用官方文档解释： 简单来说，微服务架构风格[1]是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。 2. 什么是Spring Cloud？ Spring Cloud是一个分布式的整体解决方案的框架。基于Spring Boot开发。Spring Cloud 为开发者提供了在分布式系统（配置管理，服务发现，负载，网关，消息总线，集群管理，安全管理，分布式锁，分布式事务等等）中快速构建的工具，使用Spring Cloud的开发者可以快速的启动服务或构建应用、同时能够快速和云平台资源进行对接。 3. 什么是Spring Cloud Eureka? Spring Cloud Eureka 是 Spring Cloud Netflix 微服务套件的一部分，基于 Netflix Eureka 做了二次封装

作者：林必昭 描述：该文章详细列举的服务技术栈的抓哟技术都有哪些，分别时用来做什么的 微服务开发技术栈 微服务“两大门派” 阿里系 Apache Dubbo Nacos Sentinel RocketMQ Spring Cloud Netflix Eureka Netflix Ribbon Netflix Hystrix Netflix Zuul Spring Cloud Config Spring Cloud Alibaba Spring Cloud Alibaba为分布式应用程序开发提供了一站式解决方案。它包含开发分布式应用程序所需的所有组件，使您可以轻松使用Spring Cloud开发应用程序。 使用Spring Cloud Alibaba，您只需添加一些注释和少量配置即可将Spring Cloud应用程序连接到Alibaba的分布式解决方案，并使用Alibaba中间件构建分布式应用程序系统。 官网 Github 特征： 流控制和服务降级 ：默认情况下，支持HTTP服务的流控制。您还可以使用注释来自定义流控制和服务降级规则。规则可以动态更改。 服务注册和发现 ：可以注册服务，并且客户可以使用Spring托管的bean（自动集成功能区）发现实例。 分布式配置 ：支持分布式系统中的外部配置，配置更改时自动刷新。 事件驱动 ：支持构建与共享消息系统连接的高度可扩展的事件驱动微服务。

Eureka结合网关实现多集群分片 问题描述 解决思路 具体实现 逻辑图 实现步骤说明 Eureka Client源码调整 注册网关添加路由配置 注册网关定时获取注册列表 注册网关返回所有集群注册列表 Eureka Client客户端处理注册列表 问题描述 目前EurekaClient客户端只能往一个EurekaServer集群进行注册发现。而一个EurekaServer集群受制于硬件配置的高低，所能承受的最大服务注册实例数一般在4000至8000个不等。当一群服务的实例数超过了一个EurekaServer集群所能承受的最大实例数时，EurekaServer集群就不能正常运行，会导致大量请求超时，影响所有服务的注册和发现。 解决思路 为了解决这个问题，可以引入一个注册网关，将这一群服务按照某种规则分别注册到不同的EurekaServer集群中，再由注册网关通过调用Eureka API获取所有集群中的注册列表，将这些注册列表全部返回给EurekaClient客户端，这样每一个客户端都能拿到所有EurekaServer集群里的服务实例的注册列表。 具体实现 逻辑图 实现步骤说明 1、 通过修改Eureka Client源码，在请求的注册中心URL里添加项目名； 2、 注册网关通过识别请求中的项目名，将注册的请求转发到对应的集群中； 3、 注册网关通过定时任务每3秒调用Eureka

Eureka注册中心/服务发现框架 Eureka是Netflix开发的服务发现框架，本身是一个基于REST的服务，主要用于定位运行在AWS域中的中间层服务，以达到负载均衡和中间层服务故障转移的目的。SpringCloud将它集成在其子项目spring-cloud-netflix中，以实现SpringCloud的服务发现功能。 Eureka包含两个组件：Eureka Server和Eureka Client。 Eureka Server提供服务注册服务，各个节点启动后，会在Eureka Server中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。 Eureka Client是一个java客户端，用于简化与Eureka Server的交互，客户端同时也就是一个内置的、使用轮询(round-robin)负载算法的负载均衡器。 在应用启动后，将会向Eureka Server发送心跳,默认周期为30秒，如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除(默认90秒)。 Eureka Server之间通过复制的方式完成数据的同步，Eureka还提供了客户端缓存机制，即使所有的Eureka Server都挂掉

现如今微服务架构十分流行，而采用微服务构建系统也会带来更清晰的业务划分和可扩展性。同时，支持微服务的技术栈也是多种多样的，本系列文章主要介绍这些技术中的翘楚——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作为中间层

1. 背景 通过 Spring Cloud 和微服务 的学习，我们了解到使用Spring Cloud实现微服务的架构基本成型，大致是这样的： 我们使用Spring Cloud Netflix中的Eureka实现了 服务注册中心 以及服务注册与发现；而服务间通过 Ribbon 或Feign实现服务的消费以及均衡负载。为了使得服务集群更为健壮，使用 Hystrix 的熔断机制来避免在微服务架构中个别服务出现异常时引起的故障蔓延。 在该架构中，服务集群包含：内部服务Service A 和 Service B，他们都会注册与订阅服务至Eureka Server，而Open Service是一个对外的服务，通过均衡负载公开至服务调用方。我们把焦点聚集在对外服务这块，直接暴露我们的服务地址，这样的实现是否合理，或者是否有更好的实现方式呢？ 先来说说这样的架构需要做的一些事儿以及存在的不足： • 破坏了服务无状态特点。 为了保证对外服务的安全性，我们需要实现对服务访问的权限控制，而开放服务的权限控制机制将会贯穿并污染整个开放服务的业务逻辑，这会带来的最直接问题是，破坏了服务集群中REST API无状态的特点。 从具体开发和测试的角度来说，在工作中除了要考虑实际的业务逻辑之外，还需要额外考虑对接口访问的控制处理。 • 无法直接复用既有接口。 当我们需要对一个即有的集群内访问接口，实现外部服务访问时

1. feign自定义Configuration和root 容器有效隔离。 用@Configuration注解 不能在主@ComponentScan (or @SpringBootApplication)范围内，从其包名上分离 注意避免包扫描重叠，最好的方法是明确的指定包名 2. Spring Cloud Netflix 提供了默认的Bean类型: Decoder feignDecoder: ResponseEntityDecoder (which wraps a SpringDecoder) Encoder feignEncoder: SpringEncoder Logger feignLogger: Slf4jLogger Contract feignContract: SpringMvcContract Feign.Builder feignBuilder: HystrixFeign.Builder 3. Spring Cloud Netflix没有提供默认值，但仍然可以在feign上下文配置中创建： Logger.Level Retryer ErrorDecoder Request.Options Collection 4. 自定义feign的消息编码解码器： 不要在如下代码中getObject方法内new 对象，外部会频繁调用getObject方法。 1 2 3 4 5

秉承站在巨人的肩膀上，同时我也不想重复制造轮子，我发现了一系列关于“分布式架构”方面，我需要，同时能够解决我的一些疑惑、问题的博客，转载过来，原文链接： http://blog.csdn.net/kobejayandy/article/details/52078275 http://blog.didispace.com/springcloud1/ http://www.jianshu.com/u/6a622d516e32 正文： 最近一段时间不论互联网还是传统行业，凡是涉及信息技术范畴的圈子几乎都在讨论 微服务架构 。近期也看到各大技术社区开始组织一些沙龙和论坛来分享Spring Cloud的相关实施经验，这对于最近正在整理Spring Cloud相关套件内容与实例应用的我而言，还是有不少激励的。 目前，Spring Cloud在国内的知名度并不高，在前阵子的求职过程中，与一些互联网公司的架构师、技术VP或者CTO在交流时，有些甚至还不知道该项目的存在。可能这也与国内阿里巴巴开源服务治理框架Dubbo有一定的关系，除了Dubbo本身较为完善的中文文档之外，不少科技公司的架构师均出自阿里系，所以就目前情况看，短期国内还是Dubbo的天下。 那么第一次实施微服务架构时，我们应该选择哪个基础框架更好呢？ 以下内容均为作者个人观点，知识面有限，如有不对，纯属正常，不喜勿喷。 Round 1

Caused by: java.lang.IllegalStateException: PathVariable annotation was empty on param 1 . at feign.Util.checkState(Util.java: 128) ~[feign-core-9.5.0 .jar:na] at org.springframework.cloud.netflix.feign.annotation.PathVariableParameterProcessor.processArgument(PathVariableParameterProcessor.java: 51) ~[spring-cloud-netflix-core-1.4.4.RELEASE.jar:1.4.4 .RELEASE] at org.springframework.cloud.netflix.feign.support.SpringMvcContract.processAnnotationsOnParameter(SpringMvcContract.java: 238) ~[spring-cloud-netflix-core-1.4.4.RELEASE.jar:1.4.4 .RELEASE] at feign.Contract$BaseContract