《美团大众点评微服务实践——服务框架 Pigeon 的设计与实现》

微风

2019/03/24 发布于 技术 分类

文字内容
1. 美团大众点评微服务实践 -服务框架Pigeon的设计与实现 吴湘@美团大众点评,基础架构中心
3. 大纲 • 服务框架Pigeon的设计与实现 • 服务治理 • 微服务的一些实践经验
4. 服务框架Pigeon架构 • Pigeon提供jar包接入,线上运行在tomcat里 • Monitor-CAT,负责调用链路分析、异常监控告警等 • 配置中心-Lion,负责一些开关配置读取 • Governor-服务治理门户 • 一个interface定义为一个服务,每个服务有一个唯一标识 Pigeon Governor Registry (zookeeper) Service (Invoker) Config Server(Lion) Service (Provider) Monitor(CAT)
5. 主要模块 服务治理门户 服务搜索 服务自助注册 服务治理分析 服务流控 服务降级 服务测试 运营报表 接口文档中心 服务发现 服务调用 服务隔离 服务注册注销 监控分析 服务限流 服务心跳/重连 服务单机测试 服务降级 负载均衡 序列化 服务容错 客户端
6. 服务的注册与发现 • 注册信息包括service name、ip、port、group等 • 服务提供方初始化完成后自动注册,也可以通过api或管理端注 册 • 服务调用方通过service name去发现服务 Registry(Zookeeper) /DP/SERVER/com.dianping.iphub.IpService 10.66.1.1:5020,10.66.1.2:5020
7. 服务的注销 • 服务地址通过zookeeper持久节点存储,避免临时节点的不稳定 • 关闭tomcat时会调用pigeon脚本去注册中心摘除本机服务地址 • 对于残留的无效地址,有独立的心跳服务会检测无效的服务地址 进行zookeeper删除 • 客户端对于无效的服务地址,内部也有心跳检测机制等来保证 Registry(Zookeeper) unregister register/unregister Invoker heartbeat Provider Heartbeat Service heartbeat
8. 编程方式、序列化 • 基于Hessian序列化,通过netty实现自定义TCP协议格式,开发 成本低,通过java interface定义服务接口 • 基于Thrift序列化,通过netty实现自定义TCP协议格式,性能更 高,开发成本稍高,通过定义IDL或annotation方式定义服务接 口,更方便接入其他语言,thrift会有一些限制如方法不支持重 载、struct不支持继承等
9. 调用模式 • Sync,同步等待返回调用 • Future,可实现并行发出多个请求,总耗时是最慢的请求的执行 时长,推荐方式 • Callback,发出结果不等待返回,结果回调,完全异步化 • Oneway,无需返回结果
10. 客户端心跳 • 心跳线程客户端发起,定期发送,服务端响应,连续5次不成功 则在本地路由缓存里摘除该服务端节点,摘除后下次尝试重连 Provider Invoker Load balancer Pick up Heartbeat listener Provider Pick off Provider
11. 客户端负载均衡 • 多种负载均衡策略,默认是自适应策略,客户端会计算发往每个 服务端节点的在途请求数,新的请求会优先选择在途请求数最小 的节点发送 • 预热控制,针对服务端某个刚启动的节点,客户端按从慢到快的 频率,将请求逐步发往这个节点,防止服务端刚启动的节点大量 请求进来导致大量超时 • 也可自定义负载均衡策略
12. 服务限流 • 可以在服务端对某一个服务接口的某一个方法,针对不同的调用 方应用的请求进行流量QPS限制,超出阀值后调用端会收到服务 拒绝异常,未来会在调用端进行限流 • 服务端会对任意接口的请求所占用的线程数进行控制,防止单个 接口某个方法用尽线程池所有可用线程
13. 服务隔离 • 服务端默认会监控每个接口的超时情况,超时多的接口请求会自 动路由到独立的慢线程池处理,如果该接口恢复正常,则会回到 正常共享线程池处理 • 也可以为某些接口方法配置独立的线程池,剩余的使用公共池 Timeout checker request Thread scheduler Slow method Custom method Shared pool Custom pool Slow pool
14. 服务降级 • 若依赖的服务可以降级处理,Pigeon提供多种服务自动降级策 略 • 降级的结果可以是自动返回默认值(支持json和groovy配置)、 或抛出降级异常、或返回mock对象
15. 多IDC支持 • 一个地域多个IDC,优先调用同地域的服务,也可配置优先调用 同IDC的服务,同地域不同IDC可配比例
16. 内置HTTP服务 • 内置4080端口的http服务,可以查看单机实时信息如QPS、注 册状态、调用和被调实时状态、内部线程池状态等 • 通过http+(json/hessian)可以被其他应用通过GET或POST 调用,未来会提供更好的REST服务 • 单机服务测试
17. 服务测试 • 内置http服务,提供ip:4080/services服务测试页面,也可以通 过管理端统一入口进行测试
18. 服务监控分析与告警 • 通过监控系统CAT(已开源)分析调用链路,包括调用量、TP耗 时、异常、请求及响应大小、区间耗时明细、QPS等
19. 服务监控分析与告警
20. 服务治理 • 服务可用性、耗时(平均、TP99等)排行运营日报 • 调用深度过长(>4)统计 • 出度,入度过大的服务、过大的服务统计 • 过长的超时时间统计 • 检测循环调用的风险 • 检测可能可以并行调用的服务 • 梳理核心服务性能冗余度,基础底层服务建议采用全异步化等手 段提高吞吐
21. 微服务的一些实践-基础设施标准化 • 标准化运行环境,如无特殊情况,线上业务的虚拟机KVM或 docker配置一样 • 标准化运行容器如Tomcat • 标准化环境标识,如每台机器固定路径的appenv文件, env=production,文件内容标识机器属于什么环境如线上环境、 测试环境 • 标准化应用名称规范,每个应用有一个唯一的名称,如war包下 放置一个app.properties,app.name=xxx-xxx-service
22. 微服务的一些实践-基础设施标准化 • 统一的开发语言 • 标准化发布工具,如可以实现统一war包发布、jar包版本升级限 制 • 统一的服务通信框架 • 统一的配置中心 • 统一的数据库、KV等存储访问层 • 统一的MQ • 统一的监控系统
23. 微服务的一些实践 • 底层存储如mysql、KV等尽量保证只有一个或少数几个服务访 问,每个应用只能访问自己的存储 • 面向业务领域定义服务(interface),每个服务高内聚,一个 应用可能多个服务 • 按业务产品线规划应用,理解业务本质,根据业务发展情况进行 服务的拆分或重构 • 组织结构按业务产品线划分,做好微服务需组织结构支持
24. Q/A
25. 开源地址及联系方式 • pigeon开源地址:https://github.com/dianping/pigeon • 个人联系方式:微信wux_china