技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> 系统架构 --> 过去六年在小米搞(wa)错(keng)的几个技术细节

过去六年在小米搞(wa)错(keng)的几个技术细节

浏览:982次  出处信息


  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,根本不会考虑实际运维中的需求,出发点全部是如何快速的使用。

后记

   细节有点多,坑都还在(还有一些坑已经爬出来了就不列在这里了),依旧有后继的团队和项目在坑里,如果一个项目立志要做大做强,还是一开始就跳出这些坑吧。

QQ技术交流群:445447336,欢迎加入!
扫一扫订阅我的微信号:IT技术博客大学习
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1