参加SACC2015有感

    机缘巧合.从ITPUB小鱼管理员那里得到了一张SACC2015的赠票.
    作为一个从业一年半的DB菜A,三十出头的小伙子,有幸如此近距离的聆听众多大公司平均四十岁左右的一线技术高管教诲.确实收获巨大.
    子曰,学而时习之,不亦说乎;有朋自远方来,不亦乐乎;
    平时自己学习,有收获,有心得,内心有喜悦.但是毕竟自己周围的圈子小.容易在方向上陷入迷茫.也可能陷入 有虽多闻,而增上慢 的境地.
    所以有机会参加SACC的大会,非常的开心.
    近距离接触这些业界大牛,比如田琪,吕海波,沈剑这些老师,非常平易近人.有几个问题可能问的非常幼稚,吕老师还是很耐心的都解答完了.
如果要突破自己,不仅要学好武功,更要注意修为.
    上善若水,善利万物而不争,这些还是需要我慢慢去领悟的.

    结婚之后去云南度蜜月的时候,我给自己寄了一封三年以后收到的信.希望自己三年之后,有可爱的孩子,并且可以转型成为DBA.当时觉得这些目标好遥远,似乎我也不曾真正相信自己可以实现.
    今天的生活是因为你三年前的选择，而今天的选择，将决定你三年后的生活。
    人生的每一个点,都是过去的未来和未来的过去.
    假如自己站到了人生的终点,回望过去会有什么想法呢.
    是不是有一些事情感到后悔?
    某些重要的节点,是不是希望处理的更加妥善一点?
    发现自己荒芜的虚度了一生?
    还是希望自己和数据库一样,也可以FlashBack一下?
    当自己面对困难和感到迷茫的时候,闭上眼睛,幻想自己从人生的终点穿越而回,了却未了心愿.
    向死而生给了我莫大的勇气.从大学留级一路跑到现在,克服了很多的困难.
    今天面对的困难更加复杂,无论是工作的压力,学习的瓶颈和家庭的琐事.
    但是一定要牢记烦恼即是菩提,一体之两面.
    都说养男孩就像养猪,自从有了小花狸,他一直就是我的掌上明猪。
    既然都说有恒心无恒产,我要把自己面对困境时候的迷茫,绝望,彷徨,无助,以及最终如何走出困境,克服困难记下来.不要随着时间而忘记.
    这也是人最有意思的地方,不断克服困难,把自己从一个level激发到另一个level.

    SACC的一位架构师说的挺有意思,他说一个人刚毕业的时候,用全部的24小时,转工作这个圈.
    这个工作的圈越转越大,越转越快.
    等到二十八九,有了女朋友,有了家庭.还是同样的24小时,就需要同时转两个圈.
    工作上的努力,领导一定会奖励,重视.这样工作的圈会越转越大,越转越快
    而相反,家庭的圈会越转越慢,越转越小.
    等三十五,四十岁的时候,已经大致是高级工程师,架构师的级别.
    由于边际效应,知识已经很丰富了,有些自满,导致技术好奇心下降,这样工作的圈会慢慢降低转速.
    这样工作圈,家庭圈不匹配,就会造成中年危机.
    我对这个问题,也有一些思考.我觉得一开始就要平衡两个圈.另外,一旦工作圈转速下降,一定要去SACC,DTCC这种大会开眼界.看比自己Level高得多的人.
    孔子无友不如己者,也是这层意思.

    滴滴支付架构师说的一个问题,也很有意思.他们的业务一定要保证可用性,一致性.他入职的时候,面临业务代码和支付代码耦合的情况。业务变化很快,从出租车到专车,班车等各种车.
