架构师俱乐部第二期活动要点速记
EGO
赵海平分享： 来到阿里巴巴技术保障部后做的一些事情和开展工作的思路。
主要的职责和使命是对阿里系统和框架进行性能profiling和调优。
第一步是对整个平台和框架进行profiling，发现大头（性价比最高）的问题去解决。已经了解过内部做的一些profiling工具，但是很零散。他牵头做了一个代号是太极的项目，希望开发一个能实时的、从大到小、自上而下查看整个业务系统情况的工具（从集群到机器，到具体进程，到执行的函数，进而具体的代码段位置甚至这段改动的作者），因为这样的反馈能够最好地帮助定位问题并帮助工程师成长。
希望衡量的主要指标有wall clock time、CPU time、memory、disk IO和network IO。前三者为主，后两者是次要指标。profiling完成后应该能识别一些优化的机会。
优化的思路可以分为三个层次：第一层是局部优化，修改性能较差的代码或SQL语句、加缓存等，把不好的问题改好；第二层是架构优化，采用新的架构以更适应业务发展对性能的需求，是把不好的、不需要的去掉；第三层是底层优化，包括对语言、虚拟机（如JVM）甚至系统kernel针对阿里的实际应用场景进行优化。
这个过程中需要注意的是，在做profiling创造透明度和给系统增加额外的overhead之间需要找到一个平衡。考虑从底层的jvm入手，对整个集群做广泛地sampling来得到可信的观点，整体的overhead要控制在毫秒级别。
惠新宸分享：关于优化的一些想法。
- 在进行性能优化前，先要有一个判断，系统是不是健康的或者最优的。最优的程序是没有分支、没有内存读取、遵循最小数据库读的原则。
- 有没有万物皆准的优化方法？其实是有的，比如加缓存，但其它优化需根据系统情况决策。
- 有一个说法叫做微优化都是邪恶的，这是因为局部优化可能会把代码搞的很复杂，可能得到的收益很小但是带来的风险却很大，所以需要事先评估。
- 优化不是靠专门的架构组能够解决的，需要所有员工都有优化意识,自觉的收集性能数据以便将来分析和优化。
- 优化都有连锁反应。做了底层优化，会带来其它的优化机会。
- 优化前要有准则，避免可能的人为操作。
- 开始优化之前就要知道何时结束。因为优化越到后面边际收益越小，当收益不足时要果断调整方向。
讨论问题：
- 虚拟化和容器场景下性能分析如何进行。这个和一般的集群下性能分析差不多，收集单机数据以及VM/容器中相关API数据，在单机下再分为多个VM/容器即可。
- 分布式平台的profiling怎样做到跨应用的事件追溯。为分布式系统中的每一个单机或者子系统进行标记，以实现整个业务流程的可视化。必须有一个类似于TraceID的全链路追踪的机制，实现方式和UID差不多。
- MySQL在分布式系统的架构设计和调优。MySQL是否被滥用/误用？MySQL多被用做数据持久化和存储，但它的特性是支持transaction的ACID。MySQL调优手段有限，基本就是sharding，对分布式系统的支持也有限。
- Facebook的OCP和分布式系统如何集成，对性能有何影响。OCP的设计主要是在硬件层次，对软件设计和性能优化的影响几乎透明，不用考虑这一层。
- Profiling的基准benchmark如何选择及构建。没有benchmark，是和之前的系统性能进行对比，另外，尽量将更新分小，以得知每一步的优化得到的效果。
- 如何建立实时的profiling系统。实际上做不到完全实时，但可以做到准实时，其程度在于对系统进行采样的频率。考虑到过多采样对性能造成的影响，可以考虑在更大范围的集群和机器上进行采样来保障客观性。
- 能在多大程度上容忍profiling的系统开销。要看对profiling的需求。
