Dubbo

3 月，跳不动了？>>> 小弟本着先会用在学习原理的原则 先用了dubbo 现在在实际业务中 因为分布式项目做了集群，需要用的分布式锁，就用到了基于redis的分布式锁，废话不多说，先来代码： package com.tiancaibao.utils; import org.slf4j.Logger; import org.slf4j.LoggerFactory; /** * Redis distributed lock implementation. * * @author qingzhipeng */ public class RedisLock { private static Logger logger = LoggerFactory.getLogger(RedisLock.class); private static final int DEFAULT_ACQUIRY_RESOLUTION_MILLIS = 100; /** * Lock key path. */ private String lockKey; /** * 锁超时时间，防止线程在入锁以后，无限的执行等待 */ private int expireMsecs = 60 * 1000; /** * 锁等待时间，防止线程饥饿 */ private int timeoutMsecs = 10 * 1000;

1 zookeeper如何实现高可用 1 zookeeper 多台构成集群实现高可用，有三种角色群首（leader），追随者（follower），观察者（observer）。 Leader作为整个ZooKeeper集群的主节点，负责响应所有对ZooKeeper状态变更的请求。它会将每个状态更新请求进行排序和编号，以便保证整个集群内部消息处理的FIFO Follower的逻辑就比较简单了。除了响应本服务器上的读请求外，follower还要处理leader的提议，并在leader提交该提议时在本地也进行提交。，leader和follower构成ZooKeeper集群的法定人数，也就是说，只有他们才参与新leader的选举、响应leader的提议。 如果ZooKeeper集群的读取负载很高，或者客户端多到跨机房，可以设置一些observer服务器，以提高读取的吞吐量。Observer和Follower比较相似，只有一些小区别：首先observer不属于法定人数，即不参加选举也不响应提议；其次是observer不需要将事务持久化到磁盘，一旦observer被重启，需要从leader重新同步整个名字空间。 2 zookeeper如何实现负载均衡？ 以前接触的负载均衡是通过VIP调度到各个节点。如：nginx+keepalived实现负载均衡和高可用

1.Dubbo是什么？ Dubbo 是一个分布式、高性能、透明化的 RPC 服务框架，提供服务自动注册、自动发现等高效服务治理方案， 可以和 Spring 框架无缝集成。 RPC 指的是远程调用协议，也就是说两个服务器交互数据。 2.Dubbo的由来？ 互联网的快速发展，Web应用程序的规模不断扩大，一般会经历如下四个发展阶段。 单一应用架构 当网站流量很小时，只需一个应用，将所有功能都部署在一起即可。 垂直应用架构 当访问量逐渐增大，单一应用按照有业务线拆成多个应用，以提升效率。 此时，用于加速前端页面开发的 Web框架(MVC) 是关键。 分布式服务架构 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。 此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。 流动计算架构 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。 此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。 3.Dubbo的主要应用场景？ 透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。 软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。

区别 来源（背景）： Dubbo，是阿里巴巴服务化治理的核心框架，并被广泛应用于阿里巴巴集团的各成员站点。 Spring Cloud，从命名我们就可以知道，它是Spring Source的产物，Spring社区的强大背书可以说是Java企业界最有影响力的组织了，除了Spring Source之外，还有Pivotal和Netfix是其强大的后盾与技术输出。其中Netflix开源的整套微服务架构套件是Spring Cloud的核心。 传输： Dubbo由于是二进制的传输，占用带宽会更少； Spring Cloud是http协议传输，带宽会比较多，同时使用http协议一般会使用JSON报文，消耗会更大。但是在国内95%的公司内，网络消耗不是什么太大问题，如果真的成了问题，通过压缩、二进制、高速缓存、分段降级等方法，很容易解。 开发难度： Dubbo的开发难度较大，原因是dubbo的jar包依赖问题很多大型工程无法解决； Spring Cloud的接口协议约定比较自由且松散，需要有强有力的行政措施来限制接口无序升级 后续改进： Dubbo通过dubbofilter，很多东西没有，需要自己继承，如监控，如日志，如限流，如追踪 Spring Cloud自己带了很多监控、限流措施，但是功能可能和欧美习惯相同，国内需要进行适当改造，但更简单，就是ServletFilter而已

3 月，跳不动了？>>> SPI 全称为 Service Provider Interface，是一种服务发现机制。当程序运行调用接口时，会根据配置文件或默认规则信息加载对应的实现类。所以在程序中并没有直接指定使用接口的哪个实现，而是在外部进行装配。 要想了解 Dubbo 的设计与实现，其中 Dubbo SPI 加载机制是必须了解的，在 Dubbo 中有大量功能的实现都是基于 Dubbo SPI 实现解耦，同时也使得 Dubbo 获得如此好的可扩展性。 Java SPI 通过完成一个 Java SPI 的操作来了解它的机制。 创建一个 AnimalService 接口及 category 方法 创建一个实现类 Cat 创建 META-INF/services 目录，并在该目录下创建一个文件，文件名为 AnimalService 的全限定名作为文件名 在文件中添加实现类 Cat 的全限定名 Animal 接口 public interface AnimalService { void category(); } Cat 实现类 public class Cat implements AnimalService { @Override public void category() { System.out.println("cat: Meow ~"); } } 在 META-INF

3 月，跳不动了？>>> zookeeper作为dubbo的注册中心： 工作过程： 服务提供者（provider）在初始化启动时，会在zookeeper中的dubbo节点下的服务节点下（com.foo.BarServie）的providers节点下创建一个子节点并且写入自己的URL地址，路径（目录）为/dubbo/servicename/providers/，该路径（目录）下的子节点均为服务提供者。此时这些节点均为临时节点，因为临时节点的生命周期和客户端会话相关，所以一旦服务提供者所在的机器出现故障导致无法提供服务时，该临时节点就会从zookeeper中删除。 服务消费者（consumer）初始化启动时，会订阅/dubbo/servicename/providers/路径（目录）下的提供者的URL地址，并在/dubbo/servicename/consumers/路径（目录）下创建临时子节点并且写入自己的URL地址，该路径（目录）下的子节点均为服务消费者。 由于服务提供者、消费者、注册中心之间是长连接，注册中心能感知服务提供者宕机，会通知消费者。因为监控中心是dubbo服务治理体系中重要的一部分，它需要知道服务提供者和消费者的所有情况变化情况，所以它在启动时会在路径（目录）为/dubbo/servicename/的服务节点上（com.foo.BarServie

3 月，跳不动了？>>> 1-SOA分布式架构搭建(dubbo) 一、分布式架构的演进 1.单一应用架构 优点：适用于小型网站，小型管理系统，将所有功能都部署到一个功能里，简单易用。 缺点： 1.性能扩展比较难  2.协同开发问题  3.不利于升级维护 2.垂直应用架构 优点：通过切分业务来实现单个模块单独独立部署，降低了维护和部署的难度，团队各司其职比较容易，性能扩展也更方便，更有针对性。 缺点：公用模块无法重复利用，开发性能浪费 3.分布式应用架构 优点：将各个应用通过分层独立出来，可以利用rpc实现web与service、service与service的互相调用，提高了代码的复用性。 缺点：每个调用的模块都要存储一份完整的被调用模块的位置和状态，一旦位置和状态发生变化，就要更新所有涉及的配置 4.面向服务的分布式架构   **架构概述：**随着架构不断增大，服务节点也越来越多，服务之间的调用和依赖关系也越来越负责，需要一个统一的中心来调度、路由、管理所有的服务基于这个中心构建的这个新型架构就是目前主流的SOA分布式架构。 二、分布式工程的模块搭建 1、分布式模块文件图   由于查询web应用需要调用爬虫service接口，那么必须在订单的工程中也包含一份service接口。   如果拷贝一个接口道查询工程中，那么如果以后有更多的模块都调用这个接口呢？每个接口都拷贝一份嘛？  

3 月，跳不动了？>>> 本文主要分析一下NettyServer，HeaderExchangeServer实现细节。 1、NettyServer NettyServer整个类图如下： 首先从全貌上大概看一下NettyServer对象所持有的属性： AbstractPeer private final ChannelHandler handler 事件处理Handler。 private volatile URL url 该协议的第一个服务提供者的URL， Server只需要用到 URL中的参数，与具体某一个服务没什么关系。 AbstractEndpoint private Codec2 codec 编码解码器。 private int timeout 超时时间 private int connectTimeout 连接超时时间 AbstractServer private InetSocketAddress localAddress ：url host:port地址。 private InetSocketAddress bindAddress：如果是多网卡，并且指定了 bind.ip、bind.port，如果为空，与localAddress相同。 private int accepts ： AbstractServer#accepts未使用到。 private int

3 月，跳不动了？>>> spring-boot-dubbo-sample 简介 此小程序展示了如何用spring-boot启动一个dubbo provider，并通过spring-boot启动一个consumer。本程序，下载后无需修改可以直接运行 Spring-boot启动Dubbo时，无需启动tomcat等容器，即非web项目，那么需要在springApplication的main中设置web(false)即可 运行方法 maven引入相关包后，运行provider中的App中的main，即可启动provider 启动provider后，运行consumer中的App的main，即读取provider中的helloService 项目地址： http://git.oschina.net/smarti/spring-boot-dubbo-sample 来源： oschina 链接： https://my.oschina.net/u/2398247/blog/718731

3 月，跳不动了？>>> Dubbo是一个分布式服务框架，以及SOA治理方案。其功能主要包括：高性能NIO通讯及多协议集成，服务动态寻址与路由，软负载均衡与容错，依赖分析与降级等。 它有5个节点，分别是Provider, Consumer, Registry, Monitor, Container。其中Provider是服务提供者， Consumer是服务消费者，Registry是服务进行注册和被发现的注册中心，Monitor是统计服务的调用次数和调用时间的监控中心，Container是服务运行容器。他们之间调用的关系是：Container负责启动，加载然后运行Provider。Provider在启动时会向注册中心注册自己提供的服务，Consumer在启动时会向Registry订阅自己所需服务，此时Registry会返回Provider地址列表给Consumer。如果地址有变更，Registry会基于长连接推送变更数据给Consumer。Consumer会基于软负载均衡算法选一台提供者进行调用，如果调用失败，则再选一台。Provider和Consumer在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到Monitor。 Dubbo具有4个特点，分别是连通性、jian壮性、伸缩性、以及向未来架构的升级性。连通性说明他们之间都存在着关系，比如说Provider