Pebble框架系统架构分析

背景介绍

目前途牛各个研发团队基本在使用 Spring 构建项目,服务调用采用 TSP(tuniu service platform),工程骨架、功能组件缺乏统一维护和收敛,各研发团队核能会重复造轮子。无接口定义管理,服务治理功能有限,不能满足日益增长的业务形态需求。Pebble(铺路石)对研发人员提供一种全新的服务提供与消费方案,并提供前期接口定义和文档生成、中期开发和测试、后期线上治理与监控等一整套的解决方案。主要有如下几方面:

架构分析

利益相关者

领域模型

1、提炼出的关键概念:服务(区别于TSP服务)、Pebble注册中心、Pebble客户端、服务注册、消费注册、提供者、消费者、Pebble管理中心、服务动态治理等,无交叉职责。

a.服务定义

研发在设计初期确定系统间的交互接口,使用统一的IDL语法来编写,规范描述方式。

使用统一的工具完成IDL到具体语言的代码转换。

Java侧使用maven来管理接口定义的jar包版本;收口了管理,同时jar包就是文档,从根本上解决了文档不能及时更新的问题

b.服务治理

服务的提供方实现服务接口,由框架来完成自动服务暴露和注册发现,并提供丰富的服务治理手段。

server端服务并发控制、服务限流;client端负载均衡、熔断、服务降级等。

提供客户端配置项和web控制台两种干预方式。 服务的启停、注册、暴露等的时机保证服务的稳定可靠。

c.权限管理

服务实例的归属关联明确的系统标示(系统码+模块码),负责人和owner明确。

权限管控不独立维护,依赖tardis统一管理。

d.服务监控

分为调用方视角和服务方视角。

调用端收集实际发生的调用log并做收集、分析、呈现。

服务方度量提供的服务的实际情况,并近实时呈现到web控制台。

e.测试支撑

mock测试桩维护,用例管理,解耦自测依赖,自动化测试过程。

从根本上解决测试环节中环境繁杂,数据维护效率低下等问题。 为持续集成提供可能性。

2、Pebble客户端、Pebble注册中心、Pebble管理中心三者配合完成整个研发运维的生命周期

交互逻辑

1、提供者、消费者、Pebble注册中心,最小的三角调用关系,也是最小的强依赖。Pebble注册中心挂掉时,提供者和消费者也能以原有状态继续发生业务服务调用。

2、Pebble内部进行了详细的模块和功能抽象划分,具有较细的层次,且支持插件化开发。易演进和扩展。

接口设计

1、无对外接口

2、对内接口,前后端交互。接口明确,功能内聚。

数据架构

Pebble中无需数据库。其他内部数据包含方面的数据:RPC调用过程中的header结构、调用日志数据结构、提供者配置数据结构、消费者配置数据结构、注册中心中的树结构、接口定义目录数据

1、header结构有保留字段和扩展字段,注册中心的树结构存在扩展节点

2、注册中心树结构考虑的治理模型、数据通知量、网络断线重连等场景,压缩通知模型

3、注册中心的数据需要鉴权访问,非持久化数据无需备份

4、接口文档目录数据存储于ES,集成复杂功能搜索和备份方案一体

5、原始日志数据量按预期TSP规模,每天10亿条,占用存储200G, 放弃原先TSP的存储方案,存储错误的原始调用日志和经过计算合并的分钟级监控指标数据,数据体量下降2个数量级。

技术架构

采用的技术组件主要包括如下:Java、Spring、Thrift、Maven、JavaScript、Vue、Redis、Zookeeper

组件模块之间无强依赖,无环状依赖,自底向上的依赖如下:

1、组件特性合理使用,尤其zookeeper,控制连接数和通知量

2、代码模块区分细致,pebble项目代码分块大致40个块,至少两级抽象,支持各级扩展

3、解耦各个模块,将来整个开发框架可复用

4、缓存数据是可丢失的,缓存服务是必须存在的

5、对比TSP,取舍一些功能,数值类型只支持数值类型而非对象类型,编码习惯有改变;强行限制异常不允许用null给出结果,必须用对应的对象语义或异常语义来标识

部署架构

