分布式基础架构组件

一、流量统计平台

组件介绍

流量统计平台

说明

意指能够开发一套完整替代三方数据平台（如友盟，GrowingIO）的数据流量分析平台，为使用者提供从接入到数据查看，再到数据分析全套统计分析平台。
同时为各个业务方快速便捷的提供基于流量数据的特异性需求的扩展功能

期望特性

功能列表:

• Web站点分析：
• 提供统一的流量，耗时，来源统计，地域分布统计等内置分析。（PV、UV、IP数、平均打开耗时）
• 定制监控：
• 免埋点，无需开发介入，填入 URL 立等即可查看实时统计数据。

二、分布式任务调度中心

分布式调度在互联网企业中占据着十分重要的作用，尤其是电子商务领域，由于存在数据量大、高并发的特点，对数据处理的要求较高，既要保证高效性，也要保证准确性和安全性，相对比较耗时的业务逻辑往往会从中剥离开来进行异步处理。

开源对比

• XXL-JOB 是一个轻量级分布式任务调度框架，支持通过 Web 页面对任务进行 CRUD 操作，支持动态修改任务状态、暂停/恢复任务，以及终止运行中任务，支持在线配置调度任务入参和在线查看调度结果。

• Elastic-Job 是一个分布式调度解决方案，由两个相互独立的子项目 Elastic-Job-Lite 和 Elastic-Job-Cloud 组成。

• opencron 是一个功能完善且通用的开源定时任务调度系统，拥有先进可靠的自动化任务管理调度功能，提供可操作的 web 图形化管理满足多种场景下各种复杂的定时任务调度，同时集成了 linux 实时监控、webssh 等功能特性。

• LTS、Uncode-Schedule、Antares 等

三、分布式异步任务调度中间件

使用场景:

• 普通异步任务：适用于将长耗时任务异步化。
• 延时回调任务：适用于需要定时回调的任务。（eg: 交易场景定时关单）
• 执行依赖任务：适用于互相之间有依赖关系的任务。（eg：支付平台处理有依赖关系的回调）

期望特性

• 消息持久化, 任务分布式执行:
• 执行资源的分配: 每台机器配置任务执行程数, 机器只有存在空闲线程时才会去Redis里获取任务
• 任务执行顺序: 先进先出
• 高性能，高并发（基于Redis）
• 业务隔离，独立部署（应用之间无公共依赖）
• 开发运维流程简单（无需像MQ一样事先注册Topic）
• 编程模型简单: 像调用本地方法一样调用异步任务
• 提供Web控制台: 查看任务执行情况
• 功能丰富: 提供任务重试功能, 支持延时任务和任务依赖
• 服务保障: 任务执行失败/超时的告警

四、全链路跟踪

全链路监控是分布式框架的核心模块，采用开源项目很难达到结合项目特性来进行各维度的大数据分析、系统监控、系统告警等功能。最好能结合开源项目进行相应的改造、或者按照项目特点重新规划全链路监控组件

全链路监控平台功能点

1. 收集各应用链路数据，实现链路监控
2. 链路数据海量存储
3. 链路信息秒级查询响应
4. 链路自动报警，支持报警配置

同类产品调研

Zipkin，Pinpoint，SkyWalking，CAT

• zipkin
  Zipkin是Twitter开源的调用链分析工具，目前基于springcloud sleuth得到了广泛的使用，特点是轻量，使用部署简单。
• pinpoint
  Pinpoint是韩国人开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能强大，接入端无代码侵入。
• skywalking
  类似于pinpoint 基于opentracing
• CAT
  大众点评开源的基于编码和配置的调用链分析，应用监控分析，日志采集，监控报警等一系列的监控平台工具

基本原理

类别	Zipkin	Pinpoint	SkyWalking	CAT
实现方式	拦截请求，发送（HTTP，mq）数据至zipkin服务	java探针，字节码增强	java探针，字节码增强	代码埋点（拦截器，注解，过滤器等）
类别	Zipkin	Pinpoint	SkyWalking	CAT

接入

类别	Zipkin	Pinpoint	SkyWalking	CAT
接入方式	基于linkerd或者sleuth方式，引入配置即可	javaagent字节码	javaagent字节码	代码侵入
agent到collector的协议	http,MQ	thrift	gRPC	http/tcp
OpenTracing	√	×	√	×

分析

类别	Zipkin	Pinpoint	SkyWalking	CAT
颗粒度	接口级	方法级	方法级	代码级
全局调用统计	×	√	√	√
traceid查询	√	×	√	×
报警	×	√	√	√
JVM监控	×	×	√	√

