chuixue24的博客

在微服务架构体系里面，我们一般会使用到微服务网关或叫API网关。大家都比较清楚，在微服务架构体系下本身是去中心化的架构，通过服务注册中心来实现服务注册发现和消费调用，那么为何又需要使用API网关？在传统的ESB总线进行服务集成的时候我们就经常谈到一个概念就是位置透明，即需要屏蔽底层业务模块提供API接口服务地址信息，并实现多个微服务API接口的统一出口。即类似设计模式里面经常谈到的门面模式。如何给API网关一个定义？

【代码】Eureka - 生产配置最佳实践。

服务端采用三级缓存（registry，readWriteCacheMap，readOnlyCacheMap）来存储注册表信息。链接https//www.jianshu.com/p/f3d6775cdd2e。商业转载请联系作者获得授权，非商业转载请注明出处。

为啥服务都下线了还会有那么多的请求一直进来呢？呐，我们都知道 Eureka 是 AP 模型，其实根本原因在于 Eureka 使用了三级缓存来保存服务的实例信息，如下图所示。我们的服务注册的时候会和 server 保持一个心跳，这个心跳的时间是 30 秒，服务注册之后，客户端的实例信息保存到 Registry 服务注册表当中，注册表中的信息会立刻同步到 readWriteCacheMap 之中。而客户端如果感知到这个服务，要从 readOnlyCacheMap 去读取，这个只读缓存需要 30 秒的时间去从 r

伴随云计算的滚滚浪潮，云原生(CloudNative)的概念应运而生，云原生很火，火得一塌糊涂，都0202年了，如果你还不懂云原生，那真的out了。大家言必称云原生，却鲜少有人告诉你到底什么是云原生，若是找资料来看，读完大多会感觉云绕雾罩，一知半解，总之虚得很；甚至会让你一度怀疑自己的智商，不过我对于读不懂的文章，一律归因于写文章的人太蠢，当然这不一定是事实，但这样的思考方式能让我避免陷入自我怀疑的负面情绪。云原生之所以解释不清楚，是因为云原生没有确切的定义，云原生一直在发展变化之中，解释权不归

1 RPC协议综述:ONC RPC为例RPC需要解决五个问题：如何规定远程调用的语法？如果传递参数？如何表示数据？（前三个问题统称为协议问题）如何知道一个服务端都实现了哪些远程调用，从哪个端口可以访问这个远程调用？（服务发现问题）发生了错误、重传、丢包、性能等问题怎么办？（传输问题）协议问题语法问题：RPC调用标准如下比如基于RPC协议实现的NFS（Network File System，网格文件系统）可以在本地mount一个远程的目录到本地的一个目录，从而使得本地的用户在这个目录里面写.

一、Eureka ServerEureka Server为了避免同时读写内存数据结构造成的并发冲突问题，采用了多级缓存机制来进一步提升服务请求的响应速度。Eureka Server存在三个变量：（registry、readWriteCacheMap、readOnlyCacheMap）保存服务注册信息，默认情况下定时任务每30s将readWriteCacheMap同步至readOnlyCacheMap，每60s清理超过90s未续约的节点，Eureka Client每30s从readOnlyCach

服务消费端执⾏逻辑 1. MockClusterInvoker.invoke(new RpcInvocation(method, args))：Mock逻辑2. AbstractClusterInvoker.invoke(invocation)：把RpcContext中设置的Attachments添加到invocation对象上，调⽤路由链从服务⽬录上筛选出适合的服务Invoker，获得服务均衡策略loadbalance3. FailoverClusterInvok...

Dubbo SPI 架构图Demo ExtensionLoader<Protocol> extensionLoader = ExtensionLoader.getExtensionLoader(Protocol.class);Protocol http = extensionLoader.getExtension("dubbo");System.out.println(http);上⾯这个Demo就是Dubbo常⻅的写法，表示获取"dubbo"对应的Protocol扩展点。

负载均衡 官⽹地址：http://dubbo.apache.org/zh/docs/v2.7/user/examples/loadbalance/ 如果在消费端和服务端都配置了负载均衡策略，以消费端为准。 这其中⽐较难理解的就是最少活跃调⽤数是如何进⾏统计的？ 讲道理，最少活跃数应该是在服务提供者端进⾏统计的，服务提供者统计有多少个请求正在执⾏中。 但在Dubbo中，就是不讲道理，它是在消费端进⾏统计的，为什么能在消费端进⾏统计？ 逻辑是这样的： 1. 消费者会缓存所调⽤服务的所

