{Front-end engineers}

原定周一下午推送邮件，后考虑周末闲暇时间更适合阅读和思考，改为周五下午推送。目前订阅人数较少，所以继续推荐一下订阅链接

原文：http://www.36kr.com/p/100143.html

Future Simple的创始人兼CEO Uzi Shmilovici写了一篇文章，里面谈到了设计应该关注的核心问题，我们编译如下，供各位参考。

出色的设计很好，但是用户体验最重要。Path 2.0的设计就很出色，但从作者自己的感受来说，Path实际并没有没有什么用户，其本人称自己仅用过两次，周围使用Path的人也是寥寥（当然他的感受不一定就代表所有人）。这个就好比是时装表演上的衣服，大家都很欣赏，但没有几个人会穿。

仅有好看是不够的，归根结底还是要靠用户体验。

今天所谓的web设计实际上并非真正的设计，仅是样式、像素颜色之类的拼凑。真正的设计必须解决问题。真正的设计必须比摆弄一下PS更加全面、更加深入，应该致力于营造深思熟虑、引人入胜的用户体验。然后才是让美学设计来锦上添花。

因此成功的互联网企业大抵如此，采用的都是一种实用主义的设计，可以去看看Facebook、Google、Amazon的网站，他们所专注的是营造极佳的体验来取悦用户，并带来附加价值。

Instagram的设计就是相当的实用主义，虽然没有Path那么性感，但是它让拍照、分享的过程简单、愉悦，这就够了。

为什么Wesabe会败给Mint？

个人财务管理网站Wesabe成立的时间比同类的Mint早了10个月，但最后却败给了这个后起之秀。为什么？其CEO Marc Hudlund写过一篇反思文章。篇幅很长，但其总结的要点是：

我专注于尽可能提高数据编辑的可用性和易用性；而Mint关注的重点却是如何做到让你无需编辑。

也就是说，Mint所做的事情是引入你所有的数据，然后自动替你组织起来。这个才是箭头上的毒药，找到这一剂毒药是真正的设计师的核心工作。

Dropbox如何在激烈竞争中脱颖而出，一击中的？

作者谈到了以前给自己的一位设计师朋友推荐Dropbox时对方的感受。对方感到很错愕。Dropbox用到的是一种跟web历史一样老的图标样式：FamFamFam。从设计的角度来说，实在是糟糕透顶。但是，从把握设计的精髓来看，Dropbox实在是极具天分，尽管当时他们并没有什么设计师。

把一个文件夹放到你的桌面上。OK了。虽然在屏幕背后，隐藏着如此之多的技术和功能，但这没有关系。有个文件夹放在那里就够了。这就是Dropbox的毒药。

设计迷思

设计的本质是什么？不是去寻找什么很酷的调色板，不是去追求什么灰度和阴影效果，不是制造出虚有其表令人眼花缭乱的效果，这些东西不能够喧宾夺主，设计的本质在于营造引人入胜的杀手级用户体验。而要想成为杀手，你得找到自己要射出去的那支箭的箭头上的毒药。

原文：http://www.infoq.com/cn/news/2012/05/instagram

刚被Facebook以10亿美金收购的著名手机照片分享应用Instagram最近吸引了无数人的眼球，Android版本登陆Google Play不到一个月下载量就突破1000万，总用户数即将超过5000万。Instagram联合创始人Mike Krieger说他们用了8周时间打造了最初的Instagram，但现在的系统肯定已经今非昔比。Instagram技术团队曾发表过一篇文章，介绍了Instagram背后的技术，日前Mike Krieger在名为Scaling Instagram的演讲里，又介绍了更多细节，让人们能了解到5名技术人员是如何支撑起整个系统的。

一张照片上传的过程是这样的：

1. 采用同步的方式写入媒体数据库
2. 如果照片上有地理位置标签，则以异步的方式将照片提交给Solr进行索引
3. 将照片的ID加入每个关注者的列表里，该列表保存在Redis之中
4. 在显示Feed时，选取一小部分照片ID，在Memcached里进行查询

在设计系统时，Instagram的设计哲学是简单、为最小化运维负担进行优化并监控一切内容；其核心原则是保持简单，不要重复发明轮子，尽可能使用经过验证、稳定可靠的技术。

