eureka

在使用eureka注册中心集群的时候 eureka.client.register-with-eureka=true eureka.client.fetch-registry=true 这两个参数一定要设置为true,否者集群服务不可用 集群后台显示非活动状态， 如果是单机模式下可以设为false 来源： oschina 链接： https://my.oschina.net/u/4364052/blog/3421088

<div data-v-e73bee8c="" class="article-typo article-content"><div><p>前几天拜读了 OpsGenie 公司（一家致力于 Dev & Ops 的公司）的资深工程师 Turgay Çelik 博士写的一篇文章（链接在文末），文中介绍了他们最初也是采用 Nginx 作为单体应用的网关，后来接触到微服务架构后开始逐渐采用了其他组件。</p> <p>我对于所做的工作或者感兴趣的技术，喜欢刨根问底，所以当读一篇文章时发现没有看到我想要看到的设计思想，我就会四处搜集资料，此外这篇文章涉及了我正在捣鼓的 Spring Cloud，所以我就决定写一篇文章，争取能从设计思路上解释为什么会有这样的性能差异。</p> <h2>技术介绍</h2> <p>文中针对 Nginx、ZUUL、Spring Cloud、Linkerd 等技术进行了对比（其实还有 <wdautohl-customtag style="font-weight:bold;color:red;font-size:inherit;display:inline;" id="wdautohl_id_1" class="wdautohl_ZW52b3k_">Envoy</wdautohl-customtag> 和 <wdautohl-customtag style="font

1.场景描述 因要用到微服务，关于注册中心这块，与同事在技术原型上做了讨论，初步定的方案是使用：阿里巴巴的nacos+springcloud gateway，下面表格是同事整理的注册中心对比，以前用的springcloud的eureka作为注册中心（ springcloud-高可用部署 ），与eurka相比，这次之所以用阿里的nacos，其中还有一个主要的原因就是nacos集成了动态加载，不用重启网关，动态加载服务配置等。 注册中心对比： Feature Zookeeper Eureka Consul Etcd Nacos 服务健康检查 (弱)长连接，keepalive 可配支持 服务状态，内存，硬盘等 连接心跳 心跳/自定义 多数据中心 — — 支持 — 支持 kv存储服务 支持 — 支持 支持 支持 一致性 paxos — raft raft raft CAP定理 CA AP CA CP AP 使用接口(多语言能力) 客户端 http（sidecar） 支持http和dns http/grpc dns/http/rpc watch支持 支持 支持 long polling/大部分增量 全量/支持long polling 支持 long polling 全量/支持long polling 自身监控 — metrics metrics metrics metrics 安全 acl

前言 使用 API 网关作为内部服务面向客户端的单一入口，是一种普遍采用的架构模式。企业组织通过良好定义的 API 将内部系统向内部和外部用户公开，通常都会采用 API 网关来处理横向的关注点，包括访问控制、速率限制、负载均衡等等，来实现安全可控的 API 开放。而被广泛实践的微服务架构在提供高度灵活性和弹性的同时，也给 API 网关带来了更多的挑战。 阿里云云服务总线（Cloud Service Bus）新推出微服务网关服务（CSB Micro Gateway），针对微服务架构下 API 开放的特点，提供能与微服务环境的治理策略无缝衔接的网关服务，实现高效的微服务 API 开放。 API 网关的作用 API 网关典型作用 相信许多人都熟悉 API 网关的概念。作为内部服务面向客户端的单一入口，API 网关有两个最典型的作用： 1、内外解耦：对客户端屏蔽内部服务的动态多样化实现细节，如技术框架、拆分粒度、接口结构、实例状态等 2、切面控制：让内部服务能专注在业务逻辑上，集中处理横向的关注点，如路由、安全、限流、日志、监控等 API 网关使用类型 实际使用中，对应 API 网关所在位置和针对场景的不同，可分成两种类型： 1、企业级网关：位于企业组织的外围，面对外部的 API 消费者或服务提供者。通常将企业自身的数据和能力 API 化，对外开放，也有允许外部服务入驻的情况。总的来说

前言 现在微服务实在是太火了，所以我们必不可少的是要学习一下SpringCloud了，服务化的核心就是将传统的一站式应用 根据业务拆分成一个一个的服务，而微服务在这个基础上要更彻底地去耦合（不再共享DB、KV，去掉重量级ESB），并 且强调DevOps和快速演化。 springcloud中常用的组件： 服务发现——Netflix Eureka 客户端负载均衡——Netflix Ribbon 断路器——Netflix Hystrix 服务网关——Netflix Zuul 分布式配置——Spring Cloud Config 一、SpringCloud的架构设计 1.1 SpringCloud架构图细解 上面的SpirngCloud的架构图，分层概述一下。 web服务器的选型，这个我选择的是nginx+keepalived，haproxy也是一个选择，但是haproxy在反向代理处理跨域 访问的时候问题很多。所以我们nginx有些地方做了keep-alive模式处理，减少了三次握手的次数，提高了连接效率。 keepalived做nginx的负载，虚拟一个vip对外，两个nginx做高可用，nginx本身反向代理zuul集群。 api gateway，这里的zuul很多人诟病，说是速度慢推荐直接用nginx，这里我还是推荐使用zuul的，毕竟zuul含有 拦截器和反向代理，在权限管理

