过去六年在小米搞(wa)错(keng)的几个技术细节
2010年的时候，我们开始最早的一波做小米的服务器的同学，基本都很少互联网经验，七拼八凑的把米聊上了线，这么多年过去了，很多技术框架沉淀到了公司各处团队中去了。
今天再来看，其实有很多细节，当时真的没考虑（现在也是坑）。
细节一 用nginx的proxy_pass代理java上线不平滑
一个典型的架子，是nginx+resin/tomcat，然后在nginx上设置weight=1 max_fails=3 等等。
在上线的时候，并没有平滑过度的手段（比如修改一下所有nginx配置拿掉一台之类的），所有的上线都是有损的。
庆幸的是，移动互联网native的app，断个一两秒的不服务用户感觉不出来。
细节二 监控数据很多，有用的很少
线上故障的情况，不出意外就是一个模块和另一个模块之间发生了什么问题。
过去的几年，我们始终没考虑过抽象出来这种数据。
我们的监控数据全部是以单独一个模块自身的访问数据（qps、响应时长等），常见的问题是别人说访问你慢，访问老失败，你自己一看数据觉得还挺好。
细节三 为android ios配备了http框架
如果当时没有paoding-rose，我想我们会考虑做成一个标准的tcp server，中间用pb传输到手机。
这样做的好处，在应对不好的中国移动网络的时候，http束手束脚，而tcp却自由得多。
这一点我同样要点名嘲笑一个微博的客户端，在一样的坑里。
细节四 选java又没有语言级专家
如果当时选的是php，我想我们线上的服务在很多年后需要重启的会很少（由于nio或者其他什么泄漏之类的，最后服务就假死了，重启就能管很长时间）。
当然了，现在来看，更倾向于选c/c++，至少老老实实的写不会有太大的坑，跑起来也稳定。
细节五 过于依赖关系型数据库mysql
用mysql没有什么错，使用方便，实现业务快。
在中期要做多IDC容灾的时候，没办法了，实在是关系太复杂了，做不了。
如果当时我们全部有key-value的思想，将大量的mysql做的事情放在业务代码里来，做多IDC简直是小菜一碟。
而多IDC在一个互联网业务来看，上量了之后又是多么重要的一件事情。
细节六 过多使用rabbitmq
在需要削峰的项目上使用mq无可厚非，但是一个项目到处都在用mq的时候，简直是灾难（想一想，一个大系统，调用谁不清楚，谁在调用也不清楚，只知道自己在消费什么对象）。
后期的时候，要想知道一个模块正在被谁调用基本无从查询了，因为这些开源的mq，根本不会考虑实际运维中的需求，出发点全部是如何快速的使用。
后记
细节有点多，坑都还在(还有一些坑已经爬出来了就不列在这里了)，依旧有后继的团队和项目在坑里，如果一个项目立志要做大做强，还是一开始就跳出这些坑吧。
原创文章如转载，请注明：转载自五四陈科学院[ http://www.54chen.com ]
正文到此结束
热门推荐
相关文章
近期评论
-
666
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
