自我吐槽一下工作了8年了没有成为架构师也没有进入管理层没有成为技术大师也没能成为分享大师。一直在做业务并在这条路上越走越远。有的时候觉得很尴尬但又有的时候觉得还蛮适合自己。过年之前老婆生了一个小公举。宝宝饿了“老婆快来喂奶”宝宝又饿了“老婆快来喂奶”宝宝睡醒了又饿了“老婆快来喂奶”……老婆说“我感觉我就是头奶牛”作为一名“奶爸”感触颇为深刻!自己负责的项目就像自己的孩子孩子出事了大家首先想到的就是这个奶爸。奶爸上阵(常常半夜爬起来)该换尿布换尿布(服务器故障)该喂奶就喂奶(bug)。如果生病了就喂喂药吃药不管用就外面请大夫疑难杂症搞不定请别人搞定也是搞定。宝宝的奶粉如果出了问题恨不得拿刀宰了那个奸商调用了别人的服务服务挂了影响到了自己。宝宝吃饱喝足安静睡了奶爸也可以安心睡了-------------------------------------------------------------------------------下面开始干货记录一下自己的“育儿”心得一. 技术选型开发语言java,go,php,nodejs如开头所说本人之前是C#程序员C#的语法精妙逆天的ide.net版本更新较快快到我都不记得最新的版本号了。那么多新特性如果服务器上安装的始终都是.net3.5 对我们来说又有什么用呢。开始是很抵触java的断断续续学了好多次也没投入使用这次必须要上了。不得不说这么多年了java一直在增长稳定成熟几乎能解决所有问题而且性能也不差。这大半年下来java的水真的好深异步、并行等等还没接触过的好多好多。go的好处就不说了在学习如果喜欢又觉得能拿捏的住就上吧(哈肯定不会像说的那么轻松)。nodejs做前端太方便也有人用来做服务端接口层。php做前端页面就像服务端用java一样万金油成熟稳定用的人多资料也多。总之一句话没有最好的只有最适合的选java是因为 我们后端的很多微服务也是用java开发的方便调用。还有就是不用java还能用啥。存储mysql, mongodb, redis当分库都不能解决问题的时候分表就格外重要有一种无限扩展的感觉。之前用的oracle只分库没有分表hold不住了。存储的类型还是尽量越少越好redis做缓存一般是绕不过去都要用的。团队里有很多人排斥mongodb就不说具体原因了redis能搞定的事情就不要用mongodb了。还是那句话没有最好只有适合把相应的数据放到最适合的存储里。mq:rabbitmqactivemq你肯定会用到mq的即使现在不会以后肯定会的。java框架spring mvc用的人多成熟坑都被大家踩过了遇到问题好查资料好解决。ibatis和struts在我们的项目中没有用到。二. 源代码管理工具语言选好了框架选好了要开始写代码了问题来了写好的代码用什么管理Git!SVN!Git的分支真的可以解决太多问题很强大SVN的tag也不错用来做发布不错。不管用什么工具一定要做好规范比如git的分支命名。时间长了分支越来越多如果不规范一下会乱的一团糟。再比如分支的合并应该怎么合并不应该怎么合并。分支的流程去哪个分支提交测试去哪个分支发布等等。分支合并的冲突解决一定要事先沟通好不然代码丢失找都不好找。三. 开工1. 搭架子这里最好能把监控做起来监控太重要了一开始就要考虑清楚不然后面加会痛苦万分。如果打算用hystrix之类的框架一开始也要搞清楚实现方式后期实现太痛苦。2. 代码规范架构师一开始都会想的很完美如果不做规范来来回回人多了里面就乱了。当然即使你做了规范也会乱的只是会乱的小点。3. 一些基础代码比如打日志http请求怎么加监控怎么rpc调用接口在线查询文档等。4. 调试代码写完了怎么运行怎么调试本地是用jetty还是tomcat怎么发布测试服务器这些都要根据实际情况调整了。5. 开发工具现在说好像有点晚了对于java有的人喜欢eclipse有的人喜欢idea。再比如git的管理工具有人喜欢sourcetree, 有人喜欢敲命令就比较难统一了。6. 代码审查没事看看同事写的代码代码放的位置对不对有没有重复代码不要把你的架子搞乱了。Findbugs这个插件实在太有用了可以发现很多低级、没有预料到的问题比如可能存在的空引用String.format格式化问题等等。7. 团队沟通人多事情就会来肯定会有人遇到奇奇怪怪的问题这个时候就要一起沟通解决了。底层框架的问题要赶快修复优化。流程问题优化流程规范并通知团队。如果能有个wiki论坛之类的把大家踩过的坑记一下就更好了。定期开例会同步进步同步问题。四. 测试代码写完了需要有个强大的测试团队来测试功能了。我们的项目是接口对外输出json数据如果没有自动化比对工具全靠肉眼真的要疯掉。字段缺失大小写问题格式问题各种问题都会一一暴漏是时候再优化规范了。1. 自动化测试这个看测试实力了本人也不太懂有个测试大牛是多么的重要。2. 接口文档开发在做接口的时候就要把文档更新好修改代码及时更新文档。当然写文档太烦了java里的注解可以搞这些然后自动生成在线文档。3. 压力测试并发测试等做的接口能否支撑起业务怎么评估就要看压测结果。不达标优化五. 上线这个时候要想好怎么规范发布流程了如果公司有团队帮你做自动化集成发布就太赞了如果没有就只能自己撸了。什么jenkins打包脚本就自己搞起来吧。什么代码服务器和上线服务器不在一个机房里 没关系svngit帮你搞定。tomcat也有上传war包的功能。1. 申请服务器根据访问量评估服务器数量。要不要拆分接口比如abc接口只访问A服务器def接口只访问B服务器nginx接入层搞起来。2. 发布发布流程发布系统。是否需要灰度发布能否快速回滚。配置管理系统搞起来。3. 监控奶爸程序员最重要的工作之一就是看监控。什么调用量高峰调用量成功率失败率超时率平均耗时等等。最好能在线查看接口调用返回的code,可以快速定位问题。除了app调用你的服务的监控还有你调用别人服务的监控。一个是发现自己的问题一个是发现别人的问题撕逼和被撕逼都要拿出证据。失败率超时率平均耗时这些很有必要也是奶爸程序员的kpi。如果能有cpu,内存网卡使用率等的监控更好了。再进一步如果有jvm的监控那就更棒了监控都做了报警必须有短信、邮件你懂的4. 日志奶爸程序员最重要的工作之二甚至比看监控还重要。监控有延时有时候并不能及时发现问题这个时候看错误日志就很重要。系统是否正常运行就是通过日志来判断。错误日志会帮你发现问题甚至早于用户发现问题解决问题。奶爸程序员还要看日志是不是打多了打少了打错地方了重要业务日志有没有。这是个长期的过程根据情况逐步调整。观察线上服务器的日志是奶爸的重中之重先于用户发现问题先于客服事件解决问题保驾护航简直就是爹妈不容易啊!所以辣么多服务器你最好有个日志收纳系统在线查看筛选系统。5. 稳定保障nginx接入层在tomcat前面用nginx做接入层用nginx做分发对服务器做分组周边服务挂了不能影响核心业务。nginx还有个好处还是做转发比如你有个a.site.com站点要改版老版本的a.site.com域名不能动新版本的在别的服务器上a.site.com域名也必须用那么nginx接入层的作用就显现了把新改版的页面全部指向新站其他的回老站搞定。还有就是在你的后方有众多微服务各个微服务也可能会相互依赖如果其中一个挂了那么对你来说可能就是灾难怎么避免这种情况这个也是最近在做的事情搜了一圈都是在谈Netflix的Hystrix这个应该是比较成熟的方案了。熔断和降级只能保证微服务不会星火燎原但不能保证前端出现错误所以前端一起配合提供一些柔软、体验好的错误提示会更好。最后奶爸的工作当然不止这些了为人父母当然没那么简单了杂七杂八超乎你的想象。和产品谈需求客服事件排查和同事讨论技术方案和测试沟通改bug和领导汇报什么app又打不开了什么机房有故障什么有人在刷接口永无止境。。。------------------------------------------------------说几个自己踩过的坑1. 网卡被打满当第一次遇到网卡被打满的时候觉得很神奇有一种介于牛A和牛C之间的感觉。时日至今网卡被打满真不是什么新鲜事了。测试在压力测试的时候qps老是上不去后来发现是压测机的网卡被打满了。服务崩了缓存服务器网卡被打满了单key存储的东西太大。总结网卡被打满是不得不考虑的事情尤其是你来来回回传输的东西既大调用量又高。解决办法就是单key的值不宜太大而且不论是什么缓存随着值大小的增加性能是急剧下降的所以能拆就拆现在都是分布式缓存key越多各个服务器就越平均,key的增加对性能的影响微乎其微。2. tomcat老是被重启一到高峰期tomcat就噼里啪啦的自动重启找不到原因啊奶爸遇到挑战了。就像前面说的孩子生病了你有的药吃不好那就请大夫开方子请别人治好也是康复啊。后来在tomcat重启的时候做了dump和tcp监控后来发现tomcat在重启的时候time wait过多推断出某个服务的调用出现了性能问题积压太多累积到一定程度就爆炸了。后来是增加某服务的rpc调用的连接数搞定了。还有一点就是synchronized关键词的使用要小心小心出现性能问题会堵塞。3. 监控曲线突然没了曲线突然没了掉成0了顿时吓尿了赶快排查日志发现在上报监控的时候报错了上报的线程的挂了。改呗上报错了就错了不能制造惊魂啊-----------------------------------------------------------------