这两天参加了ArchSummit 2018 北京站，流水账似的记录下感受吧，包括一些参会的流程和注意事项。
1. 关于架构的思考
Keynote 里，Google TensorFlow 中国研发负责人的演讲让人印象比较深刻，演讲的主题是《关于架构的思考》，主要介绍了几个维度去思考架构：选型、可扩展、易用性，特别提到了来自G家的 protobuf, grpc，可见基础的重要性。其实看到这个题目的时候就觉得很亲切，因为前段时间刚好写过一篇相同题目的文章，记录了自己读阿里中台架构改造一书的感想。
作者还特别提到了《纽约客》最近发表的文章， Jeff Dean 和 Sanjay 和架构设计里分别擅长的不同领域：
桑杰住在山景城一个三居室房子里，而杰夫则自己设计了房屋，在地下室里装了一个蹦床。在设计房屋时，他发现自己虽然喜欢设计空间，但并没有耐心去完成建筑方面“适合桑杰的部分”：横梁的细节、螺栓以及供电量等等。
目前，他正在开发一款软件，允许工程师轻松整合和管理十几款应用程序。如果把谷歌比作一所房子，杰夫是在建造一个附加产品，而桑杰则在支撑结构，加固房梁，拧紧螺丝。
架构里另外一个比较常见的问题是何时重构，大牛介绍说，即使在 Google，由于人员流动变化等，几年也会对模块进行一次重构，不过由于内部完善的工具、文档、单测，重构不会那么复杂。
2. 业务驱动、抽象
听了几个演讲，很多都强调了业务驱动，例如滴滴的 Fusion 以及阿里的 OceanBase，架构的演进离不开对业务的深刻理解，以及在改造过程中的不断review和找到真正的重点。这句话不同的读者看到，一定会有不同的理解吧。
3. 基础能力
基础能力也需要不断提升，例如对 leveldb/rocksdb 里 memtable sstable compact的流程理解，能够单独使用一个控件或者流程；能够对paxos/raft 的流程深入理解，从而在两地三备份或者三地机房的场景，优化现有开源方案。另外就是架构不要被业务牵着鼻子走，理解业务然后提升基础能力，例如追查 core/oom 问题的能力，做架构切忌追逐短期的收益，一看难度大收益不明显就不做了，这种心态做出来的架构并不会比算法同学搭建的架构要强。
阿里王坚博士在2017年 ArchSummit 的演讲上说：“好的架构是包容所有好技术的重要前提”，模块稳定性解决不了，怕是什么技术都包不住。而这些疑难问题，从我的经历看，真的可以提升基础能力，帮你度过一个瓶颈期也是有可能的。
4. 总结
他山之石，可以攻玉。
例如听 Dubbo 的汇报，我会对比现在的 rpc 框架、服务发现、服务治理上是否也存在类似问题；听别人对于 Paxos/Raft 的使用，会思考自己是不是不够灵活，没有做到举一反三；听别人对于数据通道的建设，想到自己在做的事情。
有一些也会触发更远见的思考，例如还没有使用 kafka 的使用经验，看到已经有人在拥抱 pulsar 了；当你还在纠结存储选型时，大牛已经在考虑生态了；当我们还在大数据上积累经验时，已经有人在考虑其中的安全问题了；这些固然不能盲从，但是都要提前了解，拓宽视野。
关于参会流程上，两个会议中间时间比较短，建议提早占座。会议前，一定根据题目、简介、演讲者及其公司，提前规划好参会流程，务必都完整听完一个演讲，不要换着听。有些题目很好，但是文不对题，因此要看简介。或者演讲者表达能力有限，受益很少。也要根据自己的状态，选择听些难度大的，还是网红课程。
总的来说，有了一次参加过的经历吧，学习知识，提升自己的作用不大，因为有大把的公众号文章和视频，就像在家自己健身还是要去私教的健身工作室，见仁见智。当然，见到一些大牛的风采，多参加这些线下活动，就是另外一个作用了。