可借鉴系统
巡检系统
- 机器层面的巡检（巡检机器质量，有点类似于监控，但是不是粗粒度的直接报警，而是根据规则后的收敛报警）
- 变更巡检系统（升级前后的指标巡检，模式可以 关键指标在发布后一小时、两小时、十二小时，昨天同期时间等做对比，进行趋势检查、cpu、内存、响应时间、状态码、上下游关键指标来作为参考）
可改善的地方
去掉jstorm去掉不需要的依赖
现在的jstorm依赖太多，很多依赖并不一定需要用上，就会导致很大的jar包。
后端版本规范
以日期为版本号，并且加上是否稳定，来区分是否是稳定版本。
2019-04-stable、2019-04-beta，在这次集群重启的时候，通过版本号，可以比较明确确定要重启哪个jar包。
监控数据的优化
我们组现有的报警监控处于一种混沌的状态，报警数据全是原始数据，没有经过收敛，类型繁多，很多报警报出来也没有处理，我觉得报警是一种处理的信号，而不是有人咨询数据掉坑再去看那个时候是否有问题的历史信息。
觉得可以这么来改善
- 机器信息报警
- 跑高报警（阈值提高）
- 采集网卡信息
- 采集cpu信息，判断是否降频
- 处理规则 cpu降频连续n分钟超过n次，网卡丢包n分钟丢包n次，连续跑高n分钟（处理报警）
- 业务信息报警
- 数据为0监控
- 数据差异大连续n分钟n次
es查询日志的分析
可以通过分析es的查询性能和耗时，针对得到的数据进行监控，报警，优化和分析。不过鉴于es在我们组的地位不断的下降，暂不考虑。
自动化运维
从将近10场的分享中，听到大部分都是以虚拟化和容器化为基础，在自动运维上实现有问题的节点自动拉起等管理。不过对我们组而言，可能还有点早，我们还停留在人肉智能的阶段。
思维
大数据趋势
产品优化
以用户体验驱动的产品优化
- 认识：提高什么能力
- 数据：用什么数据来衡量优化效果，可度量
- 量级：提升了多少（与外界做对比而不是为了报表）
最大化最小化模型
取胜的系统，在最大化单一要素和最小化其他要素上走到了”近乎荒谬的极端” (clickhouse and so on)
服务无界，定位有界，责任有界
微服务
大版本升级
在请求上带上版本号，在ng层面根据版本号，进行引流，区分新旧业务，旧业务迁移完迁移到新业务上。
服务分组
在多机房的场景下，一般以本地机房为主要调用，可是会出现其他情况可以采用如下方法来进行提供者选择。
- ping采样
- ip相似度
配置文件
yaml拥有天然的树状结构，如果在自定义配置文件复杂的情况下，可以考虑使用yaml
柔性迭代
架构的改造没办法一蹴而就，需要通过柔性迭代，慢慢改造出来。
序列化
Java序列化：Java序列化会把要序列化的对象类的元数据和业务数据全部序列化为字节流，而且是把整个继承关系上的东西全部序列化了。它序列化出来的字节流是对那个对象结构到内容的完全描述，包含所有的信息，因此效率较低而且字节流比较大。但是由于确实是序列化了所有内容，所以可以说什么都可以传输，因此也更可用和可靠。
hession序列化：序列化数据，信息量会比较少，如果在多层继承的实体中，需慎重考虑。（ 使用hessian序列化时，一定要注意子类和父类不能有同名字段）
如果真的很影响性能，有必要可以重写实体的序列化方法（Externalizable）
zk的缺点
- 单cpu运用
- 单网卡运用
- 网络利用率低
- 资源利用率低
尽量避免中央瓶颈
大数据
多级缓存
- 在读很复杂，延迟要求很低的场景（90ms），经常缓存miss容易冲击数据库，拉长查询时间，可以采用多级缓存来解决。
缓存miss的场景，如果存在多个缓存，可以先将数据库获取的结果发送kafka，然后通过中心计算从kafka中消费广播到redis中。
知乎对mysql binlog的顺序性在kafka这种多partition的消息队列上采用的单partition，由于kafka扛不住数据量改成以database分区。（这点在别的公司在kafka上想做到完全顺序性，也是一样的做法）
es的优化
从滴滴存储pb级别的es集群中，他们对于es的改造其实不大，而是紧跟版本的演进，更新版本，他们经常遇到大查询把整个集群搞死的情况。应对的措施主要如下
- 将查询日志采集分析，获取index的查询监控
- 基于1的数据，实现自动管理，如果一个index一天内调用低于某个阈值，迁移到冷机，来节省成本。
- 基于1的数据，获取查询耗时比较大的索引，通过索引优化和迁移独立集群来达到不会搞崩集群的目的。
Flink
- Flink 1.9 将会合并Blink，性能上会有很大的改变。
- Flink 1.9 将会加入python接口，可以直接对接hive
- FLink 1.9 增加join维表的功能
- 推拉模型的改变
这点在我们这边的运用，主要也是在随机分发和能者多劳的模式
TiDB
- TiDB 3.0 听说性能不错，可以深入了解一下。
- TiDB年底的新功能TiFlash是列式存储，支持ap分析，底层基于clickhouse，不过在提问中发现，他们并没有进行很多的改造，在索引的支持上依旧是第一索引，索引的位置也会影响查询性能，而且clickhouse的版本上，并不能支持可以插拔的模式。因此我对这个新功能保持观望的态度。
- 对于clickhouse不能很好的支持删除和更新的操作，他们的做法是通过加入版本号的列来进行处理的，不过数据需要唯一id，然后再获取最新的version来作为最后的数据。
个人需要学习
- Externalizable
- classload（jar url 转为 file url ，减少getResource）
- java agent 字节增强
- 多路复用 netty http2 grpc
- thrift/Pb 协议
- TiDB的了解
- 聚簇索引与非聚簇索引的区别
- Flink ExternalCatalog
- 无状态、重状态、弱状态
- TokuDB引擎
- Hystrix
- 分布式追踪原理
- kafka—> page cache
- MHA
- Flip