好猫网手机站
java 分布式有哪些技术(java分布式系统操作)
2022-07-16 20:11:59  浏览:55

java 分布式有哪些技术(java分布式系统操作)

应用架构演进

这里的架构演进应该是从服务化的角度来说,应该说随着业务发展,应用规模扩大,系统的一些公共服务就会抽取出来,独立开发,部署,维护,用来解决并发,扩展,维护的问题。

传统垂直架构

有的地方也叫单体应用,以mvc模式开发:

    所有应用代码统一打包,代码所有接口本地api调用,很少存在远程服务调用; 单机或主备,应用做集群部署; DB主从等。

这种并没有什么不好,发展初期大多是这样,体量没那么大,也不需要考虑高并发大流量可扩展性什么的,简单粗暴,解决业务需求就好,活下去才能活的更好。

但是必须明白这种简单架构存在的一些问题:

1. 业务不断发展,功能逐渐增多,应用的开发维护成本变高,部署效率降低,随便改个代码,编译一次十几分钟就浪费了。悲剧,我们有个系统才开发3年,就碰到这种情况,一次打包编译部署,13分钟结束。

2. 不同的人负责不同的部分,一些通用代码、公共代码就各写各的,不能复用,如果只是util还好,但是一些外部服务的都有重复,那就happy了(不过这种情况的出现,不一定是架构问题,更多可能是管理);

3. 不断地上新需求,不断地改代码,有时测试不到位,指定哪里埋了bug,上生产后系统就down了,牵一发而动全身;

4. 可维护性,可靠性,扩展性变差。

既然有这些问题,就要解决啊,业务就会提要求,你要解决啊,要不然影响我业务发展,影响我ipo上市啊,苦逼的码农开始干活了。

不提应用的拆分主从那些手段,但从拆分后应用交互看,原来的本地api交互变成的远程api的调用,这里就出现了rpc,当然也有走esb,webservice。其实拆分后挺麻烦的,光一个分布式事务就能折腾死人。

RPC架构

Remote Procedure Call,远程方法调用,屏蔽底层实现细节,像调用本地方法一样调用远程服务。

上个作者的图:

这个图对于大多数rpc框架通用,实现的几个技术点:

1. 服务提供者发布服务:服务接口定义,数据结构,服务提供者信息等;

2. 客户端远程调用:通常是使用jdk的代码代理拦截;

3. 底层通信:现在应该更多是使用netty吧,当然也有走支持http的;

4. 序列化:关注序列化反序列性能,xml,json,hessiaon,pb,protostuff,kryo等;

作者给了个socket实现简单demo,来实现远程调用,说明上面几个技术点。

常用的rpc框架

1. Thrift;

2. Hadoop的Avro-RPC;

3. Hessian;

4. gRPC;

单论rpc的话,没太多可说的,可是如果加上服务治理,那复杂度就几何倍数增长了。服务治理里面东西太多了,动态注册,动态发现,服务管控,调用链分析等等问题这些问题,单凭rpc框架解决不了,所以现在常用的说的服务化框架,通常指的是rpc+服务治理2个点。

SOA服务化架构

感觉soa架构应该是在rpc之前出现,用来解决异构系统的交互,通常的实现是通过ESB,WSDL来处理。其粒度通常来说是比较粗的。也存在服务治理方面的问题。

微服务

MSA也是一种服务化架构风格,正流行ing,服务划分

1. 原子服务,粒度细;

2. 独立部署,主要是容器;

分享篇文章:云栖肥侠的文章 微服务(Microservice)那点事 。

MSA与SOA的对比:

    服务拆分粒度:soa首要解决的是异构系统的服务化,微服务专注服务的拆分,原子服务; 服务依赖:soa主要处理已有系统,重用已有的资产,存在大量服务间依赖,微服务强调服务自治,原子性,避免依赖耦合的产生; 服务规模:soa服务粒度大,大多数将多个服务合并打包,因此服务实例数有限,微服务强调自治,服务独立部署,导致规模膨胀,对服务治理有挑战; 架构差异:微服务通常是去中心化的,soa通常是基于ESB的; 服务治理:微服务的动态治理,实时管控,而soa通常是静态配置治理; 交付:微服务的小团队作战。

感觉在有了docker后,微服务这个概念突然火了起来,总结就是微服务+容器+DevOps。

分布式服务框架入门

背景

应用从集中式走向分布式