页面UI展示

类别	Zipkin	Pinpoint	SkyWalking	CAT
健壮度	**	*****	****	*****
类别	Zipkin	Pinpoint	SkyWalking	CAT
健壮度	**	*****	****	*****
类别	Zipkin	Pinpoint	SkyWalking	CAT
健壮度	**	*****	****	*****

数据存储

类别	Zipkin	Pinpoint	SkyWalking	CAT
数据存储	ES，mysql,Cassandra,内存	Hbase	ES，H2	mysql,hdfs
类别	Zipkin	Pinpoint	SkyWalking	CAT
数据存储	ES，mysql,Cassandra,内存	Hbase	ES，H2	mysql,hdfs
类别	Zipkin	Pinpoint	SkyWalking	CAT
数据存储	ES，mysql,Cassandra,内存	Hbase	ES，H2	mysql,hdfs

社区活跃度

类别	Zipkin	Pinpoint	SkyWalking	CAT
STAR		STAR		STAR
11.2k	11.2k	11.2k	11.2k	11.2k
8.9k	8.9k	8.9k	8.9k	8.9k
9.3k	9.3k	9.3k	9.3k	9.3k
9.7	9.7	9.7	9.7	9.7

性能分析
模拟了三种并发用户：500，750，1000。使用jmeter测试，每个线程发送30个请求，设置思考时间为10ms。使用的采样率为1，即100%，这边与生产可能有差别。pinpoint默认的采样率为20，即50%，通过设置agent的配置文件改为100%。zipkin默认也是1。组合起来，一共有12种。下面看下汇总表：

从上表可以看出，在三种链路监控组件中，skywalking的探针对吞吐量的影响最小，zipkin的吞吐量居中。pinpoint的探针对吞吐量的影响较为明显，在500并发用户时，测试服务的吞吐量从1385降低到774，影响很大。然后再看下CPU和memory的影响，在内部服务器进行的压测，对CPU和memory的影响都差不多在10%之内。

五、服务保障平台

监控指标

资源类型	监控指标	指标说明	采集频率(s)	数据源
RDS	CpuUsage	CPU使用率	300
	DiskUsage	磁盘使用率	300
	IOPSUsage	IOPS使用率	300
	ConnectionUsage	连接数使用率	300
	MemoryUsage	内存使用率	300
	MySQL_NetworkInNew	Mysql每秒网络入流量	300
	MySQL_NetworkOutNew	Mysql每秒网络出流量	300
	MySQL_ActiveSessions	Mysql当前活跃Sessions数	300
REDIS	MemoryUsage	已用容量百分比	60
	ConnectionUsage	已用连接数百分比	60
	IntranetInRatio	写入网络带宽使用率	60
	IntranetOutRatio	读取网络带宽使用率	60
	CpuUsage	CPU使用率	60
SLB	HeathyServerCount	后端健康ECS实例个数	60
	UnhealthyServerCount	后端异常ECS实例个数	60
ECS	tsar.partition.util	磁盘使用率	60
	tsar.io.util	硬盘有IO操作的时间与总时间的百分比	60
	tsar.io.svctm	硬盘平均每次I/O操作所花的时间	60
	tsar.io.await	硬盘I/O平均每次操作的等待时间	60
	tsar.io.rrqms	硬盘读IOPS个	60
	tsar.io.wrqms	硬盘写IOPS个	60
	tsar.tcpx.cnest	tcp新建连接数	60
	tsar.tcpx.est	tcp建立的连接数	60
	tsar.load.load15	15分钟的系统平均负载	60
	tsar.load.load5	5分钟的系统平均负载	60
	tsar.load.load1	1分钟的系统平均负载	60
	tsar.tcp.retran	tcp重传率	60
	tsar.traffic.bytout	出口流量	60
	tsar.traffic.bytin	入口流量	60
	tsar.mem.util	内存使用率	60
	tsar.cpu.util	cpu利用率	60
OCS
OTS
ONS
Kafka
应用类
资源类型	监控指标	指标说明	采集频率(s)	数据源
HTTP	CostAvg	平均耗时	60	全链路日志
两种：	CostMax	最大耗时	60
http-client	SuccessCount	成功次数	60
http-server	FailCount	失败次数	60
Dubbo	CostAvg	平均耗时	60	全链路日志
两种：	CostMax	最大耗时	60
dubbo-service	SuccessCount	成功次数	60
dubbo-consumer	FailCount	失败次数	60
SQL	CostAvg	平均耗时	60	全链路日志
	CostMax	最大耗时	60
	SuccessCount	成功次数	60
	FailCount	失败次数	60
