大家好，又见面了，我是风君子。
微服务架构其实就是将单一的应用程序划分成为一组小的服务，其中每个服务都是独立的业务单元，同时又能够被独立开发、运行、测试以及部署。简单来说，它的本质其实就是拆分和独立，这也决定了微服务的部署应该是分布式的。微服务架构虽然解决了目前诸多的架构层面的问题，但在分布式部署的环境中，如何才能够有效监控每一个服务，并及时发现系统中的问题又成为了新的挑战。
\\
Google公司早已就在其生产系统中实践了分布式理念，为了解决监控问题，他们研发了Dapper分布式跟踪系统，并对外公开了相关论文。与此同时，Twitter基于Google的论文开发了Dapper系统的开源实现Zipkin。国内类似的有过曝光的系统还有淘宝鹰眼系统EagleEye以及开源软件Skywalking。InfoQ记者就分布式监控相关的问题采访了Skywalking作者吴晟，请他从整体层面为读者分享解读分布式监控相关的技术难点。另外，吴晟也将会在9月10日举行的CNUTCon全球运维技术大会上分享相关话题，欢迎关注。
\\
InfoQ：对于分布式系统的监控，你认为难点是什么？目前有哪些可行的落地思路？
\\
\
吴晟：分布式监控系统从使用的角度上，无论是手动探针还是自动探针，上手难度都不大。多数的技术型软件，从数据库、大数据处理到流式计算，在入门时都需要经历复杂的安装和参数设置过程。但是对于分布式监控系统，无论是Zipkin、Skywalking这些国内外的开源监控产品，还是各种商业APM产品，安装和入门难度都不大。
\\
但对于开发一款分布式监控系统来说，情境则完全不同，无论是探针还是后台处理都有很多的挑战。比如：
\\
- \\t
Java自动探针的实现，对于Java字节码、程序运行情况、GC、程序优化都要有相当细致的要求。
\\t\\t
- \\t
后端分析服务，如果不了解探针，给出的分析方案难度大，效率低，机器需求量大。
\\t\\t
- \\t
探针网络传输的需求，序列化效率。
\\t\
在APM领域，程序的细节决定产品的性能。目前按照探针的实现，可行的思路主要有四种：
\\
- \\t
基于日志系统，探针只负责对日志加上编号，又类似ELK的系统进行收集、处理、展示。这方面没有很成熟的产品，一般都属于公司内部封装的框架。
\\t\\t
- \\t
自动探针，适用语言：Java、C#、PHP、Node.js等等存在VM的语言。绝对大多数的商业产品和热门的开源产品都属于这个系列。
\\t\\t
- \\t
全手动探针，优势是适用范围广，最有名的就是Zipkin的整个生态系统，分布式追踪几乎无处不在。也是现在全球运用最广泛的分布式监控系统。
\\t\\t
- \\t
同时支持自动和手动模式的探针，适用语言同样是Java、C#、PHP、Node.js等等存在VM的语言，由于技术复杂性提高，运用的较少。优点是入门方便，同时使用灵活。商业上主要是Instana，开源主要是sky-walking提供了技术解决方案。
\\t\
\\
InfoQ：分布式监控领域常用的理论都有哪些？
\\
\
吴晟：所有的分布式理论几乎都来自2010年的Google论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》，这里面详尽的描述了分布式系统的解决思路。
\\
Dapper作为分布式监控的核心，主要给大家介绍了Trace、Span、spanId、log、采样等几个重要概念。其中Trace就是一个可能跨越多个节点的分布式。Span是调用过程中一个时间区间（时间跨度），这也是这个英文名字的由来。一般对应一个方法或者代码块的执行。SpanId按照书的索引方式（例如1, 1.0, 1.1, 1.1.1）来表达层级关系，让更多的读者很好的理解了调用链追踪。不过这里要强调的是，绝大多数的追踪系统，包括开源和商业，在工程实践上，因为消耗问题都放弃了这种方法。
\\
log是Span跨度内发生的事件，比如异常。在实际的产品中，会使用Tag、Annotation、Log、Event等多种概念来提升效率。采样是Dapper是大篇幅强调的问题，也就是说，超高并发系统中采样是必然，如何采样也是各产品策略不同，比如按照Span采样，按照Trace采样。
\\
但是几乎所有的现在开源和商业分布式监控系统，都在论文的基础上做了大量改进，模型并不相同。目前阶段，CNCF基金会的OpenTracing标准，是一个很好的理论参考。
\\
还有就是Zipkin的庞大生态和大量公司的参与。我和Zipkin的负责人，Pivotal资深工程师Adrian Cole有过很多的沟通，在跨语言，跨平台的监控上，Zipkin有着强大的用户基础和案例。
\
\\
InfoQ：从你的角度来看，分布式监控系统应该包含哪些模块？
\\
\
吴晟：监控系统一般分为三大模块：
\\
探针或SDK，负责数据采集和发送。探针或SDK是应用程序的收集端。一般使用插件的模式，自动探针一般是不需要修改程序，而SDK则是需要修改部分配置或者代码。skywalking就是自动探针为主，zipkin-brave就是Zipkin的Java手动探针。
\\
Collector模块，负责数据收集、分析、汇总、告警和存储。Collector模块，这个根据不同的APM实现，可能由一个或者多个子系统构成。Collector负责对探针和SDK提供网络接口（TCP、UDP、HTTP不同形式接口）。
\\
功能上，主要包含数据收集、分析、汇总、告警和存储。这些模块在复杂的开源APM和商业产品上都保持一致。大家选择时，值得注意的是，现在包括Zipkin在内的不少国外的追踪系统，是只负责追踪，不负责分析汇总，他们认为分析可以由使用者自己负责。
\\
作为分析方式，分为流式分析和异步批量两种，而流式分析会对数据统计和告警的实时性更有帮助。
\\
UI，负责高实时性的展现。包括但不限于Trace的查询，统计数据展现，拓扑图展现，VM或进程相关信息等，监控关键数据的展现。
\
\\
InfoQ：对于访问量较大的应用，如何解决埋点监控的性能问题？
\\
\
吴晟：这是我在本次分享里面很多内容的根本，性能问题。这个其实没有标准答案，根据系统的不同，流量不同，容忍度不同，标准会完全不同。我们举个简单的例子，在Google，千分之一，万分之一的采样，依然是大数据分析，依然足以定位问题；在多数非BAT核心产品上，50%或者100%采样都不会有性能问题。一定要选择适合自己的，不要过分担忧。
\\
一般说来，一款合格的产品，在单点500TPS之下的应用，采样率都可以保持的很高。
\
\\
InfoQ：现在你们的监控系统有没有结合大数据分析，智能的进行故障预警以及处理？
\\
\
吴晟：目前sky-walking没有去做这方面的工作，因为这样会大大增加部署和运维的难度。有需求，有运维的能力的公司，很容易在产品的基础上进行相关的分析。
\\
在商业产品中，指标方差数，趋势分析，偏移量，热度分析，用户促销活动等等都是在处理范围中。
\
\\
InfoQ：你的演讲里有一个有趣的观点，面向研发的监控和面向运维的监控，如何理解这句话？
\\
\
吴晟：虽然现在DevOps很热，但是无论一体化进行到哪个阶段，线上问题和开发迭代，永远都有时间差。所以“线上问题的发现、规避和应急响应”和“研发过程对于产品的改进和修复”是两个有联系又实际并不相同的理念。
\\
目前的DevOps，强调快速的迭代和响应，微更新，快速发布。相关的容器化技术也是倍受追捧。而这些对于分布式监控的要求也是越来越高。主要原因是分布式的节点，从几十个上升到几百个上千个都是很常见的。
\\
但是，DevOps的发展，并不会完全消除“线上问题响应”和”线下修复问题“中间的时间差。
\\
比如在生产环境中，某个数据库因为冷门业务的某条大SQL语句缓慢，拖慢服务器IO性能，造成应用其他主要接口响应受到影响。
\\
- \\t
对于运维人员，监控系统的职责是需要发现这条慢SQL，识别数据对应的session信息，辅助运维人员杀掉这条SQL的执行。
\\t\\t
- \\t
对于开发人员，则需要反馈调用链路，找到发生这条SQL调用的原因，是特定参数引起的，还是特定的条件分支，或者是特定的用户。并通过本周期迭代，避免或降低再次发生这个问题的风险。
\\t\
这个案例中，你会看到，其实，APM系统需要提供的信息是不太相同的。这就是所谓的“面向研发的监控”和“面向运维的监控”之间的差别。而很多人都忽略了这个差别，而这对于APM系统的运用和演进都是很重要的。
\