• 1. 淘宝服务框架(HSF)介绍毕玄 2010-03-08
  • 2. HSF介绍起源 做了些什么以及怎么做的 目前的使用状况 将来还会做什么 和eBay SOA平台的比较
  • 3. 起源07年的淘宝依靠Denali这座唯一的大山支撑着; 仅仅靠堆积机器已经无法支撑了; 于是祭起了“拆分”这个互联网常用招数; 应用拆开后,如何通讯?性能如何保证?如何保证不管是什么应用都用同样的方式交互? 于是,HSF(High-speed Service Framework)诞生了!
  • 4. 做了些什么以及怎么做的标准Service方式的RPC 应用之间以Service的方式进行交互 交互方式支持同步、异步、可靠异步以及回调 协议支持tcp/ip、webservice 序列化支持java、hessian 这就是一个Service了 com.taobao.hsf.test.provider.WebHSFService 1.0.0
  • 5. 做了些什么以及怎么做的标准Service方式的RPC---怎么做的 Service定义,参考了OSGi 协议 TCP/IP(这个部分的实现也就是TBRemoting了) NIO,基于Mina 每目标地址一个连接、长连接 实现同步、异步发送对象;回调;按连接组发送对象等; server端限定大小的线程池,正在尝试coroutine方式 … Webservice 基于Axis,支付宝做了一定的优化 序列化 集成的hessian 3.0.13
  • 6. 做了些什么以及怎么做的完善的软件负载体系 软件负载均衡 随机 权重 com.taobao.tc.*=172.23.12.*:80; 172.23.13.*:20 Failover 应用层路由(支持按服务的接口、方法、参数路由) 已应用于淘宝的店铺读写服务分离、商品中心的服务分级(按接口)以及交易中心的功能分离(按方法) 最大的特色:不增加中间点(F5、Netsclar、LVS都需要增加中间点),保障了稳定性和高度可伸缩
  • 7. 做了些什么以及怎么做的完善的负载均衡体系---怎么做的 增加了ConfigServer 实现服务地址信息的注册、服务消费者信息的注册和服务地址信息的推送,从而做到无需中间点,调用时直接调用; 实现了感应服务提供者的状态,当服务提供者断开时重新推送目标地址,从而做到failover; 选址 权重为推送一个地址的权重规则; 应用层路由 通过推送路由规则(groovy代码)到调用端,调用端根据此路由规则计算调用服务的方法时可选择的地址列表。
  • 8. 做了些什么以及怎么做的模块化、动态化 支持HSF的动态部署 隔离了HSF和应用的包,避免包冲突
  • 9. 做了些什么以及怎么做的模块化、动态化---怎么做的 基于OSGi 遵循Equinox的实现更好的设计系统,以降低动态化实现的成本 接口和domain对象放入一个独立bundle 所依赖的lib也放入独立的bundle 接口的实现分离为多个bundle,这些bundle都保持不export-package,交互基于OSGi Service的方式进行
  • 10. 做了些什么以及怎么做的服务治理 服务信息管理 服务提供者或调用者信息的查询 服务依赖关系分析 服务运行状况 服务可用性保障 服务路由调整 服务流量分配 服务端降级 调用端降级
  • 11. 做了些什么以及怎么做的服务治理---怎么做的 基于注册到ConfigServer的服务信息 基于埋点到哈勃的运行状况信息 基于故障的定义(例如响应时间超过某个阀值、可调用的服务的机器数小于约定值等) 基于应用层路由
  • 12. 做了些什么以及怎么做的以上做的这些事情经历了很多个版本的发展V 1.12008年5月流量:100万+基本RPC功能,基于JBoss-Remoting,一个简单的服务注册中心V 1.22008年8月流量:3亿+通信切换为Mina,推出configserverV 1.2.52008年9月流量:4亿+软负载V 1.32009年1月流量:40亿+抽象形成TBRemoting、ConfigServer两个通用产品;多种调用方式V 1.3.32009年1月流量:45亿+支持HSF服务发布为TOP方式V 1.42009年6月流量:80亿+迁移为OSGi结构,服务治理V 1.4.32009年9月流量:100亿+应用层路由完整支持,ConfigServer集群V 1.52009年12月权重选址、webservice RPC、动态化增强V 1.62010年4月分布式事务
  • 13. 目前的使用状况几乎部署在淘宝所有的java系统中 软负载机制已衍生的用于淘宝后端的各种系统中,例如类目推送server、前端系统和搜索引擎的交互等 每天的服务请求量在100亿+ 和支付宝合作开发,ConfigServer已部署在支付宝,SOFA 2.0将集成HSF 阿里金融项目中也在“被迫“使用
  • 14. 将来还会做什么?功能的继续完善,今年走入稳态 分布式事务、Http RPC、辅助查错系统 跨语言的版本,支持C/C++ 服务调用全过程跟踪的支持 性能的继续优化,通信、序列化/分序列化 Netty、Protocol Buffers
  • 15. 将来还会做什么?衍生发展 淘宝应用服务器(land),用于替换jboss、tomcat 淘宝应用管理系统(APPOPS) 应用的依赖关系 故障的发现及故障根源的提示 故障的处理措施:流量分配、路由调整、功能降级、资源劣化等 故障的自愈 应用的自动化部署系统 应用公用包管理系统 根据应用QoS实现机器的动态分配
  • 16. (本页无文本内容)