维基百科是这么定义RPC的： 在分布式计算，远程过程调⽤（英语：Remote Procedure Call，缩写为 RPC）是⼀个计算机通信协议。该协议允许运⾏于⼀台计算机的程序调⽤另⼀个地址空间（通常为⼀个开放⽹络的⼀台计算机）的⼦程序，⽽程序员就像调⽤本地程序⼀样，⽆需额外地为这个交互作⽤编程（⽆需关注细节）。RPC是⼀种服务器-客户端（Client/Server）模式，经典实现是⼀个通过发送请求-接受回应进⾏信息交互的系统。 如果涉及的软件采⽤⾯向对象编程，那么远程过程调⽤亦可称作远程调

当Spring启动过程中，会去给@Reference注解标注了的属性去进⾏赋值，赋值的对象为ReferenceBean中get()⽅法所返回的对象，这个对象是⼀个代理对象。对于ReferenceBean，它表示应⽤想要引⼊的服务的信息，在执⾏get()时会做如下⼏步： 1. 调⽤checkAndUpdateSubConfigs()，检查和更新参数，和服务提供者类似，把ReferenceBean⾥的属性的值更新为优先级最⾼的参数值 2. 调⽤init()去⽣成代理对象ref，get()

服务导出的⼊⼝⽅法为ServiceBean.export()，此⽅法会调⽤ServiceConfig.export()⽅法，进⾏真正的服务导出。 服务导出⼤概原理服务导出的⼊⼝为ServiceBean中的export()⽅法，当Spring启动完之后，通过接收Spring的 ContextRefreshedEvent事件来触发export()⽅法的执⾏。 ⼀个ServiceBean对象就表示⼀个Dubbo服务，ServiceBean对象中的参数就表示服务的参数，⽐如timeout，

Eureka是Netflix开源的一款提供服务注册和发现的产品，github地址为https://github.com/Netflix/eureka。注册中心是分布式开发的核心组件之一，而eureka是spring cloud推荐的注册中心实现，因此对于Java开发同学来说，还是有必要学习eureka的，特别是其架构及设计思想。官方文档定义是：Eureka is a REST (Representational State Transfer) based service that is primari.

总体说明先来看一下 Hystrix 的官方介绍：Hystrix is a library that helps you control the interactions between these distributed services by adding latency tolerance and fault tolerance logic. Hystrix does this by isolating points of access between the services, stoppi

一、可靠消息最终一致性事务概述可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息，事务参与方(消息消费者)一定能够接收消息并处理事务成功，此方案强调的是只要消息发给事务参与方最终事务要达到一致。 此方案是利用消息中间件完成，如下图：事务发起方（消息生产方）将消息发给消息中间件，事务参与方从消息中间件接收消息，事务参与方（消息消费方）和消息中间件之间都是通过网络通信，由于网络通信的不确定性会导致分布式事务问题。因此可靠消息最终一致性方案要解决以下几个问题：【1】本地事务与消息发送

确切地说，服务中⼼的划分原则更多的是架构设计经验总结，我们很难对⼀些具体的问题给⼀个精确的量化指标，但有⼀点，我很反对现在微服务中的LOC（Line Of Code）这种指标，即⽤代码的⾏数来衡量⼀个微服务落地的标准。架构本来就是⼀个追求平衡的艺术，不仅是设计原则上的平衡，还要在技术、成本、资源、性能、团队等各⽅⾯进⾏平衡，以最⾼效地解决主要问题。我认为这也是⼀名优秀架构师的必备特质，偏执地追求⼀个维度的完美肯定会在其他⽅⾯付出代价。从服务中⼼设计来看，⼀定要兼顾三个⽅⾯的需求，

github新增仓库 "dubbo-read"（点此查看），集合所有《Dubbo原理和源码解析》系列文章，后续将继续补充该系列，同时将针对Dubbo所做的功能扩展也进行分享。不定期更新，欢迎Follow。1 框架设计在官方《Dubbo 开发指南》框架设计部分提到，Dubbo 服务框架的基本设计原则是：采用 URL 作为配置信息的统一格式，所有扩展点都通过传递 URL 携带配置信息； 采用 Microkernel + Plugin 模式，Microkernel 只负责组装 Plugin..

