3个中国程序员 vs 3个美国程序员，差距太大了

　　大概是2009年，我和两个好哥们聊天，觉得智能手机可能是风口，商量着要弄一个照片分享网站。

　　用户可以用手机把随手拍的照片放到网上分享，名称都起好了，叫InstantPost。

　　可是我们的执行力太差了，聚了两次，做了一点儿技术验证，就没有下文了。

　　过了几年，我看到美国一个叫Instagram的火了，不由地一拍大腿：卧槽！这不就是我们当年要做的事儿吗？！

　　后来我看到Instagram初期的故事，他们也是三个程序员，从2010年10月到2011年12月，在一年多的时间内，就把用户数量从0增长到了1400万！

　　看完他们的架构设计，我就释然了，抛开执行力，在2009年那个时间点，我们确实不行。

　　Instagram制定的架构指导准则是：

　　1.保持简单

　　2.不要重新发明轮子

　　3.尽可能使用经过验证的可靠技术

　　所以早期的Instagram跑在云上，使用EC2和Ubuntu Linux 11.04。

　　接下来，站在一个用户会话(Session)的角度，来看看Instagram的处理过程。

　　Session：用户打开了Instagram APP。

　　2010年，Instagram开发了一个iOS app，正式推出。

　　因为这时候Swift还没有发布，他们用了Objective-C，UIKit等技术。

　　负载均衡

　　Session：打开App后，会向后端发起一个请求（获取主界面的“信息流”），这个请求会首先到达Instagram的负载均衡。

　　Instagram 最早使用2个Nginx并在它们之间进行DNS Round-Robin，这种方法的缺点是，如果某一个机器出现故障，DNS的更新需要时间。

　　后来他们选择了Amazon的Elastic Load Balancer，这里有三个NGINX实例，可以换入换出。

　　后端

　　Session：负载均衡会把请求转发给应用服务器

　　Instagram用Django作为后端服务，运行在 Amazon High-CPU Extra-Large 上，因为这三个程序员发现，后端服务是CPU密集型的。

　　用Gunicorn做WSGI Server。

　　应用运行在超过25台亚马逊虚拟机中，这些应用都是无状态的，可以在需要的时候进行扩展。

　　为了在多台机器上运行命令（例如部署代码），Instagram使用了Fabric，它有一个很好用的并行模式，部署只需要几秒钟。

　　数据存储

　　Session: 用户请求到达了应用服务器，接下来它需要获得这些数据：

　　1.最新的Photo IDs

　　2.这些Photo ID对应的实际照片

　　3.这些照片的用户数据

　　Database: PostgreSQL

　　Session: 应用服务器从PostgreSQL获取最新的Photo ID，这里保存着用户和照片的元数据。

　　大部分的数据，如用户，照片元数据，标签等都保存在PostgreSQL数据库中。

　　因为数据量不小，每秒钟有25个照片上传，并且有90个赞，Instagram对数据做了分片。

　　分片系统由数千个逻辑分片组成，这些分片在代码中被映射到少得多的物理分片，用这种办法，可以从少量的数据库开始，扩展到更多的数据库。

　　当扩展时，只需要把逻辑分片从一个数据库“指向”另外一个即可，无需挪动任何数据。

　　一个挑战是：Instagram如何解决Photo ID问题，因为需要能按时间排序，而无需获得有关照片的更多信息，理想情况下，ID应该是64位的。

　　后来的解决方案是这样的：

　　41位：记录毫秒时间

　　13位：逻辑分片ID

　　10位：自动增长的序列，模数1024，这意味着每毫秒，每个分片可以生成1024个ID

　　最终结果是个64为整数，可以被PostgreSQL排序，找到最新的照片。

　　照片的存储：S3 和Cloudfront

　　Session: 获取了Photo ID以后，应用服务器要获取真正的照片，快速发给用户

　　照片保存在Amazon S3中 ，存储了几个TB的数据，通过使用CDN（Amazon CloudFront ），照片可以快速分发给世界各地的用户（例如日本，是Instagram第二大受欢迎的国家）

　　缓存

　　Instagram 需要将大约 3 亿张照片(ID)和创建它们的用户ID的映射保存起来，以便知道查询那个分片。

　　他们选择了Redis后发现，为了保存这些映射，Redis需要21GB内存，这已经大于 Amazon EC2 上的 17GB 实例类型。

　　后来他们向Redis的核心开发人员Pieter Noordhuis求助，Pieter建议使用Redis Hash，最终通过巧妙的设计，这些映射仅需不到5G的内存。

　　对于其他缓存（如session），Instagram使用Memcached，当时有6个实例。

　　数据备份

　　无论是PostGreSQL还是Redis，都会使用Amazon EBS经常性进行数据备用

　　通知和异步任务

　　Session: 用户关闭了App，但是朋友发送了一张照片，需要发送一个通知。

　　Instagram的推送服务用的是 pyapns, 这是一个开源的、通用的苹果推送服务提供商，运行非常稳定，为Instagram处理了超过10亿条推送通知。

　　Session:用户非常喜欢这张照片! 他决定在Twitter何Facebook上分享。

　　在后台, 任务被推送到了Gearman, 这个任务队列会保存任务，Instagram有大约200 Python workers 来处理这些任务。

　　监控

　　Session: Uh oh! 服务器端发生了错误，Instagram崩溃了，那三个程序员需要收到告警，马上进行处理。

　　Instagram 使用 Sentry这个开源的应用来实时监控Python错误。

　　使用Munin来绘制各种系统指标的图表，如果有任何情况超出正常范围，就会向程序员发出异常告警。Instagram 有一堆自定义 Munin 插件来跟踪应用程序级别的指标，例如每秒发布的照片、每分钟注册人数等。

　　对于外部服务的监控，使用了Pingdom ，PagerDuty 用于处理事件和通知。

　　最终的架构

　　反思

　　2009年，我们三个都在比较传统的软件公司，互联网技术用得比较少。

　　像负载均衡、分库分表、缓存也是刚刚开始接触，还没有在生产系统中大规模使用的经验。

　　iPhone还没在国内上市，我们仨手头都没有，还在用诺基亚的“智能机”做测试。

　　国内市场也没有很好的云服务作为基础设施，当时李彦宏表示，云计算只不过是新瓶装旧酒，15年来没有新东西，马化腾则认为云计算要像水电一样用还为时尚早。

　　如果执行力强的话，InstantPost应该能做出来，但肯定会遇到很多的坑，想取得一年1000多万用户肯定是痴心妄想。

　　当然，这仅仅说明是我们三个比较菜，不是中国程序员不行，中国程序员在互联网时代也创造了很多优秀的产品，甚至杀到了美国大本营。

　　我想说的是，很多看起来是风口的东西，我们是抓不住的，因为：

　　我们不是局内人。