他们就像是在飞机上边飞边修发动机..后来,他们采用分库分表,结合分布式事务.提供了高可用一致性的支付服务.
    有意思的是,他们采用分布式事务,2PC.一般认为2PC有性能问题.但是恰好在滴滴支付的业务中,不存在这个问题.因为每个涉及支付的乘客和出租车师傅,不会有并发锁的问题..
    所以,采用何种技术更适合业务,体现了架构师的功力.
    另外,他们的支付业务本身并不复杂.仅仅是实现几种支付的原语.所以他们没有使用任何框架,什么Spring,OR Mapping,MVC框架,都没有采用.甚至禁止使用继承.就用最简单的JDBC+SQL.
    这样的好处是,简单,也方便DBA调优、审核.

    有相同观点的是腾讯文学的架构师,他说简单即是坚固.他有意思的观点是慎用开源.
    我估计他说的应该是国内公司开源的那些框架.TDDL,Dubbo之类的.
    他说你采用了这些框架,耦合在代码里面,一旦出现了问题,难道要我去找马云吗?如果你没有看过这个开源项目源码的80%,有二次开发的能力.就不要找他说用开源的事情.
    他的观点挺有意思,估计是认为国内的公司做开源不靠谱.后期维护很成问题.

    吕海波老师的题目是关于去IOE的.
    有意思的是,我听他讲完觉得还是用Oracle更好..
    吕海波老师认为一旦MySQL数据量和Oracle一样大,必然拆库拆表,用更多的PC服务器.
    这些运维,数据库管理,机房,机架的成本,其实并不便宜.

    可以明显的感到
    没有任何一场讨论过Mongodb的应用.
    Docker很火
    关系数据库是架构核心中的核心
    写得一手好SQL真是太重要了
    
    这几天我也想了想自己在优贝在线的发展.虽然有各种机缘,不过公司愿意聘任一个没有任何经验的人做数据库管理工作,莫大的信任.自己的水平确实也比较弱,最近几次宕机事故,处理的都不算好.
这个月线上连续遇到事故,自己特别害怕.程序有漏洞大量全表扫描大表,连接池使用不当,验证码被攻破大量注册广告帐号,程序设计不当被攻击.天天胆战心惊.作为几个库的守门人,一般问题到了这里,都是来势凶猛.往往在数据库不容易处理,回天乏力.毕竟程序在那里,设计在那里,数据库层面处理起来相当的被动.
    我希望以优化为契机,推进代码的服务化.这样从长期来看,会从根本解决数据库的问题.目前想到的有几点.
    1.通过AOP在程序中采集性能数据,rpc到集中日志服务器.做一个简易的APM
    2.定期在测试服务器做HTTP流量回放.将问题屏蔽在测试阶段.
    3.业务日志通过rpc服务,统一在集中日志服务器存放,定期刷到Hadoop集群.
    4.log4j,Nginx日志定期刷到Hadoop集群.打通这些通道,Hadoop集群就可以真正的用起来.
    5.统一处理点击,排行等功能.
    进而逐步推动应用Docker化.
    作为我在这个单位的发展,我希望是
    Oracle,MySQL,MongoDB,Redis管理员
    负责程序性能优化
    负责程序SOA推进
    Hadoop程序员,管理员
    负责Docker化之后的运维管理.
   
    主要是以优化入手,调整程序的结构,最终减轻数据库层面的压力.
    虽然看起来还比较远,我希望用三年时间做到这些.
    参加SACC也帮助我梳理了一下思路.也设立了一些更长远的目标,比如5年之后可以成为运维帮,OneAPM技术分享沙龙的主讲嘉宾.10年之后,也能成为SACC这种级别的演讲嘉宾.
    从工程师到架构师的蜕变.我感觉主要体现在沟通和交流能力.在这次SACC大会中,可以看的很明显.
    但是首先,我要克服自己不自信的缺点.要像一个大将一样,扛得住事儿.

    感谢小鱼管理员提供的这次机会.从不多的接触中,能感觉出她敬事而信的工作态度.
    祝新单位工作顺利.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29254281/viewspace-1816244/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/29254281/viewspace-1816244/