2018，换个角度看微服务监控与性能优化

摘要

主要介绍分布式监控的基本概念及方法，java技术栈相关监控机制，性能监控、业务监控、异常监控、性能数据分析在融数微服务平台的实践及应用。

微服务监控

微服务架构本质是带自身特点的面向服务的分布式架构模式。

微服务架构特征是有更细粒度服务边界，倡导独立开发、测试、部署、扩展等等，更细粒度带来的敏捷提升，以及分布式系统固有的复杂性。

微服务是一个分布式的架构模式，它一直以来都会有一些自身的问题。

首先是问题的定位。当系统发从单个节点扩张到很多节点的时候，如果系统的某个点出现问题，对于我们的运维和开发人员来说，这时的问题定位可能就会变成一个挑战。

其次是当新的业务进来以后，系统能否支持，系统运行的状况又是怎样？还有现在的一些电商要做促销活动，容量规划怎么做？我们可以通过监控手段对系统进行衡量，或者做一个数据支撑。

其它还有就是要理解分布式系统是怎样一个拓扑结构，如何部署，系统之间怎样通信，系统目前是怎样的性能状况，以及出了问题我们要怎么去发现它。

这些都可能是分布式系统需要面对的问题。出现这些问题后，监控就是一个比较常用、有效率的一个手段。

总的来说，监控主要解决的是感知系统的状况。

应用性能、拓扑第三方组件；资源使用；异常堆栈；数据聚合、分析报警；自定义业务。

开源：Zabbix、ELK、Zipkin；

闭源：Prometheus、Pinpoint 、Newrelic；

或者“撸起袖子自己干”。

命令行工具：Command line tools

代码级工具：Log、SDK、AOP

采集数据并拿到真正关注的指标：Instrument+JMX

JMX机制获取JVM、OS相关数据：

ManagementFactory.getXXXMXBean();

OperatingSystemMXBean

RuntimeMXBean

MemoryMXBean

ThreadMXBean

Collection<GarbageCollectorMXBean>

思路：围绕微服务的开发、部署、调用、通信、业务处理过程。

在开发部署方面，我们构建了一个完整的工具链，通过插件机制把整个系统的初始化环境和代码结构构建起来。

调用的时候对于普通用户来说，并不想介入太多特定框架。最好是环境透明初始化，接近开箱即用的状态。

分布式框架意味着有一个跨进程的调用和数据的传输等问题需要解决。如果每次调用都重新进行连接，从性能角度来说可能不太友好。长连接可以解决一部分问题，但假如通信数据很庞大，还会涉及到数据的压缩以及事件异步。

在使用过程中尽量做到框架透明，减少或消除依赖。

运维监控接入整合监控平台。

思路：在有限资源内实现高效。

我们不希望为了监控而引入很多源码，所以使用了Instrument和JMX机制。我们需要实时控制它，所以要让它可配置化。

我们在高性能方面会做一个考量，比如限制它线程数量的大小等等。频繁采集会对系统产生很严重的影响，我们选择用采样的方式来进行。

比优化更困难的是发现问题；

没有条件或目标的优化都是耍流氓；

要追求对资源的高效利用。

文件io操作，IO操作使用buffer。动机：减少内核级调用、减少IO操作、可能减少CPU指令。

多线程环境，幵行、减少锁竞争。动机：解放单线程限制、获取CPU核数带来的计算能力的扩展。

使用jdkcollection，数据结构指定大小。动机：减少扩容带来的内存占用、及其复制和老数据回收带来的CPU指令。

调整算法。动机：在执行每一次任务时，减少或优化CPU指令。

调整heap大小。动机：应用稳定状态下新生代、老年代、方法区大小。大小的调整进而影响到gc的行为。

更换GC。动机：面向响应时间、吞吐量，终极目标针对CPU。

启停其他特定参数。动机：针对特定场景，如对验尸、逃逸分析、JIT支持。

根据gc日志计算出应用长期存活对象(老年代、永久代)的大小。

建立heap基准大小（参考建议：基于长期存活对象大小，整堆如果限定为其大小的3-4x。那么新生代为其1~1.5x，老年代为其2-3x，永久代为自身大小的1.5x）。

按目标是针对吞处理、响应时间来调整GC行为。启用相应GC收集器，调整相应新生代、老年代、永久代大小。

按额外需求起停其他参数。