自我介绍一下，本人以前是.net程序员，去年下半年负责把项目从.net转到java，并且有跨机房迁移，亿级访问量，app服务端项目。
  自我吐槽一下，工作了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: rabbitmq，activemq
你肯定会用到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，打包脚本，就自己搞起来吧。
什么，代码服务器和上线服务器不在一个机房里？ 没关系，svn，git帮你搞定。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了，顿时吓尿了，赶快排查日志，发现在上报监控的时候报错了，上报的线程的挂了。
改呗，上报错了就错了，不能制造惊魂啊！
  总结：

  以上都是本人的一些经验心得，可能对你来说没什么特别，也只能说鄙人才疏学浅，跟不上技术发展的脚步。如果你有更好的，请不吝赐教，大家一起成长！
以上的所有东西，对于小公司小团队，或者从无到有的项目还是很庞大的。监控系统，日志系统，运维，发布，到处都有坑让你踩。我们目前所用的rpc调用方案、缓存、mq都是第三方的，虽然有技术支持，还是踩了很多坑。
坑到处都有，我们要做的就是踩到坑了不摔倒！
    文/昵称：往边界
来源：博客园