服务化框架技术选型实践
前言
首先本文不讨论为什么要服务化,包括服务化的优点缺点。
其次本文也不讨论什么是微服务,也不讨论微服务和SOA的区别。
最后本文也不讨论哪个技术最优。
服务框架构成
最基本的服务框架
基本的服务化框架包括如下模块:统一的RPC框架,服务注册中心,管理平台。
有了这三个模块,就能实现基本的服务化。下面对三个模块进行具体分析。
RPC框架选型
为什么一定要是统一的RPC框架,而不是随便啥框架,这里主要是为了技术对齐,减少开发人员的学习成本,减少团队间沟通成本。
好,那么选择一个RPC框架,我们都需要考量什么东西呢?这里我总结下:
- 代码规范:例如是对已有代码透明,还是代码生成。
- 通讯协议:例如是TCP还是HTTP
- 序列化协议:例如是二进制还是文本,是否需要跨语言,性能
- IO模型:异步/同步,阻塞/非阻塞
- 负载均衡:客户端软负载,代理模式,服务端负载
另外如果是从开源里面选择,那么我们还需要考量:
- 成熟度:包括学习成本,社区热度,文档数,是否有团队维护,稳定性(盲目追求的不一定是最适合)
- 可扩展性:是否有SPI支持扩展,是否支持上下兼容
- 跨语言:是否支持跨语言
- 性能:要想作为RPC框架,性能一般都不会太差 [滑稽脸]
下面是常见的一些开源框架的比较,大家可以看一下。
Ps:SOAP,RMI,Hessian,ICE就不列举了。
选型小结:
- 如果需要与前端交互的,适合短链接、跨语言的RPC框架,例如RESTful、gRPC等
- 如果纯粹后台交互的,适合长链接、序列化为二进制的RPC框架,例如thrift、dubbo等更高效
- 如果是小公司,新公司从头开始推广服务化框架的,可以选择规范化的RPC框架,例如thrift、RESTful、gRPC
- 如果是已有大量业务代码的再推广服务框架的,那么最好选择无代码入侵的RPC框架,例如dubbo、RESTful
注册中心选型
注册中心相当于是服务提供者和服务调用者之间的引路人,在服务治理中的作用极为重要。
选择注册中心基本要考量:
- 服务注册:接收注册信息的方式
- 服务订阅:返回订阅信息的方式,推还是拉
- 状态检测:检测服务端存活状态
重点提一下这个状态检测,因为这个要是检测不准确会误判,导致严重后果,
例如Zookeeper根据服务端注册的临时节点进行状态检测,如果服务端和Zookeeper之间的网络闪断,导致Zookeeper认为服务端已经死了,从而摘掉这个节点。
但是其实客户端和服务端直接的网络是好的,这样就有可能把节点全部摘掉,导致无可用节点。
如果是从开源里面选择,那么还需要考量:
- 成熟度:包括学习成本,社区热度,文档数(盲目追求的不一定是最适合)
- 维护成本:注册中心维护
- 数据解构:是否能快速定位结果,是否能遍历
- 性能和稳定性:
- CAP原则:CP(关注一致性)还是AP(关注可用性)
下面是常见的一些使用开源项目做注册中心的比较,大家可以看一下。
Ps:Redis和MySQL没有列举。
选型小结:
- 规模小选择CP,RPC框架可以直接接入数据源
- 规模大选择AP, RPC框架不可以直接接入数据源
- 存在跨机房,跨地域的尽量不要选有强一致性协议的注册中心
- RPC框架必须要有注册中心不可用的容灾策略
- 服务状态检测十分重要
简易管理端
管理端没啥特殊要求,最起码能看到服务提供者和调用者即可。
完善的服务化框架
如果需要一个完善的服务化框架,那么必须增加外部模块,常见的模块如下图:
接口文档管理
提供一个接口文档管理以及接口查询的入口,可以是一个公共的WIKI,也可以是独立的系统,等等。
这里可以定义接口的文档,包括接口描述,方法定义,字段定义
可以定义接口的SLA,包括支持的并发数,tp99多少,建议配置是什么
还有就是接口的负责人等一些查询的入口。
配置中心
提供一个配置管理的地方,这里说的配置主要指的是服务相关的一些配置。
配置包括分组配置、路由策略、黑白名单、降级开关、限流信息、超时时间、重试次数等等,任何可以动态变更的所有数据。
这样服务提供者和服务调用者可以不需要重启自己的应用,直接进行配置的变更。
配置中心可以独立于注册中心,也可以和注册中心合并。
监控中心
监控服务关注接口维度,实例(例如所在JVM实例)维度的数据。
RPC框架可以定时上报调用次数,耗时,异常等信息。
监控中心可以统计出服务质量信息,也可以进行监控报警。
分布式跟踪
区别于监控中心,以调用链的模式对服务进行。
RPC框架作为分布式跟踪系统的一个天然埋点,可以很好的进行一个数据输出。
服务治理(重点)
我这边列了常见的服务治理功能,例如:
服务路由:
- 权重:例如机器配置高的权重高,机器配置低的权重低
IP路由:例如某几台机器只能调某几台机器 - 分组路由:例如自动根据配置调某个分组
- 参数路由:例如根据方法名进行读写分类,或者根据参数走不同的节点
- 机房路由:例如只走同机房,或者同机房优先
- 权重:例如机器配置高的权重高,机器配置低的权重低
调用授权:
- 应用授权:只有授权后的应用才能调这组服务
- token:只有token对的调这组服务
- 黑白名单:只有名单允许的才能调这组服务
动态分组:
- 服务端切分组:可以根据分组的情况,对服务提供者进行一个动态的分组调度
- 客户端切分组:可以对调用者进行一个分组调度
调用限流:
- 服务端限流:服务端基于令牌桶或者漏桶模型进行限流
- 客户端限流:根据客户端的标识,进行调用次数限流
灰度部署:
- 灰度上线:先启动,验证后在提供服务
- 预发标识:表示该服务为预发布服务
- 接口测试:方便的提供接口自动化功能测试功能
配置下发:
- 服务配置
- 全局配置
服务降级:
- Mock:出现异常或者测试情况下,返回Mock数据
- 熔断:客户端超时或者服务端超时
- 拒绝服务:服务端压力大时,自动拒绝服务,保护自己
网关
RPC框架大部分场景都是自己调用的,什么时候会需要一个网关呢?
网关可以提供如下功能:
- 统一的鉴权服务
- 限流服务
- 协议转换:外部协议转统一内部协议
- Mock:服务测试,降级等
其它一些统一处理逻辑(例如请求解析,响应包装)
服务注册中心Plus
需要逻辑处理能力,例如对数据进行筛选过滤整合,计算服务路由等功能
同时还需要有与RPC框架交互的功能。
管理端Plus
管理端除了之前的简单服务管理功能外,还需要提供配置信息展示,监控信息展示,各种维度的数据展示。
也就是下面提到的服务治理功能,都可以在管理端进行管理。
另外,常见的服务治理功能,我们都可以作为开放服务供开发人员进行一个调用。
京东实践
第一代SAF背景
2012年初,京东从.NET转Java。各个部门,各个业务线都没有一个统一的服务化框架,有的是dubbo,有的是WebService,有的是Hessian等等。
同时各个业务系统自己有非常多的业务代码。通过统计接口规模在1K左右,服务节点在50K左右,机器规模在8K左右,机房比较少拓扑简单。
所以当时的愿景和目标比较明确:
- 京东系统服务化、API化的从无到有
- 统一京东的RPC调用框架
- 稳定可靠
- 提供简单的服务治理功能
第一代SAF选择
OK,结合我们的情况和上面的一些选型小结,我们当时的选择如下:
- RPC框架:基于dubbo2.3.2做配置扩展,以及功能扩展包括rest(resteasy)、webservice(cxf)、kryo/thrift序列化、调用压缩等
- 注册中心:Zookeeper,RPC框架直接接入数据源
- 监控中心:监控服务+HBase
- 管理平台:读取Zookeeper做管理平台,提供基本的上下线、黑白名单等功能
于2012年4月上线,最大规模时,接口数3K,接入最大IP数20K。
第二代JSF背景
随着京东业务的不断快速增长,接口、机器数也呈数量级增长。
同时京东成立子公司,在全国各地新建机房,部署结构也变得比较复杂。
加上SAF遗留的一些问题,大概面临如下几点:
- RPC框架较重,性能有提高的空间
- 注册中心无业务逻辑,直接对外暴露
- 京东复杂的部署架构需要更强大灵活的服务治理功能
- 监控数据不完整,维度不够
- 无应用依赖关系
- 跨语言调用需求
第二代JSF选择
所以在2014年初,我们进行了第二代JSF的一个全部自研过程。
我们主要做了如下技术选型:(全部自研)
- RPC框架:轻量级,更佳的性能,兼容旧版本协议
- 注册中心:基于DB作为数据源,前置Index服务;支持十倍接入量;部分逻辑放在注册中心减少客户端负担
- 监控中心:监控Proxy服务+InfluxDB(2015后改为ElasticSearch)
- 管理端:基于DB,功能更强大,提供完善的服务治理管理功能;打通京东应用管理平台,提供应用依赖关系梳理;
- HTTP网关:基于Netty,支持跨语言调用
开发周期:7人/年(2014.1-2015.1)。包括开发、测试、预发、上线、推广。
JSF架构简图
JSF注册中心
京东的注册中心是自研的,基于DB做的数据最终一致,也就是上面说的AP系统。
注册中心主要实现的就是服务列表的注册订阅推送,服务配置的获取下发,服务状态的实时查看等功能。
注册中心节点是无状态的,可水平扩展的。整个注册中心集群下的所有注册中心几点都是等价的。
每个机房部署多个注册中心节点。同机房的RPC框架会优先连本机房的注册中心节点。
主要亮点如下:
引入Index服务概念
- 该服务就是一个最简单HTTP的服务,用于找注册中心节点(同机房或者压力最小或者其它特定场景),可以认为是不会挂的服务,
- RPC框架会优先连该服务拿注册中心地址,这样子的好处是注册中心地址变化后,RPC框架不用修改任何设置。
注册中心内存有服务列表全量缓存,连不上数据库也保证可读
数据库的数据结构更适合各种维度展示、过滤、分析等
- 例如根据分组,IP,应用,机房等不同维度
- 注册中心就是个JSF服务,监控到压力大即可进行动态水平扩展
- dogfooding,注册中心其实是第一个JSF接口
- 服务列表推送逻辑改进
- 例如原来100个Provider,现在加1个节点,之前的SAF是需要下发101个节点,自己判断加了哪个节点,进行长链接建立;
- 现在的改进是:修改为下发一个add事件,告知RPC框架加了1个节点,RPC框架进行长链接建立;
- 这样做大大减少了推送的数据量。
- 注册中心与RPC框架可各种交互
- 注册中心和RPC框架是长链接,而且JSF是支持Callback的,注册中心可以调用RPC框架进行服务列表变化之外的操作;
- 例如查看状态,查看配置,配置下发等。
JSF RPC框架
RPC框架作为服务化里面的最基本的组件,其实都大同小异,因为RPC调用都绕不开代理、网络、序列化这些操作。
JSF的RPC框架也类似,主要分为图中的几个模块,
下面大概列下一些功能特性:
- Config:Spring/API/Annotation
- Proxy: Javassist/JDK
- Invoker/Filter:内置+自定义,Filter可扩展
- Client:Failover(默认)/FailFast/TransportPinpoint/MultiClientProxy
- 调用方式:同步(默认)/异步并行/异步回调/Callback/泛化
- Loadbalance:Random(默认)/Roundrobin/ConsistentHash/ LocalPreference/LeastActiveCall
- 路由:参数路由,分组路由,(IP级别路由逻辑在注册中心做)
- 长连接维护:可用/死亡/亚健康
- 协议:JSF(默认)/SAF(dubbo)/HTTP/Telnet/HTTP2
- 第三方:REST/Webservice
- 序列化:MsgPack(默认)/Hessian/Json/Java/protobuf(c++)
- 压缩:Snappy/LZMA
- 网络:基于Netty4.0,长连接复用
- 线程模型:BOSS+WORKER+BIZ
- 容灾:本地文件
- 请求上下文:IP,参数,隐式传参
- 事件监听:响应事件,连接事件,状态事件
- 分布式跟踪支持:进行数据埋点
JSF管理平台
提供强大管理功能,包括服务管理,监控管理,注册中心管理等功能。
我们针对服务治理的功能,提供了很多API,可以授权给开发人员或者外部系统使用。
例如单元测试调用,限流配置/开关,动态分组,上下线等都提供了开放API。
JSF HTTP网关
网关是为了方便跨语言通过HTTP+JSON调用JSF服务,而不需要使用JSF的RPC框架。
特性如下:
基于Netty4.0实现HTTP网关,没有使用Servlet容器,轻量高效。
支持服务自动发现
- 一般的HTTP服务,外面为了解决单点问题,都会用域名+VIP等实现高可用,故障转移等;
- 现在网关同时原生接入了JSF的注册中心,知道了服务的提供者信息(JSF协议支持HTTP调用)。
- 服务提供者也不用关系扩容缩容导致服务的IP端口发生变化,网关会自动维护服务列表。
- 服务限流
- 针对方法级+应用进行授权,固定时间只能调用指定次数。
- 同一个方法也只能占用网关内的部分线程
- 结果统一包装
- 对异常等响应进行包装
JSF遇到京东弹性云
京东的JSF服务开发在京东弹性云的研发推广之前完成,自从京东弹性云落地以来,也遇到不少问题。
例如:
- 硬件指标:例如使用JDK获取的Docker的指标有些是物理机的,我们需要特殊处理
- 网络:结合京东的“胖”容器,每个容器其实有实际IP,对外提供服务
- 轻量:提高启动速度
- 开放服务:在容器销毁或者非优雅停机的情况下,提供API进行服务治理
JSF规模
- 接口数:万级
- 服务节点数:百万级
- 接入实例数:十万级
- 框架调用量:每天千亿级别
- 监控数据:每天120亿条数据,1.2T数据量
- HTTP网关:每天百亿级别
总结
- 没有最好,只有最适合!
意思就是不要人云亦云,盲目看大公司用什么,现在什么最新,或者什么性能最好。因为架构不是让你一下子设计出来使用一辈子,好的架构都是慢慢演化而来的。不同的架构会做出不同的技术选型。所以无论什么时候都要结合自己的现状以及未来几年的规划,来进行技术选型。
- It’s just the beginning!
服务化框架的选择只是开始,真正的变革是选择后,公司整体业务和开发的变革。这个大家有空可以看看康威定律。
编辑推荐:架构技术实践系列文章(部分):
- 章耿:服务化框架技术选型实践
- 赵琨:视频直播早期创业团队的技术架构与选型
- 卢誉声:分布式实时处理系统架构设计与机器学习实践
- 陈斌:架构师的必备素质和成长途径
- 林伟:高可用的大数据计算平台如何持续发布和演进
- 柳宗扬:蘑菇街直播实战技巧带你解决直播开发难题
- 胡骏:详解自动化运维平台的构建过程
- 黄日成:从UDP的连接性说起——告知你不为人知的UDP
- 林昊:阿里超大规模Docker化之路
- 罗金鹏:双11媒体大屏背后的数据技术与产品
- 袁岳峰:手机端创新体验——手把手教你搭建VR&AR架构
- 张铭:双11背后的网络自动化技术
- 王鹤:Vue.js 2.0源码解析之前端渲染篇
- 黄日成:从TCP三次握手说起–浅析TCP协议中的疑难杂症
- 厉心刚:JavaScript引擎分析
- 蓝邦珏:来看看机智的前端童鞋怎么防盗
- 陈志兴:让页面滑动流畅得飞起的新特性:Passive Event Listeners
- 唐聪:大规模排行榜系统实践及挑战
- 左明:半小时深刻理解React
- 王照辉:魅族自动化测试架构之路
- 翁宁龙:美团数据库运维自动化系统构建之路
- 何轼:美团外卖订单中心的演进
- 申政:唯品会多线程Redis设计与实现
- 阿刘:千万级用户的Android客户端是如何养成的
- 卜赫:大道至简——React Native在直播应用中的实践
- 陈爱珍:从运维的角度看微服务和容器
- 孙其瑞:VR应用在直播领域上的实践与探索
- 刘丁:bilibili高并发实时弹幕系统的实战之路
- 秦鹏:从应用到平台,云服务架构的演进过程
- 郭炜:从0到N建立高性价比的大数据平台
- 李智慧:宅米网技术变迁——初创互联网公司的技术发展之路
- 陶文质:分布式系统设计的求生之路
- 魏晓军:React Native实践之携程Moles框架
- 学霸君姜波:耳目一新的在线答疑服务背后的核心技术
- 爱乐奇麦凯臻:在线教育的内容研发和技术的迭代创新
- 长虹李玮:老牌消费电子企业如何拥抱Docker
- 徐汉彬:日请求过亿的Web系统PHP7升级实践
- 窦威:AcFun的视频架构演化实践
- 傅鸿城:QQ亿级日活跃业务后台核心技术揭秘
- 宁峰峰:尖峰日96万订单,59校园狂欢节技术架构剖析
- 梁阳鹤:每秒处理10万订单乐视集团支付架构
- 沈辉煌:亿级日PV的魅族云同步的核心协议与架构实践
- 李任:携程Docker最佳实践
- 王海军:游戏研发与运营环境Docker化
- 史海峰:当当网高可用架构之道
- 黄哲铿:应对电商大促峰值的九个方法
- 1号店交易系统架构如何向「高并发高可用」演进
- 京东闫国旗:从C10K到C10M高性能网络的探索与实践
- 李林锋:服务化架构的演进与实践
- 1号店架构师王富平:一号店用户画像系统实践
- 唯品会官华:实现电商平台从业务到架构的治理体系
- 沈剑:58同城数据库架构最佳实践
- 荔枝FM架构师刘耀华:异地多活IDC机房架构
- UPYUN的云CDN技术架构演进之路
- 初页CTO丁乐:分布式以后还能敏捷吗?
- 陈科:河狸家运维系统监控系统的实现方案
- 途牛谭俊青:多数据中心状态同步&两地三中心的理论
- 云运维的启示与架构设计
- 魅族多机房部署方案
- 艺龙十万级服务器监控系统开发的架构和心得
- 京东商品详情页应对“双11”大流量的技术实践
- 架构师于小波:魅族实时消息推送架构
服务化框架技术选型实践相关推荐
- 【转】服务化框架技术选型与京东JSF解密
声明:本文转载自微信公众号"开涛的博客",转载务必声明. 作者:章耿,原京东资深架构师,曾负责京东服务框架,配置中心等基础平台.近十年工作经验,专注于基础中间件等底层技术架构,对分 ...
- 务化框架技术选型与京东JSF解密
作者:章耿,原京东资深架构师,曾负责京东服务框架,配置中心等基础平台.近十年工作经验,专注于基础中间件等底层技术架构,对分布式系统/服务化/DevOps建设有一定经验. |前言 首先本文不讨论为什么要 ...
- 专注于业务编排的工作流引擎Temporal框架技术Java实践(SpringBoot)
目录 Temporal 业务系统结构 心跳以及重试机制 长耗时复杂业务工作流设计 场景 选项1 选项 2 选项 3 Activity持久化问题 写在最后 Temporal Temporal 是一个微服 ...
- 【译】前端框架技术选型 React vs. Vue (vs. Angular)
这是该系列文章的第2部分:"Fundbox的前端技术选型".第1部分介绍了Fundbox的技术现状以及我们重新设计它的动机.第2部分介绍了选择新框架背后的考虑:是迁移到React, ...
- 轻量级 Java Web 框架技术选型
2019独角兽企业重金招聘Python工程师标准>>> 本文是<轻量级 Java Web 框架架构设计>的系列博文. 前面已对该 Java Web 框架做了一些简要描述, ...
- 三大前端框架技术选型对比
1.ReactJS简介 React 起源于 Facebook 的内部项目就在2013年5月开源了. 由于 React 的设计思想极其独特,属于革命性创新,性能出众,代码逻辑却非常简单.所以,越来越多的 ...
- 技术选型都做不好,难怪自动化做得这么费力...
01.自动化测试框架 在学习自动化测试或者实践自动化测试时,我们一定会对一个名词不陌生,那就是"自动化测试框架". 而有些人也将 Selenium.Appium 这样的工具也称之为 ...
- 你真的会自动化测试?自动化测试技术选型抉择
自动化测试框架 在学习自动化测试或者实践自动化测试时,我们一定会对一个名词不陌生,那就是"自动化测试框架",而有些人也将Selenium.Appium这样的工具也称之为" ...
- .net开源框架简介和通用技术选型建议
.net体系 .net core .net 类库 asp.net mvc asp.net webapi asp.net core EF 跨平台和运行时解决方案(解决方案) Katana:微软基于OWI ...
最新文章
- 因热爱而编码,创造至美生活,挑战高效工作 阿里云智能开发者创新应用大赛全记录...
- 后端数据操作超时_数据分析在知乎商业质量保障中的初步实践
- Marketing Cloud里使用了哪个版本的UI5 Odata模型?
- 微课与计算机技术的论文,微课在高校计算机教学的运用论文
- 关于直播学习笔记-005-nginx-rtmp-win32在Win10上使用
- android 控件宽度自适应_Android中让图片自适应控件的大小的方法
- (50)VHDL实现增减计数器
- 虚拟服务器设置 - 百度,百度云虚拟主机BCH配置伪静态图文教学
- python读取dicom序列_python读取dicom图像(SimpleITK和dicom包实现)
- 内核sk_buff工作线程总结
- Android投屏,屏幕共享,两个设备互相投屏
- Python-Selenium自动化登陆QQ空间
- scrapy抓取贝壳找房租房数据
- android隐藏虚拟按键的几种方式
- vlookup函数和vlookup函数与数据有效性
- Springboot框架整合Mybatis-plus实战动态SQL以及常见的Mybatis面试题
- jwt token使用autho0-jwt框架使用(二)
- 就是用计算机判断一个句子的语义,英语汉语词汇语义及句子结构对比
- 电子计算机的四个名称,文件夹,文件夹名称唯美四个
- JS基础 -- 大复习(阶段六:对象和内置对象及预解析)
热门文章
- re.findall函数和enumerate函数实现罗马数字转化为整数的方法比较
- python中使用gdal,osgeo
- 128*64点阵图形液晶显示屏程序设计教程
- 在计算机的应用领域 cat的中文全称,计算机基础知识题库.xls
- armneon Intrinsics记录
- 吐血整理阿里云安装MySQL8.0及远程连接失败问题
- 随手记_英语_留学生千万不能犯的Email Communication的禁忌
- 用matlab画OCC控制电路,基于单周期控制的Boost型APFC电路设计及仿真
- 耀之阳电商:店铺DSR为零怎么办
- 【转载】玉伯三年前的某天随笔