MQ				全链路日志
JVM				待定
Druid				Druid

全链路报警

• 链路报警规则

六、数据架构

• Hadoop服务
• HBase 服务

相关产品

• Flume
• Phoenix
• TiDB
• ClickHouse
• Presto
• Kylin

七、配置中心

期望特性：

• 统一管理不同环境、不同集群的配置
• 配置修改实时生效（热发布）
• 版本发布管理
• 灰度发布
• 权限管理、发布审核、操作审计
• 客户端配置信息监控

八、应用综合管理台

定位类似于Spring Boot Admin Server，作为Optimus应用的综合管理控制后台，具有自动注册/发现、在线调试、接口文档管理，查看应用元数据、服务指标等功能。提供客户端供应用接入。

期望目标
1、 基本的客户端服务自动注册和指标采集，并提供对应服务端和UI展示。
2、统一的文档注册和管理（Web/Dubbo）和接口调试能力。
3、接入已有的链路追踪、日志平台、Job平台、配置中心、架构感知，提供与其他平台的关联能力。
4、提供基本的DevOps能力，自动化应用开发、测试、打包、上线、下线、扩缩容。

功能

• 服务端提供展示应用元数据的能力

• 接口文档管理Document, 目标是替换目前Swagger的客户端UI

• 在线调试Online Visible Debug,提供可视化的在线调试能力，主要针对接口调试。

• 服务指标针对单个应用实例的基本监控点，是持续监控的时序数据，分为累加值、瞬时值、可计算的值、可聚合的其他指标。
  上线时间\启动耗时\已运行时间

• 自动关联Relations
  ** 通过项目管理等系统关联应用的项目、产品和其他基础信息。
  ** 注册至服务端的应用允许自动关联Apollo、JIRA、GitLab、JenKins等服务，通过各服务的API接口拉取数据。
  ** 可手动指定关联服务的地址

Spring Boot Admin 介绍
Spring Boot Admin 是一个开源社区项目，用于管理和监控 SpringBoot 应用程序。但是它没有跟 Spring Cloud 做深度的整合。我们希望做一个 Spring Cloud Admin，它能提供如下功能:

• 增加服务治理控制台，整合微服务控制能力
• 服务查询、管理
• 配置管理
• 限流降级等
• 项目管理/监控

九、数据工作台

• BI分析平台
• 离线数据分析
• 数据管理平台
• 流计算平台
• 因子挖掘平台
• 数据同步中间件
• 流量统计平台

十、混沌工程

介绍
混沌工程（Chaos Engineering）：是在分布式系统上进行实验的学科, 目的是建立对系统抵御生产环境中失控条件的能力以及信心。最早由Netflix及相关团队提出。

为什么需要混沌工程

混沌工程与测试的区别

混沌工程、故障注入和故障测试在关注点和工具中都有很大的重叠。
混沌工程和其他方法之间的主要区别在于，混沌工程是一种生成新信息的实践，而故障注入是测试一种情况的一种特定方法。当您想要探索复杂系统可能出现的不良行为时，注入通信延迟和错误等失败是一种很好的方法。但是我们也想探索诸如流量激增，激烈竞争，拜占庭式失败，以及消息的计划外或不常见的组合。如果一个面向消费者的网站突然因为流量激增而导致更多收入，我们很难称之为错误或失败，但我们仍然对探索系统的影响非常感兴趣。同样，故障测试以某种预想的方式破坏系统，但没有探索更多可能发生的奇怪场景，那么不可预测的事情就可能发生。
测试和实验之间可以有一个重要的区别。在测试中，进行断言：给定特定条件，系统将发出特定输出。测试通常是二进制态的，并确定属性是真还是假。严格地说，这不会产生关于系统的新知识，它只是将效价分配给它的已知属性。实验产生新知识，并经常提出新的探索途径。我们认为混沌工程是一种实验形式，可以产生关于系统的新知识。它不仅仅是一种测试已知属性的方法，可以通过集成测试更轻松地进行验证。

• ChaosBlade 是一款遵循混沌工程实验原理，建立在阿里巴巴近十年故障测试和演练实践基础上，并结合了集团各业务的最佳创意和实践，提供丰富故障场景实现，帮助分布式系统提升容错性和可恢复性的混沌工程工具。
• 故障演练平台

十一、日志平台

日志规范

