分布式基础架构组件

1、流量统计平台

组件介绍

流量统计平台

说明

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

指望特性

功能列表:

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

2、分布式任务调度中心

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

开源对比

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

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

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

• LTS、Uncode-Schedule、Antares 等

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

使用场景:

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

指望特性

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

4、全链路跟踪

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

全链路监控平台功能点

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%以内。

5、服务保障平台

监控指标

资源类型	监控指标	指标说明	采集频率(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

全链路报警

• 链路报警规则

6、数据架构

• Hadoop服务
• HBase 服务

相关产品

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

7、配置中心

指望特性：

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

8、应用综合管理台

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

指望目标
一、 基本的客户端服务自动注册和指标采集，并提供对应服务端和UI展现。
二、统一的文档注册和管理（Web/Dubbo）和接口调试能力。
三、接入已有的链路追踪、日志平台、Job平台、配置中心、架构感知，提供与其余平台的关联能力。
四、提供基本的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，它能提供以下功能:

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

9、数据工做台

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

10、混沌工程

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

为何须要混沌工程

混沌工程与测试的区别

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

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

11、日志平台

日志规范

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

12、工做效率平台

Devops及持续集成重构项目

十3、中间件项目

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

EasyTransaction
ByteTCC
TCC-Transaction

二、work-flow
三、压测链路
四、服务质量：异常计数
五、权限中心
六、服务幂等组件

leaf改造发号器

为何须要一个发号器

在使用数据库时，表的主键常常会使用数据库的自增（auto_increment）来产生。这固然很方便也很高效。可是使用自增也会带来一些麻烦。若是从一个数据库之外的地方，也就是发号器来产生全局惟一 ID，这些问题就能够获得解决，生活就能够更美好。

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

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

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

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

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

十4、接口文档

介绍

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

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

十5、系统监控

• Open-Falcon
• Zabbix
• Nagios
• Prometheus

十6、持续集成

十7、分布式文件系统

十8、统一工做台