1、采用docker部署,父镜像根据公司统一tomcat镜像定制扩展组件形成镜像,支持mvn git svn thrift等组件操作。

2、Pebble管理中心、Pebble监控服务、Pebble日志收集服务均采用docker部署,多实例。

3、Pebble管理中心需要较多资源,随前端用户使用接口发布量而变化,资源有所倾斜,并通过并发控制。

4、测试环境不提供全部功能,生产环境也不提供全部功能。如接口发布只在生产环境提供,测试功能只在测试环境提供。

5、灾备恢复机制只需恢复zookeeper集群。zookeeper集群已经在不同机柜部署5个节点,抗灾能力有保障。恢复过程只需重启实例。就算部分数据没有,也不影响。

6、模块低耦合,不存在一些上线顺序或刷数据的场景。

7、zookeeper组件对网络有需求,实际使用量随着接入数量而定。具体服务数、订阅数、网络流量的关系无压测数据支撑。实际200个服务,每个服务消费10个服务,网络流量已控制在500K/S以内。

功能波及

Pebble服务框架是全新的系统建设,无功能波及。唯一的影响面是提供客户端给别人使用,可能会带来兼容性问题。做了如下举措:

1、提供了相对详尽的文档

2、提供了兼容性检查的自动插件

性能

性能方面,进行了如下工作:

1、提供者和消费者,单点服务压测,报文大小1kb,压测到35000QPS时,系统负载40%(24核)。详见压测报告。

2、系统无慢查风险,客户端无并发争抢资源。

3、客户端消费服务时,需要较高的数据一致性,必须能实时知道服务端节点下线。

在极端情况下(未覆盖测试),网络成为瓶颈,可能会导致通知到达延迟,

此时服务端下线,客户端可能延迟感知到消费者退出而发生调用错误(使用高阶的集群策略可保障服务可用)

4、经测试,Pebble管理中心在接口发布时,占用资源比较高,已通过并发限制控制。

可靠性

Pebble服务框架提供的一系列服务,均无单点,提供如下标准可靠性

发布与构建通过版本控制,可以自由重复测试、发布、回滚,数据无兼容性问题。

扩展性

Pebble提供了非常丰富的功能扩展性

1、抽象功能的插件化扩展,包括:filter、router、registry、cluster、loadbalance等完成路由、限流、熔断、集群策略等高阶自定义功能。

2、插件的选择采用level id控制启用覆盖关系;

3、最主要的注册中心都是可以从zookeeper扩展到其他选型的。

维护性

除了提供客户端之外,Pebble管理中心提供了的主要治理功能,用户可以来方便的治理服务

1、服务的启用停用

2、热缓冲时间

3、禁用启用节点

4、配置路由策略和鉴权等

5、配置限流策略等

如下图:

还可以比较方便的获取服务实时的运行情况:

1、服务数、被依赖数、提供者数

2、流量、失败率、错误种类

3、客户端或服务端的流量折线图、失败饼图

如下图:

监控与日志

Pebble服务框架为大家提供各种监控功能的同时,本身自己的服务也在监控范围内。

P0级别的组件服务zookeeper,通过zabbix和falcon监控机器集群和进程各参数状态,并提供及时的告警。

具体zookeeper被监控的指标有

Pebble服务队用户提供了较多的监控视图,目前尚缺告警机制。

Pebble客户端有详细的异常错误栈打印。Pebble调用日志,能具体到时间、节点等

安全

1、Pebble客户端不存在敏感资源的使用,服务治理功能为使用者提供了一种系统鉴权准入的安全机制。

2、Pebble内部功能上的鉴权,通过tardis上的系统及角色来控制,无冒用权限接入的风险,保证用户能正确的使用功能。

3、 Pebble管理中心涉及内网用户登录,采用密文加密传输,接入CAS鉴权,通过后应用内session保持回话。

总结

综合Pebble项目当时的实践过程,及一段时间内的演化过程,对比最初的目标,尚存在一些待优化的地方:

1、对服务提供者和消费者提供消费失败或消费质量下降的预警机制

2、对注册中心的压力进行更极端的压力测试,及极端情况下注册中心本身的脑裂缺陷提供应对策略。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181105G1RFAU00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券