前言 上篇文章已经介绍了 为何要读netflix eureka源码了，这里就不再概述，下面开始正式源码解读的内容。 如若转载 请标明来源： 一枝花算不算浪漫 代码总览 还记得上文中，我们通过web.xml找到了eureka server入口的类 EurekaBootStrap ，这里我们就先来简单地看下： /** * The class that kick starts the eureka server. 负责启动Eureka server的类 * * <p> * 这里要注意两个关键点： * eureka server对应的配置类为：EurekaServerConfig * eureka client对应的配置类为：EurekaInstanceConfig * * The eureka server is configured by using the configuration * {@link EurekaServerConfig} specified by <em>eureka.server.props</em> in the * classpath. The eureka client component is also initialized by using the * configuration {@link EurekaInstanceConfig}

前言 上一讲已经讲解了EurekaClient的启动流程，到了这里已经有6篇Eureka源码分析的文章了，看了下之前的文章，感觉代码成分太多，会影响阅读，后面会只截取主要的代码，加上注释讲解。 这一讲看的是EurekaClient注册的流程，当然也是一块核心，标题为什么会写上眼花缭乱呢？关于EurekaClient注册的代码，真的不是这么容易被发现的。 如若转载 请标明来源： 一枝花算不算浪漫 源码分析 如果是看过前面文章的同学，肯定会知道，Eureka Client启动流程最后是初始化DiscoveryClient这个类，那么我们就直接从这个类开始分析，后面代码都只截取重要代码，具体大家可以自行参照源码。 DiscoveryClient.java @Inject DiscoveryClient(ApplicationInfoManager applicationInfoManager, EurekaClientConfig config, AbstractDiscoveryClientOptionalArgs args, Provider<BackupRegistry> backupRegistryProvider) { // 省略部分代码... this.applicationInfoManager = applicationInfoManager; // 创建一个配置实例

前言 上一讲eureka client是如何注册的，一直跟到源码发送http请求为止，当时看eureka client注册时如此费尽，光是找一个regiter的地方就找了半天，那么client端发送了http请求给server端，server端是如何处理的呢？ 带着这么一个疑问 就开始今天源码的解读了。 如若转载 请标明来源： 一枝花算不算浪漫 源码解读 从何读起？ 上一讲我们知道，跟进client注册 一直到 AbstractJersey2EurekaHttpClient.register 方法，这里先看下其中的源码： public EurekaHttpResponse<Void> register(InstanceInfo info) { String urlPath = "apps/" + info.getAppName(); Response response = null; try { // 发送请求，类似于：http://localhost:8080/v2/apps/ServiceA // 发送的是post请求，服务实例的对象被打成了一个json发送，包括自己的主机、ip、端口号 // eureka server 就知道了这个ServiceA这个服务，有一个服务实例，比如是在192.168.31.109、host-01、8761端口 Builder

前言 想说的话 【一起学源码-微服务-Ribbon】专栏到这里就已经全部结束了，共更新四篇文章。 Ribbon比较小巧，这里是直接 读的spring cloud 内嵌封装的版本，里面的各种configuration确实有点绕，不过看看第三讲Ribbon初始化的过程总结图就会清晰很多。 紧接着会继续整理学习Feign源码相关的，敬请期待。 说明 原创不易，如若转载 请标明来源！ 博客地址： 一枝花算不算浪漫 微信公众号：壹枝花算不算浪漫 总结 总结分为两个部分，一个是Riboon执行整体流程图，还一个是Ribbon初始化流程图。 Ribbon整体流程图： Ribbon初始化流程图： 常用配置 常用配置 禁用 Eureka 当我们在 RestTemplate 上添加 @LoadBalanced 注解后，就可以用服务名称来调用接口了，当有多个服务的时候，还能做负载均衡。 这是因为 Eureka 中的服务信息已经被拉取到了客户端本地，如果我们不想和 Eureka 集成，可以通过下面的配置方法将其禁用。 #禁用 Eureka ribbon.eureka.enabled=false 当我们禁用了 Eureka 之后，就不能使用服务名称去调用接口了，必须指定服务地址。 配置接口地址列表 上面我们讲了可以禁用 Eureka，禁用之后就需要手动配置调用的服务地址了，配置如下： #禁用 Eureka

前言 　　本篇文章简单介绍一下什么是微服务、微服务的优点、SpringCloud的微服务架构核心组件选型等； 一、什么是微服务？ 　　微服务的提出者 Martin Fowler 是这样描述微服务的（原文： https://martinfowler.com/articles/microservices.html ）： In short , the microservice architectural style [ 1 ] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which