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、对注册中心的压力进行更极端的压力测试，及极端情况下注册中心本身的脑裂缺陷提供应对策略。