随着业务的发展导致功能的增多,传统的架构模式开发,测试,部署整个流程变长,效率变低,后台服务的压力变大,只能通过硬件扩容来暂时缓解压力,但解决不了根本性问题:

    应用规模变大,开发维护成本变高,部署效率降低; 代码复用:原来是本地api调用,导致一些公用功能可能是按需开发,不统一,随意等问题; 交付面临困难:主要是业务变得复杂,新增修改测试变得困难,拉长整个流程。

通用法宝:拆分,大系统拆小系统,独立扩展和伸缩。

    纵向:分业务模块; 横向:提炼核心功能,公共业务;

需要服务治理

大拆小,核心服务提炼后,服务的数量变多,而且需要一些运行态的管控,这时候就需要服务治理:

    服务生命周期管理; 服务容量规划; 运行期治理; 服务安全。

服务框架介绍

Dubbo

阿里开源的Dubbo应该是业界分布式服务框架最出名的了吧,看过公司的rpc框架,Dubbo的扩展性比我们的好的多了,我们的框架每次升级,改动都很多,改天要看下Dubbo的源码了解了解扩展性。

HSF

淘宝的体量决定了他对极致性能的追求,HSF跨机房特性挺牛。

Coral Service

这个没听说过,孤陋寡闻了。

框架设计

架构原理

万变不离其中,这张图可以概括rpc的一些通用原理:

细化了下:

    rpc层:底层的通讯框架,通讯协议,序列化和反序列化; 服务发布订阅; 服务治理;

功能

性能

可靠性

分布式的,面试会问,用池子的话讲就是,知识点啊。

服务治理

通讯框架

技术点

    长连接:主要是链路的创建过程到最后的关闭,耗时耗资源;每次调用都要创建的话,调用时延的问题,很可能链路创建的耗时比代码真正执行时长还多; BIO还是NIO:主要是线程模型的选择,推荐篇文章 IO – 同步,异步,阻塞,非阻塞 (亡羊补牢篇); 自研还是使用开源NIO框架:一般来说还是使用开源吧,技术成熟,社区支持,现在netty和mina使用较多了吧。

在功能设计方面,作者基于netty给了demo服务端和客户端的代码,个人理解:

1. 通用性api;

2. 扩展性,封装底层,提供上层接口,隔离协议和底层通讯;

可靠性设计

谈分布式系统必谈可靠性。

链路有效性

通过心跳来确认双方c、s存活,保证链路可用,心跳检测机制分为3个层面:

1. tcp层面,即tcp的keep-alive,作用于整个tcp协议栈;

2. 协议层的心跳检测,主要存在于长连接协议中,例如smpp协议;

3. 应用层的心跳,业务双方的定时发送心跳消息;

第2个没听说过,常用的是1,3。一般使用netty的话用的是netty的读写空闲来实现心跳。

断连

不管因为网络挂了还是服务端宕机,还是心跳超时什么的,导致链路不可用关闭,这时候就需要链路重连,需要注意的一点就是短连后,不要立即重连,留时间给系统释放资源,可以scheduler处理。

消息缓存重发

底层消息不会立即发送(也会导致半包粘包),断链后,导致消息丢失,看有无业务需求,有就支持断链后消息重发。

资源释放

主要是断链后,一定要保证资源销毁和释放,当然也包括一些线程池,内存等的释放。

性能设计

性能差的三宗罪

对于底层通讯框架来说,主要是下面几个:

1. 通讯模型的选择,主要是阻塞非阻塞那些东西;

2. 序列化反序列化(后面有章单讲序列化);

3. 线程模型,主要是服务端选择什么样的线程模型来处理消息。

通信性能三原则

既然有上面的3个问题,那就针对这些做优化了:

    传输:BIONIOAIO的选择; 选择自定义协议栈,便于优化; 服务端线程模型,单线程处理还是线程池,线程池是一个,还是分优先级,Reactor还是其他什么的。

高性能之道这节作者讲了netty的优势。

序列化与反序列化

也就是通常所说的编码、解码。通常的通讯框架会提供编解码的接口,也会内置一些常用的序列化反序列化工具支持。

与通讯框架和协议的关系,感觉可以理解为:通讯框架是通道,其上跑的码流数据是利用各种序列化编码后的各种协议。

功能设计

各种序列化框架需要考虑的主要有:

序列化框架本身的功能的丰富,支持的数据类型; 多语言的支持; 兼容性,往大了说:
    服务接口的前后兼容; 协议的兼容; 支持的数据类型的兼容。
性能,目的是最少的资源,最快的速度,最大的压缩:
    序列化后码流大小; 序列化的速度; 序列化的资源占用。

