有关“架构师”

昨天参加了云栖社区开发者技术峰会——架构专场,会议议程包含了分布式系统,容器,混合云,机器学习中蕴含的架构思想。
这是架构师最好的时代。物联网、移动、云计算、大数据、人工智能等等新兴领域,都包含着背后架构师的思想、设计、技能和经验。

阿里云大数据计算平台资深架构师林伟带来的分享《我看分布式系统架构设计和阿里实践》最后提到了一个架构师的基本素养:

  • 熟悉各种资源的原始特性
  • 知识面宽
  • 大量阅读各种系统代码,汲取营养
  • 实践出真实,大量的coding
  • 两个数量级的性能变化就需要系统的重新设计

恰好前两天看到 曹政@caoz的梦呓 的一篇文章,里面提到这样一个细节:

1
2
3
4
5
6
7
8
9
10
11
12
13
案例2:看似正常的负载过高

当时有个新业务数据增长很快,该业务的数据库服务器每天处理数百万次数据查询请求,uptime比较高,经常在5-6的样子,cpu负荷较重,运维负责人就发邮件,申请更换更好的服务器,增加资源。

按理说,这是个合理请求,负载也确实很高,业务也确实增长,但我这个人天性财迷抠门,总觉得这个数字不应该是极限,就登录到数据库服务器看了一下,很简单,我的方法就是先刷show processlist,连续刷几遍,看数据库都在执行啥,开销都集中在什么状态,这一看还真就发现问题了,居然经常看到有些mysql进程停留在 storing result to query cache 上。

这事我就纳闷了,因为按常规,这个状态应该是基本没有时间开销的,也就是show processlist看到是小概率事件的。

所以就要验证一下,执行 set profiling=1,然后从show processlist复制一条执行一次,然后执行 show profiles for query 1; 结果意外发现,常规来说执行开销最大的sending data (这个开销可不是输出数据哦,其实是io寻址)只有0.002秒,而 storing result to query cache 却执行了 0.005秒的样子,千分之五秒,一般人可能就无视了吧,但整个SQL执行不到0.01秒,这个开销比例蛮大的了。

那个,其实这个问题的责任者呢,是我自己,我觉得query cache是个好东西啊,所以开始配置服务器的时候,还是我自己做的配置,因为服务器内存够大,我就把query cache设置的比较大,结果SQL的反馈结果内容较多的情况下,就出现了query cache的碎片化比较严重,反而导致了query cache存储额外的开销,我在数据库里直接操作将query cache内容重置的命令,再执行这个SQL,用profiling去分析,发现这个开销就没有了,负载瞬间显著下降了60%左右。

然后我跟运维负责人说,半夜没人的时候把数据库的启动参数,query cache那块设置回默认值,重启一下数据库,于是就没再追加预算和服务器投入。

想想有的时候自己经手的项目,都是达到能用的程度之后,就没有再投入时间去自己维护和完善,对于资源和性能都没有仔细分析,只是一味的想通过提高机器配置的方式来解决问题,实在没有一个称职的架构应该有的“抠门”

感谢林伟的分享,有醍醐灌顶之感。

后面继续努力,希望在架构师这条路上走的更远。