阿里中间件技术交流
发展历程
- 淘宝使用的是自己优化过的tomcat,淘宝会进一步把所有主要的公用行组件都放进去,如:notify客户端,TDDL,etc,公用组件和业务发布是分离的
-
- 08年做过一次停止所有业务开发,梳理业务逻辑,梳理定义服务
- 硬件中转问题:所有请求都从F5走,F5价格高,作为单点性能有瓶颈
- 采用直连方式,服务发现:
- 所有机器ip列表放在公共机器上。
- 风险:name server对带宽、性能要求较高
- HSF(High Speed FrameWork)
- 人【调用者】.开()【调用】.灯【提供者】
- 调用使用的封装协议,序列化_要自描述_
- java
- hession【目前默认,认为效率也低】【版本不兼容,演进比较差】
- protocol【非自描述,需要增加配置定义,所以没有采用】
- 接口协议描述
- 使用java interface【淘宝使用】
- 没有采用wsdl等
- 问题:
- 网关类系统:如TOP平台,对外开放API,会遇到问题,需要提供更通用的接口框架,做了适配
- 淘宝将服务框架进行整合,整合Dubbo和HSF
- 13年qcon,淘宝分享了“鹰眼”,管理服务调用情况,包括自动生成依赖关系
- 靠消息实现的分布式事务情况下,可能会有用到event driven
- 服务框架:
- 流控:单节点,如果超过直接拒绝,
- 负载均衡
- 在客户端做一般用算法实现,进行随机访问
- 也支持根据资源情况分配,但是不建议,带来了复杂性
- 支持3种调用方式
- 关注:
- rpc是基础
- 软负载和服务管理是核心
- 无缝集成是关键
- HSF2.0
- 兼容了HSF1.0,Dubbo的不同版本,使用方式和功能适配
- 实现互联互通
- 客户端如何知道服务端支持何种协议,config server上声明
- 服务端如何知道客户端发来何种协议,消息头
- 现状
- 面向运营,服务治理
- 权重规则
- 动态归组
- 同套代码提供不同的服务,实现集群的隔离,保障关键应用
- 这里也表明了,客户端需要自表明自己
- 全局规则
- 调整日志采样:双11可以关闭
- HSF日志:双11可以改下级别至warn之类的,本地日志
与淘宝服务框架架构师交流
- HSF建的是长连接,定期会清理
- 服务发布时会配置默认分组,动态修改分组的时候会写文件
- 服务节点的监控,提供者会通过流量来看【某台服务器上没有流量】,然后通知config server下掉该节点
- 版本号和组件(模块)关系的,服务框架不关心,可能业务团队会关注,也就没进一步问版本号依赖管理的内容(参照osgi的依赖管理)
posted @
2014-05-20 12:32
fallingriver
阅读(
813)
评论()
编辑
收藏
举报