github新增仓库 "dubbo-read"（点此查看），集合所有《Dubbo原理和源码解析》系列文章，后续将继续补充该系列，同时将针对Dubbo所做的功能扩展也进行分享。不定期更新，欢迎Follow。一、框架设计在官方《Dubbo 开发指南》框架设计部分，给出了引用服务时序图：另外，在官方《Dubbo 用户指南》集群容错部分，给出了服务引用的各功能组件关系图：本文将根据以上两张图，分析服务引用的实现原理，并进行详细的代码跟踪与解析。二、原理和源码解析2.1 ...

github新增仓库 "dubbo-read"（点此查看），集合所有《Dubbo原理和源码解析》系列文章，后续将继续补充该系列，同时将针对Dubbo所做的功能扩展也进行分享。不定期更新，欢迎Follow。一、框架设计在官方《Dubbo 用户指南》架构部分，给出了服务调用的整体架构和流程：另外，在官方《Dubbo 开发指南》框架设计部分，给出了整体设计：以及暴露服务时序图：本文将根据以上几张图，分析服务暴露的实现原理，并进行详细的代码跟踪与解析。二、原...

github新增仓库 "dubbo-read"（点此查看），集合所有《Dubbo原理和源码解析》系列文章，后续将继续补充该系列，同时将针对Dubbo所做的功能扩展也进行分享。不定期更新，欢迎Follow。一、Dubbo 配置方式Dubbo 支持多种配置方式：XML 配置：基于 Spring 的 Schema 和 XML 扩展机制实现 属性配置：加载 classpath 根目录下的 dubbo.properties API 配置：通过硬编码方式配置（不推荐使用） 注解配置：通过注解..

DubboBeanDefinitionParser.parse()---->ServiceBean.onApplicationEvent()---->ServiceBean.export()---->ServiceConfig.export()---->ServiceConfig.doExport()---->ServiceConfig.doExportUrls()---->ServiceConfig.doExportUrlsFor1Protocol()---->S

在dubbo服务化时，有时会遇到这样的异常信息：Caused by: com.alibaba.dubbo.remoting.RemotingException: Server side(192.168.202.56,20880) threadpool is exhausted ,detail msg:Thread pool is EXHAUSTED! Thread Name: DubboServerHandler-192.168.202.56:20880, Pool Size: 200 (active

本文是针对 Dubbo 协议调用的调优指导，详细说明常用调优参数的作用域及源码。Dubbo调用模型常用性能调优参数 参数名 作用范围 默认值 说明 备注 threads provider 200 业务处理线程池大小 iothreads pro..

阅读须知dubbo版本：2.6.0 spring版本：4.3.8 文章中使用/* */注释的方法会做深入分析正文我们知道，dubbo的生产者和消费者的关系维护在注册中心，所以，消费者关联生产者肯定是需要订阅注册中心的相关生产者信息才能完成，在Dubbo源码解析之registry注册中心这篇文章中我们分析了dubbo有关注册中心的一些操作如注册、订阅等，在文章的最后，我们分析了消费者订阅注册中心的configuration、routers、providers等信息的流程，在处理provider信

一 RPC协议的网络传输一个RPC协议又通信模块、报文编码和序列化三个模块组成，其中通信模块实现了RPC的网络传输。网络传输的稳定性和性能直接影响RPC服务的稳定性和性能。网络传输框架组成io模型 （1）BIO：同步阻塞 （2）NIO：同步非阻塞（Netty） （3）AIO：异步非阻塞 连接方式 （1）长连接（Netty） （2）短链接 线程分类（每个线程都有配有线程池） （1）IO线程 （2）服务端业务线程 （3）客户端调度线程 （4）客户端结果exchange线程 （5

@[TOC] 背景昨天接到一个任务，把我们的旧项目改造下，实现微服务化。之前有用过基于SpringBoot+Dubbo的微服务，基于dubbo的注解来实现。这次改造，原理上和之前的相通，但实际操作未必一样。今天对改造完的项目进行了测试，没有问题，在此记录分享一下。如果实现微服务，目前流行的SpringCloud，但如果不是一个全新的项目，而是对旧项目进行改造，那技术选型还是Dubbo合适。Dubbo中文手册：http://dubbo.apache.org/zh-cn/docs/us.