1. 每条日志的格式严格符合规定；
2. 日志归档时，统一压缩一下，或者以日期为结尾，比如：tomcat_stdout.log.20190122.gz、tomcat_stdout.log.20190122；
3. 日志尽量输出到一个文件中，因为使用logkit收集程序接入日志的话，配置文件不能很好的匹配，会对ElasticSearch造成很大的压力；

十二、工作效率平台

Devops及持续集成重构项目

十三、中间件项目

1、分布式事务:Seata、hmily等。tcc、基于消息的最终一致性等
开源 TCC 框架对比

EasyTransaction
ByteTCC
TCC-Transaction

2、work-flow
3、压测链路
4、服务质量：异常计数
5、权限中心
6、服务幂等组件

leaf改造发号器

为什么需要一个发号器

在使用数据库时，表的主键经常会使用数据库的自增（auto_increment）来产生。这当然很方便也很高效。但是使用自增也会带来一些麻烦。如果从一个数据库以外的地方，也就是发号器来产生全局唯一 ID，这些问题就可以得到解决，生活就可以更美好。

• 难以适应分片场景
  在采用数据库分片时，如果使用数据库自增 ID，不同分片上会产生相同的 ID。单靠 ID 无法唯一标示一个对象，还需要额外加上分片字段才行。如果需要将 ID 用于其他对象的关联时，会麻烦很多。而采用发号器生成的是全局唯一的 ID，单靠 ID 就能实现关联。同时，这也使得采用 ID 作为分片字段成为可能。

• 主备切换时数据冲突
  在 MySQL 集群发生主备切换时，异步复制无法确保主从完全同步。在备库开放写入后，备库上产生的自增 ID 会和尚未同步的主库上的数据冲突。这样一来，即使原来的主库恢复了，也无法重新加入集群。数据修复也变成了一件非常困难的事情。引入发号器以后，备库上插入的 ID 和原来主库上的 ID 是不会重复的。因此，未复制的新增数据和对这些新增数据的修改就不会在备库发生冲突。

• 网络异常时无法判断插入是否成功
  当插入记录时，如果使用数据库自增 ID，在完成插入后，才能得到产生的 ID。如果在执行语句时发生网络中断，客户端无法知道事务是否成功，即使成功，也无法再获得产生的 ID。如果使用发号器，就可以在插入之前预先产生 ID。如果碰到网络中断，可以用已经获得的 ID 去尝试查询来判断之前的插入是否成功。
  此外，一些业务 ID 会需要一个全局唯一的整数作为它的组成部分。其他的分布式系统可以用全局单调的唯一 ID 作为事务号。有一个现成的服务就不用各自实现了

7、MQ消息可靠性保障
8、状态机中间件
概念
有限状态机，顾名思义，表示有限个状态以及在这些状态之间的转移和动作等行为的数学模型。
一个状态机应当包含以下几个要素：

• 现态：是指当前所处的状态。
• 条件：又称为事件。当一个条件被满足，可能将会触发一个动作，或者执行一次状态的迁移。
• 动作：条件满足后执行的动作行为。动作执行完毕后，可以迁移到新的状态，也可以仍旧保持原状态。动作不是必需的，当条件满足后，也可以不执行任何动作，直接迁移到新状态。
• 次态：条件满足后要迁往的新状态。“次态”是相对于“现态”而言的，“次态”一旦被激活，就转变成新的“现态”了。

十四、接口文档

介绍

随着 web 技术的发展，前后端分离成为越来越多互联网公司构建应用的方式。前后端分离的优势是一套 Api 可被多个客户端复用，分工和协作被细化，大大提高了编码效率，但同时也带来一些“副作用”:

• 接口文档不可靠。很多小伙伴管理接口文档，有使用 wiki 的，有 word 文档的，甚至还有用聊天软件口口相传的，后端接口对于前端就像一个黑盒子，经常遇到问题是接口因未知原因增加参数了，参数名变了，参数被删除了。
• 测试数据生成方案没有统一出口。我们都有这样的经历，前端开发功能依赖后端，解决方案有自己在代码注入 json 的，还有后端工程师临时搭建一套测试数据服务器，这种情况下势必会影响工作效率和代码质量，也不能及时进行更新。
• 资源分散，无法共享。接口调试每个开发者单独维护一套 Postman 接口集，每个人无法共用其他人的接口集，存在大量重复填写请求参数工作，最重要的是 postman 没法跟接口定义关联起来，导致后端没有动力去维护接口文档。 基于此，我们在前端和后端之间搭建了专属桥梁—— YApi 接口管理平台

十五、系统监控

• Open-Falcon
• Zabbix
• Nagios
• Prometheus

十六、持续集成

十七、分布式文件系统

十八、统一工作台