由于只有5名技术人员（其中仅2.5名后端工程师），精力有限，选择Amazon的云服务是个不错的选择。目前他们使用了超过100个EC2实例用于提供各种服务，运行的操作系统是Ubuntu 11.04，之前的一些版本在高流量时表现不够稳定。在负载均衡方面，他们使用Amazon的Elastic Load Balancer实现负载均衡，后端运行了3个Nginx实例，SSL只到ELB上为止，降低了Nginx上的CPU负载。DNS和CDN分别由Amazon的Route 53和CloudFront提供，所有的照片都存放在S3上，目前已经有几TB的规模了。

用于处理请求的应用服务器运行于Amazon High-CPU Extra-Large Instance之上，由于他们的请求更多是CPU密集型的，因此这能更好地平衡CPU与内存。采用的开发框架是Django，WSGI服务器是Gunicorn，通过Fabric在所有机器上进行并行部署，一次部署仅需几秒钟。

大多数数据都存放在PostgreSQL里，主分片集群运行于12个High-Memory Quadruple Extra-Large Instance（68.4GB内存）上，另有12个位于不同可用区里的副本，通过repmgr以Streaming Replication的方式进行同步。由于Elastic Block Store的磁盘IOPS不高，因此需要将正在使用的数据都加载到内存里，vmtouch能帮助管理内存中的数据。他们在EBS上使用mdadm实现了软件Raid，以此提升写吞吐量；数据库的文件系统用的是XFS，在从库获取快照时，会先冻结RAID阵列，保证快照的一致性。

应用程序在连接数据库时，由Pgbouncer建立连接池。目前，Instagram的数据按照用户ID进行分片，某些分片可能会超出物理节点的容量上限，为此他们将数据分成了很多个逻辑分片，映射到少数几个物理节点之上；当一个节点被填满之后，可以将某些逻辑分片移到别的节点上，以缓解该节点的压力。随着数据量的增长，以后他们也会进行垂直分区，Django DB Router能让一切轻松不少。

Instagram也大量使用Redis来存放复杂的对象（对象的大小做了一定的限制），用于主Feed、活动Feed、会话系统及其他相关系统。因为要将Redis的所有数据都放在内存里，此处同样也用了High-Memory Quadruple Extra-Large Instance，并对数据做了分片。当Redis实例的请求达到4万/秒后，它渐渐成为了瓶颈，于是Redis也做了主从复制，副本的数据会经常导出到磁盘上，通过EBS快照进行备份。

除了Redis，他们还使用Memcached来做缓存，目前运行了6个实例，应用服务器通过pylibmc和libmemcached进行连接。虽然Amazon提供了Elastic Cache服务，但该服务的价格并不便宜，相比之下，还是运行自己的Memcached实例比较划算。异步任务队列使用的是Gearman，目前有大约200个工作进程来处理各种任务，比如把照片分享到Twitter和Facebook，通知用户有新照片等等。Pyapns已经处理了十亿的推送通知，非常稳定，他们还自己开发了基于Node.js的node2dm，用于向Android设备发送推送通知。

监控方面，Instagram使用Munin以图形化的方式呈现整个系统的运行状况，还通过Python-Munin定制了一些插件，用来显示业务数据；网络守护进程Stated可以实时收集数据并做汇总；Dogslow会监控进程，一旦发现运行时间过长的进程，便会保存该进程的快照，以便后续分析，比如响应时间超过1.5秒的请求，通常都是卡在Memcached的set()和get_many()方法上。对于Python的错误，只要登上Sentry就能实时获取错误信息。

HighScalability上还根据整理Mike Krieger的演讲整理了一些值得借鉴的经验，比如：

• 找那些你熟悉的技术和工具，在简单的使用场景里先做一些尝试
• 不要使用两个工具来处理同样的任务
• 事先准备降级方案，以便在需要时降低负载
• 不要过度优化，或者希望能事先知道站点要扩展，对于一个初创的社交站点而言，没什么扩展性问题是解决不了的
• 如果一个办法不行，赶快换下一个

如果您想进一步了解Instagram背后的技术细节，可以访问其技术团队的博客。

目前的想法是在周日把一周里面自己觉得靠谱的各种blog 技术文章做一个汇总，让没有太多时间阅读的同学可以在周一回来上班的时候抽空可以补补。

将与每周一  13：00发出新一期内容。

点击此处订阅：订阅地址

以下是本期内容：