Java编程良心推荐——分布式架构原理解析
Posted Linkey bpm
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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等认证信息;
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。调用失败后的链路切换和快速失败肯定要支持,缓存重发可以不用。
本篇篇幅过长,相信能坚持看到最后的都是对知识求知如渴的人,将来必定不凡。顺便点点关注点点赞呗。
欢迎工作一到五年的Java工程师朋友们加入Java架构开发:878249276
群内提供免费的Java架构学习资料(里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码,MyBatis,Netty,Redis,Kafka,mysql,Zookeeper,Tomcat,Docker,Dubbo,nginx等多个知识点的架构资料)合理利用自己每一分每一秒的时间来学习提升自己,不要再用"没有时间“来掩饰自己思想上的懒惰!趁年轻,使劲拼,给未来的自己一个交代!
以上是关于Java编程良心推荐——分布式架构原理解析的主要内容,如果未能解决你的问题,请参考以下文章
良心!鹅厂强推的695页SpringCloudNginx高并发核心编程
14套java精品高级架构课,Dubbo分布式Restful 服务,并发原理编程,SpringBoot,SpringCloud,RocketMQ中间件视频教程