在扩展性这节,作者讲了netty的对序列化的一些内置支持,但实际开发中,一般不太会使用这些东西,都会提供序列化反序列接口,自行扩展定义,所以扩展性特重要。

常用的序列化,xml,json,hessian,kryo,pb,ps,看需求需要支持那种,具体可以搜索各序列化的性能和压缩后大小。

协议栈

这一章最主要的是讲了自定义协议栈的设计,已经交互的过程,其他讲的可靠性设计什么的跟之前通讯框架一章有重复。

通信模型

服务提供者和消费者之间采用单链路,长连接通信,链路创建流程:

1. 客户端发送握手请求,携带节点ID等认证信息;

2. 服务端校验:节点ID有效性,重复登录,ip地址黑白名单等,通过后,返回握手应答信息;

3. 链路建立后,客户端发送业务消息;

4. 客户端服务端心跳维持链路;

5. 服务端退出时,关闭连接,客户端感知连接关闭,关闭客户端连接。

协议消息定义

通过attachment兼容了扩展性。作者还讲了将消息头的通用序列化和消息体的自定义序列化,看需求吧,我们公司的框架没做这部分支持,做了简化,将消息头和消息体统一封装,然后再加一个序列化方式组成一条消息发送。

安全性设计

    内部的,不一定需要认证,也有基于系统,域名,ip的黑白名单,安全认证的; 外部开发平台的话,基于秘钥认证;
服务路由

服务路由指的是服务提供者集群部署,消费端如何从服务列表中选择合适的服务提供者提供服务进行调用。

透明化路由

    基于zk的服务注册中心的发布订阅; 消费者本地缓存服务提供者列表,注册中心宕机后,不影响已有的使用,只是影响新服务的注册和老服务的下线。

负载均衡

随机 轮循 服务调用时延 一致性Hash
    有个一致性hash算法,挺有意思的,redis的客户端shard用的
黏滞连接
    这个应该不太常用,服务提供者多数无状态,一旦有状态,不利于扩展

这些都是点对点的连接,负载均衡大多会在客户端执行,有种场景会取决于服务端负载,就是服务端服务配置的是域名。

本地路由优先策略

injvm:jvm也提供了消费端的服务,可以改成优先本jvm,对于消费端来说,不需关注提供者; innative:injvm比较少,多得是可能是这种,一个物理机部署多个虚拟机,或者一个容器部署多个服务提供者,消费者不需远程调用,本机,本地或本机房优先。

路由规则

除了上面提供的各种路由负载均衡,还容许自定义路由规则:

– 条件路由:主要是通过条件表达式来实现;

– 脚本路由:通过脚本解析实现。

其实应该还有一种客户端通过代码自定义路由选择。这些主要是为了扩展性。

路由策略定制

自定义路由场景:

1. 灰度;

2. 引流;

路由策略:

1. 框架提供接口扩展;

2. 配置平台提供路由脚本配置;

配置化路由

    本地配置:包括服务提供者和消费者,全局配置3种; 注册中心:路由策略统一注册到服务注册中心,集中化管理; 动态下发:配置后动态下发各服务消费端。
集群容错

指的是服务调用失败后,根据容错策略进行自动容错处理。

集群容错场景

通信链路故障:
    通信过程中,对方宕机导致链路中断; 解码失败等原因Rest掉链接; 消费者read-write socketchannel发生IOException导致链路中断; 网络闪断故障; 交换机异常导致链路中断; 长时间Full GC导致;
服务端超时:
    服务端没有及时从网络读取客户端请求消息,导致消息阻塞; 服务端业务处理超时; 服务端长时间Full GC;
服务端调用失败:
    服务端解码失败; 服务端流控; 服务端队列积压; 访问权限校验失败; 违反SLA策略; 其他系统异常;

业务执行异常不属于服务端异常。

容错策略

这图不错,关系很清晰。

失败自动切换(Failover):
    调用失败后切换链路调用; 服务提供者的防重; 重试次数和超时时间的设置。
失败通知(FailBack):失败后直接返回,由消费端自行处理; 失败缓存(Failcache):主要是失败后,缓存重试重发,注意:
    缓存时间、缓存数量; 缓存淘汰算法; 定时重试的周期T、重试次数;
快速失败(Failfast):失败不处理,记录日志分析,可用于大促期间,对非核心业务的容错。

容错策略扩展

    容错接口的开放; 屏蔽底层细节,用户自定义; 支持扩展。

其实还有一点,感觉也挺重要,就是支持容错后本地mcok。调用失败后的链路切换和快速失败肯定要支持,缓存重发可以不用。