一、服务化后业务运营遇到的挑战
1.每天千亿次级的服务调用中出现报错时的问题快速定位
2.运行状态的实时监控服务
3.服务于运营团队精准营销的业务指标实时呈现
如何结合团队管理？
在服务化场景下为了快速定位问题，如何管理服务开发人员？
1.影响KPI：线上服务稳定性直接影响开发人员KPI
2.服务开发人员(服务owner)需要关注的2个点
（1）我的服务在什么链路下被调用，调用的场景和数据是否合理
（2）目前服务调用趋势怎样？产生的瞬间峰值有多少？是否达到服务能力的最高水位？
3.业务架构师需要关心和思考的问题
（1）在当前的业务流程设计中，我的服务依赖了哪些应用、哪些服务？
（2）整个链路的依赖路径是怎样的？哪些服务对当前业务处理来说是最为核心？这些依赖如果出错，会有什么影响？
（3）一次业务请求处理的时间到底花在了什么地方？是因为某一个服务耗时很长，还是某一个数据库的访问操作耗时最久，需要有一个清晰直观的定位
（4）我所负责的业务链路中，过去一段时间哪些服务是出错率比较高的，哪些服务是业务链路的处理瓶颈？
小结一下
（1）梳理依赖和依赖间的关系
（2）链路耗时和出错追踪及瓶颈定位
二、运行状态的实时监控服务
鹰眼——阿里基于分布式日志引擎的分布式服务调用链跟踪平台
业界类似平台
Zipkin——Twitter
Dapper——Google http://research.google.com/pubs/pub36356.html
三、鹰眼日志埋点
四、TLog中间件
特性
根据用户定制的处理流程
持续不断地对目标机器生成的日志数据进行解析、计算、入库等操作
“所见即所得”的可视化配置界面（Google Blockly）
零业务侵入（预先日志埋点）、高性能（http://jstorm.io）、强实时性
可以方便编排的日志分析模式
这里基于Google Blockly完成的日志分析模式的编排比较有意思。虽然Google Blockly最初只是一个用于低龄儿童学习编程的图形化编程语言，但是可能是由于它的架构本身比较利于扩展和二次开发；因此可以方便的定义“programming”意外领域的规则范式。除了TLog中使用的面向日志分析模式编排的，Blockly甚至可以用来解迷宫。https://developers.google.cn/blockly/
我感觉Blockly是提供了一个思路；而且这个jigsaw-style的前端确实蛮有趣的。其在TLog中的应用我觉得是比较深入的借鉴了Blockly的基本想法——通过可视化的方式靠谱的传递某个领域模型(domain model)下的逻辑。在Tlog的日志分析场景下，生成的自然就是类似于awk ‘{print x,
x
,
y, $z}’；而其中的“规则”在不同的领域模型下是可以被重新定义的，比如给的demo就是在“编程”这个domain下定义的各种if else… 那么就生成代码；甚至利用这个“可视化规则”还可以生成跑迷宫的算法。总之，我觉得可以认为Tlog对于Blockly的应用可以认为是在形式逻辑具体化方面给出了一个有着具体HCI的建议，类似的还有Drools以及它built-in的可以直接读取.xlsx形式定义的规则。
五、业务应用场景
1.服务实时监控
解决问题：细化到服务粒度的监控
2.服务调用链跟踪
调用链跟踪的详细信息表头参考
服务名及嵌套调用关系
服务器IP地址
服务调用类型：HSF-RPC、Tair缓存访问、访库
服务调用结果（按服务类型会有不同枚举值）：OK、TIMEOUT、NOTEXIST
产生数据大小
具体服务和方法
处理时间
3.服务调用链分析
根据调用链跟踪数据定期对服务调用数据进行统计和分析（for 业务架构师）
调用链分析表头参考
服务嵌套调用层次关系
调用的服务方法、所属应用、资源（数据库、缓存、文件系统）
QPS当前值和峰值
调用次数计数
平均耗时
本地耗时
依赖度
占比
强弱依赖标记
4.业务全息排查
关键信息字段
TraceID
RpcID
(New)DataKey
业务事件发生时间
(New)业务主键
被查询的业务主键字段
(New)业务详情记录
键值
5.业务实时监控
