阿里中间件技术交流

发展历程

• {服务框架与业务程序隔离，直接与web容器集成}
• 淘宝使用的是自己优化过的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
  • 服务框架：
    • 流控：单节点，如果超过直接拒绝，{fail over由客户端负责}
    • 负载均衡
      • 在客户端做一般用算法实现，进行随机访问
      • 也支持根据资源情况分配，但是不建议，带来了复杂性
    • 支持3种调用方式
      • 同步
      • future
      • 异步回调
    • 关注：
      • rpc是基础
        • 协议的兼容性和标准化
        • 跨语言支持
      • 软负载和服务管理是核心
        • 路由
        • 权重
        • 归组
        • 本机房和流控
        • 服务治理中心
      • 无缝集成是关键
        • {隔离}
          • Dubbo没有做到
        • 升级
  • HSF2.0
    • 兼容了HSF1.0，Dubbo的不同版本,使用方式和功能适配
    • 实现互联互通
      • 客户端如何知道服务端支持何种协议，config server上声明
      • 服务端如何知道客户端发来何种协议，消息头
    • 现状
    • 大部分时间在答疑
    • 其次推动升级
    • 最后是开发测试
  • 面向运营，服务治理
    • 权重规则
      • {引入线上流量压测：B2B应用在线上压测时导入流量}
      • 动态归组
        • 同套代码提供不同的服务，实现集群的隔离，保障关键应用
        • 这里也表明了，客户端需要自表明自己
      • 全局规则
        • 调整日志采样：双11可以关闭
        • HSF日志：双11可以改下级别至warn之类的，本地日志

与淘宝服务框架架构师交流

• HSF建的是长连接，定期会清理
• 服务发布时会配置默认分组，动态修改分组的时候会写文件
• 服务节点的监控，提供者会通过流量来看【某台服务器上没有流量】，然后通知config server下掉该节点
• 版本号和组件（模块）关系的，服务框架不关心，可能业务团队会关注，也就没进一步问版本号依赖管理的内容（参照osgi的依赖管理）