大概是2009年，我和两个好哥们聊天，觉得智能手机可能是风口，商量着要弄一个照片分享网站。
用户可以用手机把随手拍的照片放到网上分享，名称都起好了，叫InstantPost。
可是我们的执行力太差了，聚了两次，做了一点儿技术验证，就没有下文了。
过了几年，我看到美国一个叫Instagram的火了，不由地一拍大腿：卧槽！这不就是我们当年要做的事儿吗？！
图片
后来我看到Instagram初期的故事，他们也是三个程序员，从2010年10月到2011年12月，在一年多的时间内，就把用户数量从0增长到了1400万！
看完他们的架构设计，我就释然了，抛开执行力，在2009年那个时间点，我们确实不行。
Instagram制定的架构指导准则是：
1.保持简单
2.不要重新发明轮子
3.尽可能使用经过验证的可靠技术
所以早期的Instagram跑在云上，使用EC2和Ubuntu Linux 11.04（“Natty Narwhal”）。
接下来，站在一个用户会话(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多万用户肯定是痴心妄想。
当然，这仅仅说明是我们三个比较菜，不是中国程序员不行，中国程序员在互联网时代也创造了很多优秀的产品，甚至杀到了美国大本营。
我想说的是，很多看起来是风口的东西，我们是抓不住的，因为：
我们不是局内人。
参考资料：
https://engineercodex.substack.com/p/how-instagram-scaled-to-14-million （本文主体内容的来源）
https://instagram-engineering.com/what-powers-instagram-hundreds-of-instances-dozens-of-technologies-adf2e22da2ad
https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c
