小米大树part1:基础架构之痛

题记

无知和弱小不是生存的障碍，傲慢才是。 －－《三体》

缘起

一直想写一系列的笔记，记录整个小米六年的研发工作中实际遇到的困难，以及这一大群人如何不可避免的走向大公司氛围，又如何慢慢打破定势，苦于自己拖延症影响，现在才开始总结。

共分三个部分：基础架构之痛、测试之痛、产品进度之痛。本篇是第一部分。

基础

2010年，第一批服务器工程师来自五湖四海，有金山、微软、、百度、人人，唯独，没有来自最大互联网公司－腾讯。

A君（人物纯属虚构，以求表达效果）从业数年，经验丰富，说：“我觉得我们可以用一些php，简单好招人”，于是开始这样干了。

B君说：“我们还可以用一些java，招人也不太难，现成的东西多”，于是这样作了。

C君说：“的thrift也不错，我们需要一个这样的rpc框架”，于是用上了thrift。

D君说：“与客户端最简单，还是用http请求吧，加上json，调起来方便”，于是就http+json了。

E君和F君带来了先进的海外大公司经验，大家都深信不疑。

G君带来了maven，H君带来了git，I君带来了zookeeper，J君带来了memcache，K君带来了scribe，L君带来了hadoop，M君带来了HBase，N君带来了spring。。。

两年之后，诸君磨合成了以java为核心，诸多语言为辅助，看上去哪哪都大厂的基础体系。并且大家都认为可以为各兄弟无脑使用了。

问题

两年之后，人多事杂，诸君分为多个，多个都在共用着这一整套基础架构。

有一天，X君在调用Y君的接口出现了速度突然变慢了一倍，从10ms的速度变成了100ms（因为基础架构里没有可用性的计算，X君也是在用户投诉说最外层的API慢，分析之后才发现只有可能是这里慢了）。

X：“Y啊，你的服务不稳定啦，怎么慢了10倍，影响我们的服务啦”。

Y：“不对啊，从基础架构里提供的counter看，我们的服务一切正常，99.9%的请求，都在5ms返回了”。

X：“真的是你这边慢了，你再查查吧”。

Y：“可能是网络有问题吧，我们的服务真的没有问题”。

X无可奈何，Y也觉得自己没有过错，转身，X抱怨了一句：“TMD现在怎么这么官僚啊”。Y也莫名其妙：“草，A这的人太找茬了”。

Z君在网络，从交换机上看了一下图，“网络一切正常”。

这个技术问题就这样没有了结论。

原因

上述的场景在一天又一天演进，慢慢形成了所谓的大公司氛围，除非同一的人遇到了问题，很难将一个问题查到根本原因。

而X君遇到的问题，也没有专家团队可以帮忙解决，因为当年引入技术的专家们，分散在各个，在为各自的方向努力，根本无暇顾及。

靠前人拼凑出来的基础架构里，多年过去也没有可用性这样直接抽象的数据和监控报警。

X君之痛

根本的原因，是基础架构里，没有一个CTO的角色，从技术上进行抽象思考，从行政上强迫统一。

腾讯的前CTO张志东应该是个牛逼的人，带领老一辈的技术高人们，没有这么多开源的项目可以借用，所有的东西都要靠自己来抽象。

在没有开源行业的这个大保障（大包袱），腾讯的基础架构抽象得出奇的自然，再经过几代人的修补，已经坚不可破。

而X君这次遇到的问题，痛点在于：1.基础架构里的监控数据无法表达X君、Y君服务的可用性。2.Y君所参考的基础架构里的自身监控数据也无法认同X君说自己的服务不稳定的现实。3.X君和Y君，都没有意识到，网络也是服务的一环，而不是交给硬件和网络维护。4.X和Y君都在使用java，典型的gc问题就可能导致双方的数据全部不可靠。

打破常规

在第四五年的时候，已经开始有在打破上述的常规：

1.引入C基础架构，排除gc影响，提高吞吐。

2.主动调用方以承诺最大延时得出可用性数据描述被动调用方服务稳定性，并且双方达成一致。

3.除非有明确的原因分析结果，绝不把问题抛向相关团队。

4.每个环节，都有可用性数据，包括客户端。

一句话概括，对于互联网业务，可用性就是一切。

原创文章如转载，请注明：转载自五四陈科学院[http://www.54chen.com]

Posted by 54chen 企业

« 微信支付api.mch.weixin.qq.com域名解析慢原因：ipv6 小米大树part1.5:基础架构之痛答疑 »