firemail
标题: 让你一分钟了解分布式服务框架 [打印本页]
作者: java 时间: 2018-5-3 09:42
标题: 让你一分钟了解分布式服务框架
本帖最后由 java 于 2018-5-3 09:54 编辑
让你一分钟了解分布式服务框架
程序员的日常那些事 2018-05-02 19:07:00
[size=13.3333px]
1:应用架构的演进过程
说到分布式架构,首先需要了解一下应用架构的整个演进过程,如下图所示
第一代:MVC架构 :当业务规模很小时,将所有功能都部署在同一个进程中,通过双机或者前置负载均衡实现负载分流;此时,用于分离前后逻辑的Mvc架构是关键。
Model View Controller,是模型(model)-视图(view)-控制器(controller)的缩写
第二代:RPC架构:当垂直应用越来越多,应用之间交互不可避免,将核心和公共业务抽取出来,作为独立的服务,实现前后台逻辑分离、此时,用于提高业务复用和拆分的RPC框架是关键。
RPC(Remote Promote Call)远程过程调用 一种进程间通信方式。允许像调用本地服务一样调用远程服务。
第三代:SOA架构:随着业务发展,服务数量越来越多,服务生命周期管控和运行态的治理成为瓶颈,此时用于提升服务质量的SOA服务治理是关键。
SOA (面向服务的架构)Service-Oriented Architecture
第四代:微服务架构:随着敏捷开发,持续交付,DEVOPS理论的发展和实践,以及基于docker等轻量级容器部署应用和服务的成熟,微服务架构开始流行,逐渐成为应用架构的未来演进方向。通过服务的原子拆分,以及微服务的独立打包,部署和升级,小团队敏捷交付,应用的交付周期将缩短,运维成本也将大幅下降。
随着大型应用的不断发展,新的业务需求和功能不断增加,技术也在不断演进,不同团队构建的功能子系统采用的技术架构五花八门,子系统之前的开发,部署和运维模式也存在较大差异。传统垂直架构已经不能适应业务发展的需求,服务化改造才是最有效的方式。而改造的核心就是分布式服务架构。
2:分布式诞生的背景:
应用从集中式走向分布式。大规模系统架构的设计一般规则就是尽可能的拆分,以达到更好的独立扩展与伸缩,更灵活的部署,更好的隔离和容错,更高的开发效率。具体的拆分策略大体分为横向拆分和纵向拆分。
使用WEB服务或者rpc架构对业务进行拆分后,随着服务数的增多,急需一个服务治理框架,有效管控服务,提升服务运行期质量,防止业务服务代码架构腐化。服务治理主要有以下几点:
生命周期管理:服务上线,测试发布和下线通知机制要规范化。
服务容量规划:随着业务的发展,服务调用量越来越大,服务的容量问题逐渐显现出来。需要通过采集服务调用性能,时延,成功率,系统资源占用等综合指标,为容量规划提供精确的数据支持。
运行期治理:流量陡增,系统资源成为瓶颈,对非核心服务采取降级,限流的措施,保证核心业务的运行;缓存失效时,系统压力转移到数据库,服务调用时延突然增大,业务失败率升高,需要在线调大服务调用超时时间,保证业务成功率;非核心服务发生故障时,希望对业务放通,不调用远程服务,取而代之的是执行本地的降级逻辑。
服务安全:敏感数据需要有权限控制。
3:分布式服务框架设计
尽管不同的分布式架构实现细节存在差异,但是核心功能差异不大。通常,分布式服务框架的架构可以抽象为三层。
1)RPC层:包括底层通信框架(例如NIO框架),序列化和反序列化框架,用于屏蔽底层通信协议细节和序列化方式差异的Remoting框架。
2)Filter Chain层:服务调用职责链,提供多种服务调用切面提供框架自身和使用者扩展,例如负载均衡,服务调用性能统计,服务调用完成通知机制,失败重发等。
3)Service层:主要包括java动态代理,消费者使用,主要用于将服务提供者的接口封装成远程服务调用:java反射,服务提供者使用,根据消费者请求消息中的接口名,方法名,参数列表反射调用服务提供者的接口本地实现类。
从功能角度看,分布式服务框架通常会包含另外两个重要功能:服务治理中心和服务注册中心,业务需求不同,具体实现细节也存在很大差异。以服务注册中心为例,HSF使用的是基于数据库的ConfigServer,Dubbo默认使用的是Zookeeper。
服务注册中心负责服务的发布和通知,通常支持对等集群部署,某一个服务注册中心当机并不会导致整个服务注册中心集群不可用。
服务治理中心通常包含服务治理接口和服务治理Portal,架构师,测试人员和系统维护人员通过服务治理Portal对服务的运行状态,历史数据,健康度和调用关系等进行可视化的分心和维护,目标就是要持续优化服务,防止服务架构腐化,保证服务高质量运行。
4:分布式架构的功能特性
1)服务订阅发布:
配置化发布和引用服务:支持通过XML配置的方式发布和导入服务,降低对业务代码的侵入。
服务自动发现机制:支持服务实时自动发现,由注册中心推送服务地址,消费者不需要配置服务提供者地址,服务地址透明化。
服务在线注册和去注册:支持运行态注册新服务,也支持运行态取消服务注册。
2)服务路由:
3)集群容错
Failover:失败自动切换,当出现失败,重试其他服务器,通常用于读操作;也可用于幂等性写操作
Failback:失败自动恢复,后台记录失败请求,定时重发,通常用于消息通知操作
Failfast:快速失败,只发起一次调用,失败立即报错,通常用于非幂等性的写操作
4)服务调用
同步调用:消费者发起服务调用之后,同步阻塞等待服务端响应
异步调用:消费者发起服务调用之后,不阻塞立即返回,由服务端返回应答后异步通知消费者
并行调用:消费者同时对多个服务提供者批量发起服务调用请求,批量发起请求后,集中等待应答
5)多协议
私有协议:支持二进制等私有协议,支持私有协议定制和扩展
公有协议:提供 Web Service等公有协议,用于外部服务对接
6)序列化方式
7)统一配置
5:分布式架构的性能特性
1)高性能:在同等资源占用情况下,单服务提供者的TPS要尽量高
2)低时延:在同等资源下,服务调用时延要尽量低
3)性能线性增长:扩展服务提供者,性能要能够线性增长
6:分布式架构的可靠性
应用有单机调用演进到分布式部署之后,由于网络故障,会导致业务失败率增加,分布式框架需要具备很强的可靠性来保证业务的成功率。
1)服务注册中心:
健康状态监测:注册中心通过心跳检测服务提供者的存在,服务提供者当机,注册中心将立即推送事件通知消费者。
故障切换:注册中心对等集群,任意一台当机后,将自动切换。
高HA:注册中心全部当机后,服务提供者和服务消费者仍能通过本地缓存通信
2)消除单点故障:
7:服务治理
1)服务运行态管控:
服务路由:动态修改路由
服务限流:资源成为瓶颈时,服务端和消费者的动态流控
服务迁入迁出:实现资源的动态分配
服务降级:服务提供者故障时或者业务高峰期,进行服务强制或者容错降级,执行本地降级逻辑,保证系统平稳运行
服务超时控制:动态调整超时时间,在业务高峰期保障业务调用成功率
2)服务监控:
性能统计:统计项包括服务调用时延、成功率、调用次数等
统计报表:提供多维度、实时和历史数据报表,同比、环比等性能对比数据,供运维、运营等使用
告警:指标异常,根据告警策略发送告警,包括但不限于短信、E-mail、记录日志等
3)服务生命周期管理
上线审批:服务提供者不能随意线上发布服务,需要通过正规的审批流程批准之后才能上线
下线通知:服务提供者在下线某个服务之前一段时间,需要根据SLA策略,通知消费者
服务灰度发布:灰度环境划分原则、接口前向兼容性策略,以及消费者如何路由,都需要灰度发布引擎负责管理
4)故障快速定界定位
分布式日志采集:支持在大规模分布式环境中实时采集容器、中间件和应用的各种日志
海量日志在线检索:支持分布式环境海量日志的在线检索,支持多维度索引和模糊査询
调用链可视化展示:通过分布式消息跟踪系统输出调用链,可视化、快速地进行故障定界
运行日志故障定位:通过调用链的故障关键字,在日志检索界面快速检索故障日志,用于故障的精确定位
5)服务安全
目前,开源的分布式架构有阿里的dubbo,spring的spring cloudy。都是很不错的。大家有空可以研究一下源码,一定会有收获。
欢迎光临 firemail (http://firemail.wang:8088/) |
Powered by Discuz! X3 |