全链路监控系统整合业务系统如何高可用
- 2020 年 2 月 24 日
- 笔记
参照zinpkin全链路监控系统的弊端:监控系统收集器，通过集成SpringBoot插件，耦合侵入业务，和应用部署在同一个jvm中，影响洪峰下的业务系统的高可用性。
高可用设计方案:
保障高可用必须牺牲一致性
目前全链路架构方案的改进：
方案：将影响业务性能的模块和应用解耦，以java agent和应用部署在同一台服务器上，保证进程隔离。
搜集器单独部署，业务侵入以java agent方式侵入。
优点：对业务零侵入，性能损耗也比较小
可以借鉴Pinpoint的设计思想，Pinpoint架构：
- HBase (用于存储数据)
- Pinpoint Collector (信息的收集者，部署在tomcat中)
- Pinpoint Web (提供WEB_UI界面，部署在tomcat中)
- Pinpoint Agent (附加到 java 应用来做采样）
监控系统es存储优化
es客户端优化：
1）es客户端使用的是TransportClient,其实为了提高kafka的es消费者消费的速度，减少日志洪峰下，kafka日志消息的堆积，可以考虑换用Node Client。
TransportClient作为es集群和应用程序之间的通信层，是集群外部的，和集群是完全解耦的，适合大批量的客户端连接，轻量级客户端，执行性能要比Node Client差一点。
Node Client（节点客户端）把应用程序当作一个集群中的客户端节点（非data和master)，因为他是集群内部的一个节点，所以知道整个集群的状态，通信更加高效。
2）在需要与集群解耦的业务场景下，使用TransportClient，为了提升效率，可以考虑将kafka和es通信的通道抽离成一个基础服务组件，单独分布式部署（高可用架构部署)，一个节点一个客户端，负载均衡，比如有3个节点，这样就可以并行的消化生产者消息，到es集群，从而解决高流量日志消息对业务系统的影响。
