为了帮助IT从业者职业之路拥有更多收获，在诸多C粉的殷切期待下，由 CTO俱乐部打造的CTO线上讲堂自登场以来获得大家好评。本期邀请云智慧首席架构师高驰涛（Neeke Gao）带来“如何通过APM持续构建高性能IT架构？ ”的主题分享。
欢迎加入CTO讲堂微信群与业界大咖零距离沟通，12月17日本期讲堂报名方式拖至文末查看。
分享嘉宾：云智慧首席架构师 高驰涛（Neeke Gao）
嘉宾简介：高驰涛（Neeke Gao），云智慧首席架构师，PHP/PECL开发组成员，同时也是PECL/SeasLog 的作者。10年研发管理经验，早期从事大规模企业信息化研发架构，09年涉足互联网数字营销领域并深入研究架构与性能优化。2014 年加入云智慧，致力于 APM 产品的架构与研发。崇尚敏捷，高效，GettingReal。
公司简介：云智慧（北京）科技有限公司是国内领先的应用性能管理服务商。基于大数据分析为企业级用户提供全面专业的端到端应用性能管理（End To End Application Performance Management）解决方案。云智慧旗下产品监控宝、透视宝和压测宝，已累计为电子商务、移动互联网、广告传媒、在线游戏、教育医疗、金融证券、政企等行业的几十万用户提供了前瞻性的智慧性能管理服务，是新一代应用性能管理（APM）的领导者。
以下是12月10日CTO讲堂现场完整速记：
主持人：下面欢迎云智慧首席架构师，高驰涛（Neeke Gao）做自我介绍。
高驰涛：大家好，我是来自云智慧的高驰涛（Neeke Gao），PHP/PECL开发组成员。2010年以前一直在传统企业中做企业信息化的研发和架构，2010年有幸加入易车，开始涉足互联网数字营销领域，2014年加入云智慧，致力于APM产品的架构和研发。语言方向为PHP, Python, C, Go。崇尚敏捷，高效，GettingReal。
主持人：欢迎您~看到您近年来涉足互联网数字营销领域并深入研究架构与性能优化，什么契机下加入了云智慧？最初的想法是怎样的？
高驰涛：互联网数字营销领域，简单说其实就是利用互联网门户或垂直门户或自媒体等等区别于传统行式的新媒体形式进行，广告。这个市场向来非常的火爆。在营销过程中和营销后的技术领域，有很大部分是在进行数据的采集，监测，归总分析和报告管理。这部分技术内容深化之后，其实就是我们目前所了解的云计算和大数据分析，这在很早以前已经完全成为了另一个新兴的行业。
加入云智慧，首先要感谢我们的CEO Andy，那时我刚刚加入PHP/PECL开发组。这个契机让我有机会将一直以来研究的底层技术发挥应用，并更深入地针对APM这个事情进行钻研。在Andy的带领下，整个团队都在深沉的技术氛围中，特别的有朝气，团结向上。这个团队集合了非常多的技术专家和有志之士，大家共同努力着同一个事情，这是非常令人振奋的。
主持人：请介绍下目前云智慧的情况以及技术团队构成。
高驰涛：云智慧继2014年A、B两轮融资之后又在前天（2015年12月8日），刚刚完成了由红杉资本和戈壁创投追加投资的1230万美元B+轮融资，这两年的三级跳，进一步证实了云智慧从性能测试，性能监控到性能管理的全方位产品和解决方案，已经得到了市场和用户的认可。
目前公司服务团队由最初的30余人发展到如今的160多人，产品技术团队约占公司人数的70%，技术部门由产品研发、技术服务两部分组成，并设有专门的架构师团队、产品研发团队、售前技术支持团队、项目实施和专业服务团队。
主持人：发展的真快，那麻烦您简单介绍下云智慧目前提供的产品和服务吧。
高驰涛：云智慧自09年成立以来，先后推出了旗下的三款产品：监控宝，透视宝，压测宝。
在互联网时代，中国还没有什么像样的为 IT 服务的公司，在 IT 基础设施这块非常薄弱，一个简单的业务问题可能都解决得不是很好。例如，一些很大的互联网公司经常会接到用户投诉说网站访问不了，然而他们的 IT 部门并不知道。这是因为在国内几乎所有的基础设施是三大运营商在做，他们之间是互联互通都是有问题的，所以IT部门没办法第一时间发现使用其他运营商网络的用户遇到的问题。
云智慧就从这个点出发，发布了SaaS产品－－监控宝－－来解决当时的互联网企业的一个痛点问题：业务中断。怎么做呢？我们部署了很多服务器在各大运营商不同地区骨干网的节点上，通过这些分布式访问点来帮助企业的网站发现问题。到今天，我们已经在全球 200 多个城市部署了服务器，来实现网站的实时监控 。目前中国有近80%的运维工程师都在使用这款产品。
随着云计算、移动互联网以及 IT 运维技术的快速发展，常规监控依然存在，但随着客户的增长以及 IT 成熟度的发展， 业务中断问题对于很多公司已经不是个解决不了的事，用户体验问题变得更加突出。伴随移动互联网的发展，每人都有手机，手机里有很多App。五六年前在很多传统业务里，普通企业的IT运维很难直接接触到用户，但是今天，通过用户手机里装的App，用户每时每刻都在跟企业的 IT 系统打交道。这时候，用户体验就基本是由这个 IT 系统传递，我们就从这个点上发现了另外一个很大的市场：业务性能监控的问题，因此云智慧发布了－－透视宝－－这样一个新产品。以上是云智慧所从事的领域：「应用性能监控」即 APM。
2015年云智慧又推出了基于真实业务场颢的全链路性能测试服务－－压测宝，这也标志着云智慧面向全生命周期的一站式性能解决方案产品布局的初步完成。
主持人：有人说APM就是速度监测和日志管理，该如何准确理解APM的真正含义？
高驰涛：APM行业近几年非常火爆，已经逐步成为企业级用户对IT软硬件监控和管理的刚需。可是由于各APM厂商的理解不同，大家所认识的APM也并不完全。我们看一下Gartner对APM的定义：
根据Garter的定义，真正的APM要求做到5个分析和管理范围：终端用户体验，应用架构映射，应用事务分析，深度应用诊断，分析与报告。这里需要特别指出的是：没错，APM绝不仅仅是简单的速度监测和日志管理。因为目前确实已经有不少大小厂商，看似酷炫的界面，其实做到的核心业务只是比较基础的日志统计管理。我们再来看一个经过抽象的复杂应用架构模型：
用户请求，通过前端缓存，通过WebServer，同步或异步地采用可复用的业务集群；然后数据经过同步或异步的各种类型数据中心，最终通过数据路由，与文件系统＼DB系统＼其他资源系统，进行交互。
上面是软件架构模型。我们再看一下硬件架构模型：
假如这个应用服务器的研发部门接到投诉：有一个用户不能登录了。我们能准确地定位到上面两个模型中的任何一个位置吗？
相信很多人都不能回答这个问题。因为一个请求的过程实在是太复杂，没有办法准确地定位：
这里有太多的可能性，导致我们无法快速定位。我曾经遇到最离谱的原因是，某一个WebServer实例的磁盘被日志写满了。而此时，我们需要的就是APM。而单单从某一个点的表现都是片面的，更不可能准确地定位到问题的根本。
主持人：APM管理最为核心的要素包括哪些？
高驰涛：APM要求企业做到的，就是怎样通过上面五个层次（终端用户体验，应用架构映射，应用事务分析，深度应用诊断，分析与报告），做到快速精确的定位，并提供解决问题或优化的建议方案。
终端用户，指的是用户本身，用户说你快说你好，你才是真正的快和好，服务器自己的表现其实也是片面的，只有到了用户那里，才是真正的服务。
应用架构映射，曾经遇到过一个上市企业的cto，他坦言，就他们目前10多名架构师的规模，全部上阵，也需要半年时间才能把整个架构画清楚。APM要求马上呈现它。
应用事务分析，指的并非mysql等关系型数据库的事务，这里指的是用户的行为事务，如：打开商品，加入购物车，完成购买。一个应用复杂程度非常，应用事务也是异常复杂的，APM要求管理者能够很好地分析和管理它们。
深度应用诊断，一个请求慢了或者断了，原因会非常多而且复杂，具体为什么导致，性能瓶颈究竟在哪里，APM要求快速地定位并且准确地进行诊断。
分析与报告，数据的多样性和快速输入，要求分析和报告要足够快，足够智能。
主持人：可否从具体产品适用场景或者客户案例方面来阐述一下云智慧产品的服务流程。
高驰涛：云智慧目前已经累计为数十万企业用户提供过服务。
大家所熟知的监控宝，提供的主要是saas服务，也为部分客户提供了私有部署。客户主要使用监控宝完成网站和服务器的可用性和硬件服务性能监控和告警。比如一个网站页面，在北京是否可以正常打开，打开速度是多少，文档大小如何，有否使用CDN等等信息都可以非常方便地在平台上进行配置，然后利用遍布全球的近300个监控点进行实时地测试性监控。监控宝最近又发布了新一版的API监控，同样利用全球监控点，可以实时地对某一个API或某一组API工作流程进行可用性和稳定性的监控。
透视宝和压测宝相对比较新，透视宝主要做的是应用性能管理，压测宝主要做基于真实业务场颢的全链路性能测试。如果监控宝监控到某一个网站可用性差了，这只是一个表现，并不能准确地反映为什么变成这样，这时需要使用透视宝这个应用性能管理服务来发现为什么慢，并且可以准确地定位到慢的具体元素，是js出了错，还是硬件问题，或者是应用中的具体的某一行代码或某一条sql出现了问题。最主要使用透视宝可以发现生产环境中那些即时出现的问题，并且可以将问题产生的现场，包括软硬件的所有信息，完全地还原出来。
其实很多问题在部署生产环境之前也可以通过压测宝进行发现。很多问题，只有在生产环境才会出现，原因是我们不能在测试环境中完全地模拟真实用户的行为。而压测宝才可以完成这一点，同样利用全球监控点，模拟用户的真实访问，对未发布的或者已经发布beta的应用服务进行有流程的压力测试，从而更早地发现应用性能问题的瓶颈到底在哪里。
云智慧已经取得iso9001服务认证体系认证，整个服务流程是规范严谨的。
主持人：云智慧的产品有什么独特之处？与国内外同类型的服务公司相比竞争力体现在哪？
高驰涛：云智慧的产品体系与竞品对比，优势非常明显。这里提一下最明确的三点：
我们从上面的软硬件模型中可以看到，一个用户请求从前到后，经过了无数的节点才最终返回数据并展现在用户面前，相信很多有经验的开发和运维都曾经想，怎样有效地将从用户请求开始，将请求链路中的数据都采集到，并且有效地关联起来，就美了。这也是云智慧一直以来努力的方向。并且也已经有所成效。
“端到端”自多年前业内就在提End2End，现在业内几个APM厂商在云智慧提出端到端的概念之后，也在这么吆喝着。端到端有很多种理解，我们的理解是：从终端用户出发，将从Request到Response整个链路中涉及到的所有数据，有效地串接起来，这样的数据才是真正的端到端。而不是将数据按照时间序列进行简单地罗列展现。
APM中的”大数据“是天生的，因为首先，这涉及到用户行为。凡是提到用户行为，大家就必然会想到，大数据是它必不可少的特征之一；其次，APM由于采集指标的多样性和维度的多样性，又明显使APM带有了大数据的另一个典型特征；对大数据的实时分析和处理，是整个APM实践中最有挑战的一个事情。
云智慧目前可以承诺所有用户，数据从采集到分析展现和阈值告警，只需几秒钟，几乎是实时的。
主持人：请举例介绍下可为企业用户做的ROI分析。
高驰涛：云智慧在多年的实践中，以及对数十万用户数据的需求提炼，最终帮助这些客户解决了这样非常实际的三个需求：
1. 帮助企业解决普通存在的” 投诉即反馈 “的情况， 非常有力的改善了研发，运维，管理人员被动接受反馈的现状，避免了业务下降和直接的用户丢失。
这一点非常实际，相当有过研发或运维经验的朋友们都知道，这类问题屡见不鲜，研发运维部门相当被动，往往在解决问题之前，用户体验已经大大降低或者用户已经直接丢失。
2. 帮助企业管理者避免了项目优化或重构过程中，盲目的性能和体验优化，提供了有效的性能和体验优化的建议，和相对应的充分的数据佐证。
项目运行一段时间后，研发和产品准备进行项目优化或重构时，往往无法入手。我们的不少客户正是在此契机上先用了云智慧的服务，这样，优化和重构先从了解现有应用开始，然后找到问题症结，对症下药。
3. 帮助企业几乎无成本地，零修改地进行性能和体验的监控。
在多年的服务实践中，我们发现，性能分析和管理在有能力的公司里面早已经开始着手，但是他们由于技术能力和自身业务发展的原因，没有很好的解决方案，多数是拿着开源软件东拼西凑，再加入用户自已修改原有的代码，这样费力劳神，满目疮痍。
而在应用云智慧的整体解决方案时，用户基本上不需要修改任何代码。快速插拔，这是非常有利的。
主持人：可否分享一下在技术方面云智慧都做了哪些探索，用到了什么技术？
高驰涛：前面说，我们对“端到端”理解是从终端用户出发，将从Request到Response整个链路中涉及到的所有数据，有效地串接起来。这是一个很有意思的事情。我们知道，几乎所有的WebServer软件都拥有输入和输出过滤器，即“Input Filter”和“Output Filter”。这两个过滤器分别处理着请求和连接，响应和返回。在数据交接的过程中，有着非常紧密的联系。
我们的实现方式也非常地直接有效，从请求开始产生一个一致Hash，该Hash将伴随整个请示过程，在一步一步向后或旁路传递的过程中进行”染色“；并从最末或最旁的响应开始，一步一步向前或旁路进行回应。这样就可以在整个请求中的任一点，都可以做到请求的自解释：我是谁，从哪里来，往哪里去。
那么基于这个实现原理，我们不难在请求数据的最末端准确地得到一次请求中的完整的Request链路。于是我们可以基于此，对数以亿万计的用户行为，戴上一个”应用“的帽子。在这个帽子下面，数据也不再是一个个的信息孤岛，而是有生命的交替转换。
我们基于此可以准确分析出一个应用的架构拓扑，整个应用中，有哪些负载均衡，每个请求命中的是哪一个负载点；也可以准确地分析出一个服务集群中，有哪些组成节点，每一次请求，究竟命中的是哪一个或多个节点。
比如：
我们从图上，可以清晰地看到云智慧监控宝主站的主体架构映射，以及和子应用之间的关系。可以看到监控宝主站应用的是PHP语言，并且子系统也基本上都是由PHP搭建。其中应用了大量MySQL实例组成的多个集群，以及多个Redis实例组成的缓存集群。
当然，有的应用，不会像监控宝的架构映射得这么清晰。它们有可能是环形的，甚至是网状的。这在维护一个旧有系统，或刚刚接手的新系统时，是非常有用的。这里面用到的技术是偏底层的，即使用应用服务底层实现，语言底层实现，乃至系统底层实现。为不显干乏，这里先不细说了，有机会可以专就实现部分细聊。
另外一个不得不提的技术就是对数据采集的插件架构模型。由于Server端的数据指标多样性，意味着根本不可能使用同一个软件覆盖所有指标采集，也很难将各种指标进行标准化的处理，这都将导致整体研发迭代变得不可控。我们基于这个插件架构模型构建了透视宝产品核心的SmartAgent，内部戏称SmartAgent就像小时候玩的小霸王游戏机。
SmartAgent自带了OSAgent插件取得硬件物理指标，这就像小霸王自带的百玩不厌的小游戏；同时提供了”热插拔“接口，方便地对监控的插件Agent进行插装。
比如插了PHPAgent / MysqlAgent / NginxAgent，一个LNMP监控体系就完成了；插了JavaAgent / OracleAgent / TomcatAgent， 一个简单的JAVA监控体系就完成了；这在APM产品研发的过程中成为了非常重要的一个组成。
它将一个庞大的软件组成体系变得异常的松耦合，并提供了更多后续发展的可能性。
主持人：从很多的客户案例积累得出了哪些启示？
高驰涛：我们就”大数据智能实时分析处理“一点来谈这个问题吧。着重说一下用户提到的”多维度“分析需求和”散点“效应。
比如请求的事务数据：一个应用中的事务基本是不可枚举的，因为有各种参数的存在；那么在各种参数存在的前提上，怎么对响应时间进行分析？
这方面各厂商的做法：是这段时间内请求时间最慢的事务top10，这是相当不负责任的做法。为什么不负责任，客户的原话是这样的：我知道这就是我的top10，然后呢？天天说这个top10，周周说，月月说，这并不能反映我的应用健康状态。
我们需要关注的是，某段时间内，请求次数又多，响应时间又相对较慢的这些事务。于是你看，这里我们提出了三个维度的交叉：单位时间，请求次数，响应时间。
于是我们可以首先构思这样一幅矩阵图，X轴是时间，左Y轴是请求次数，右Y轴是平均响应时间。这些事务以向量散落在这个象限内，那么我们可以得出，距离XY的左原点，距离最远的，即是我们所关注的。后来经过抽象和产品梳理，得出了这样一个非常有意义的分析结果：
单位时间内，橙色的，即是我们要关注的对象。图上点击一下，就可以看到：
看第二个请求，往下深入钻取，又可以得到：
非常有效地定位到这个函数： Dispose::tool_ping。
整个项目对于事务的健康分析状况，一目了然，同时又可以快速地找到关注目标。基于这个原理，对SQL / API / 其他资源的请求分析，也是一样的。
诸如此类的情况还有非常非常多。
我们从客户这里得到的最有用的信息，总结起来是一句话，真真正正地从用户的角度去考虑问题，永远是没错的。这看起来很空泛，是真的非常有意义。
主持人：您怎么看国内外APM领域的发展？
高驰涛：APM领域国内起步较国外晚大约3年的时间，但差距在逐步减小。国外以NewRelic， AppDynamics为首的公司定位并不完全相同，NewRelic在关注2B服务的同时更关注2C的业务，而 AppDynamics则从始自终更关注2B业务。NewRelic已经在2014年成功上市，相信 AppDynamics也将在不久的将来上市。国外的APM领域极大地促进着中国本土APM领域的发展。今年听云在新三板上市，以及云智慧两年三连跳的飞速融资都是很好的佐证。
因为中国的IT基础领域较国外发展落后不少，企业信息化脚步一直在不停地加快，随着最近互联网＋的提起，国内也将有更多企业越来越关注APM所能给他们带来的价值，相信APM行业在中国的市场较美国更大，而且大很多。
主持人：您是PHP/PECL开发组成员，也是PECL/SeasLog 的作者，请结合这些年您自己在技术之路上的积累，谈谈技术人该如何做到高效学习和提升技能？
高驰涛：首先基础一定要打牢，学校里的东西虽说非常多在实际工作中用处并不明显，但它们无时无刻不在影响着你做的每一个决定；
最重要的是交流和沟通，技术人面对的其实并不是电脑或代码，而是与我们同处一个环境中的同伴，能够与同伴融洽的相处，不仅仅是生存技能，而是学习提升的最大优势；
然后才是一定要多参加社区交流，多思考如何为社区做贡献，开源战争最后最直接的胜利者，就是开发者。
主持人：请结合您的切身体会谈谈一名合格的CTO或技术团队管理者应该是怎样的？
高驰涛：这个题目有点大，呵呵。本职工作当然是勿须多谈的，保障公司业务稳健，保障技术团队发展；
我认为除本职工作之外，有一个非常重要的点，是大多数管理者不会过多考虑或经常忽略的，其实就是人，不是用人，是为人。说人格魅力影响有点虚，跟团队成员做朋友吧，而且要做好朋友，兄弟有难，谁不会伸手？
主持人：对想在技术路线上走得更远的人，您都有什么建议和忠告？推荐一些您觉得非常不错的资料或者书籍吧。
高驰涛：忠告谈不上，提两个小建议吧。
一般都会说技术人要趁早转行做管理，大体是没错的，不过得先认清自己是个什么水准，还是要多交流沟通，千万不能自诩如何；对于技术方向，面不要贪多，先就一点向下深掘，可以快速地成为一个方向尖子，然后再考虑横向发展。
推荐之美系列丛书，《架构之美》《数据之美》这一组；
另外推一本小但很有用的书《Getting Real》，这本小书对我的影响非常大。
互动环节：一般网站面临的问题就是负载的问题，当人数多，导致速度慢是主要解决的问题，对此您有什么建议？
高驰涛：并发问题比较常见，处理作法，一般会认为加CDN，横向扩展均衡池，业务中添加队列和缓存等等做法。总结起来有一个原则吧，能往前挡的请求就往前挡，实在挡不了再想办法将计算进行分发，如果要求实时响应，就考虑如何好地利用队列进行分片和阻塞。
另外将请求进行合并，也是非常有效的做法，因为大部分基于http的性能消耗有相当部分是属于协议握手部分的。如将静态资源请求的合并，如果有可能，将业务请求进行合并，也是很有效的做法。
互动环节：我这边问一个问题。刚才提到NewRelic更关注2C，AppDynamics更关注2B。请问2C和2B在APM的产品与服务设计上的侧重点存在哪些不同？云智慧的方向是2B还是2C？
高驰涛：2B更多的是需要售前，售后，实施等服务团队做支撑的，这也就意味着可以将产品的复杂度可以设计得更大一些，这并不是说会降低易用性，而是在能保证易用性的前提上，做更多的设计。
云智慧的产品体系比较完整，其中监控宝更倾向于2C方向，而透视宝和压测宝更倾向于2B方向。
互动环节：刚刚爬楼看完，看得有点小激动。解决了不少开发运维的痛点，前面提到终端用户，但是目前好像没有考虑移动app这块，更多是后台服务的。觉得移动这块也是一个非常大的市场。
高驰涛：移动这块我们也已经覆盖了。这次没有重点说。
问：哦，这样。移动是怎么做的？用户分析吗？
高驰涛：为移动开发者提供了SDK，解决移动终端的应用性能分析和用户行为分析。这是相关文档：http://www.toushibao.com/help/help_operation/152
想与业界大咖零距离沟通，欢迎加入CTO讲堂微信群，参与CTO讲堂！
【CTO讲堂第28期预告】
分享主题：密码泄露事件频发？探秘其背后的本质
分享嘉宾：洋葱创始人 吴洪声（原DNSPod创始人）
嘉宾简介：吴洪声 ，洋葱创始人，原DNSPod创始人，圈内人称“奶罩”，是中国域名行业、安全领域的知名人物，于2006年创办了DNSPod，经过8年的努力，将DNSPod打造成为了中国最大、全球第四的域名服务商，DNSPod也成为了域名解析的代名词。在腾讯以4000万的价格收购DNSPod后，吴洪声选择二次创业，打出“干掉密码”的口号，推出了“洋葱”，力图改变身份验证现状。
公司简介：赛肯（北京）科技有限公司(Secken，Inc.)创立于2014年10月，是一家专注于互联网账号安全和身份识别的云计算企业。
产品名称：“洋葱”，主要帮助网站、企业以及移动应用开发者解决密码安全问题和提高用户的身份验证体验。通过人脸、声音、指纹等生物特征取代密码，让人们可以不再依赖账号密码，快速安全地完成身份验证，并针对企业内网提供定制化服务，帮助企业实现“去密码化办公”。公司已经成功获得来自创新工场和光信资本的千万人民币的天使轮投资。
现阶段，国内还暂时没有同类型的产品达到同等水平。国际上功能相近的产品有：Authy、launchkey，但是他们主要是基于个人用户的使用场景,和洋葱提供的真人身份验证服务不同。
加入方式：扫描二维码加“C粉儿小助手”好友，申请入群。
还不是CTO俱乐部成员的各公司技术负责人，欢迎立即加入俱乐部：cto.csdn.net。
来源：CSDN
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！