是技术分享而不是培训

通过甲方的反馈，我了解到他们已经在实施微服务了，但是生产上很多瓶颈都是在数据库。因为我再三思考，把这次分享的核心重点放到[数据库性能优化]，对于后端开发来说，无论去到哪个公司、哪个团队，遇到任何的系统，数据库性能永远是大家遇到的第一个瓶颈，如果说能把优化方案了解清楚，我相信能解决日常问题的80%甚至90%，我一直是这么坚信的。

其次他们实施了微服务，另外也希望跟我沟通下微服务拆分这块的经验，因此我认为以微服务的补充跟他们的实践做个碰撞。

虽然甲方是希望我过去做的叫培训，但是我从接到这门活起，我把它定位为技术分享交流。为什么我不愿意把他们作为一个培训呢？

1.我希望这次一个平等的姿态，站在跟甲方的同行们同一个水平线上交流。

2.我坚信闻道有先后、术业有专攻，每个人都有自己的擅长和熟悉的领域，而能力与知识是可以随之沟通、阅读、实践而增长，并不是一成不变。

跟上一次微服务培训一样，我仍然准备了三件套：Word讲义，PPT课件，现场讲解视频。我认为这种是对客户的一种尊重与责任，也希望我日后能这么坚持下来。

寻找自我认同感

读到这里相信也有不少读者对我这次技术分享的价格是非常好奇的。

对于技术的分享，我一直都是保持着非常开放的态度和别人交流的，可以说知无不言，包括我所写的各种文章，都是基于当时我的经验与认知，毫无保留的写下来。相比于课酬，我更加看重的是那种虚无缥缈的成就感，自我认同与被认同。这也是促使我坚持写博客的原因之一。

一般这种培训、技术分享的课酬也就几千。不少人认为只要一两个钟头就能赚到这么多，这个时薪也太高了吧。

其实，像我这种偶尔来一次活的，在准备讲义、课件的一般要一两个星期，线下分享前还得自己私下演练一遍，保证演讲的流畅性，从时间和精力的投入来看，其实性价比并不是很高的。因此如果把关注度放到“钱”这方面，也许会让自己有所失望。

但是，我把每一次的机会当成了自我提升、自我总结、自我突破的过程，那么动力源就不一样了。另外也有朋友会认为，我把知识传达给了别人，受益较多的会是对方。然而真正经历过做技术分享的朋友或许知道，真正受益良多的是做分享的自己，因为准备好传达正确的知识与材料的时候，不得不去把之前自己认为模糊的知识点给了解清楚；为了让对方很好的理解，不得不去把曾经的零散的知识与经验梳理并总结。

回忆之余不得不感叹费曼学习法的强大之处。

共鸣

此次分享的话题，以数据库为主，微服务为辅的，整个分享过程与甲方同行有来有往，并在我分享一些我的经验总结与独特看法的时候，明显的能得到对方不少同行的认同与反馈。整个过程非常的愉快，通过对方的提问，我也思维发散的把自己在准备时遗漏的一些知识点，补充并传达到给了对方，这次技术分享的成功，少不了甲方团队的同行的配合。

一个巴掌拍不响的。

与第一次做微服务的讲师相比，我自认为我的口才并没有得到很大的提升。那么能让这次技术分享的成功与第一次比有什么不同呢？

1.内容更加接近甲方的实践，让甲方身临其境。

2.数据库优化相比于微服务整套架构更加易于理解。

3.甲方团队的技术平均水平相比之前的高，吸收知识自然更快速。

4.整个分享时长相对合理（讲2个小时，剩余沟通交流，之前讲微服务6个钟)

这一次经历也深深的让我感受到，分享的内容不在于有多高大上，而在于是否贴切到对方团队的实际经验，只有双方存在了共鸣，才会激发大家的沟通与交流。