Tim[后端技术] -- IT技术博客大学习 -- 共学习共进步！

• 有感Google的混合研究方法

对于一个长期在研发领域的人来说，经常需要思考研发的意义、工程与研究的关系、产品型的公司应当做何种程度的研究等问题。理想情况下，我们期望每一项研发工作都能得到组织、同事以及社区的高度认可。因此不管你处于工程领域还是研究领域，工程与研究的关系会让你不断思考甚至困扰。最近看到的Google’s hybrid Approach to research (English 中文) 一文或许会让你豁然开朗。研究领域的现状根据技术领域的差异，大部分产品开发可以依赖已有成熟的工程技术完成，进一步通过研究来提升产品能力的空间并不大（比如提升空间在10%以下）。互联网企业偏重产品开发能力，关注点主要在开发效率、研发流程等交付能力上。偏实用主义驱动方式，很难对相关领域的工程技术进行升华。因此研究的驱动力、研究的空间及取得成果的可能性较低。

• 微信架构的启示

腾讯大讲堂中最近分享了周颢演讲的微信技术总监解读微信架构的秘密，看完视频的一些心得。技术微创新微信的技术设计上有很多微创新，看起来都很小，但是对于系统的稳定性、用户体验及开发敏捷都具有重要作用。前轻后重由于客户端升级不便，从技术设计上尽量利用后端的设计来减少依赖客户端升级的方法。如某个版本新增了群聊功能，按常规思路，需要所有客户端升级才能全部打通。微信采用服务器兼容的方法，在老客户端不升级情况下让其增加群聊的功能，通过在服务端将群聊协议转换成之前旧版兼容的协议返回给老的客户端。客户端辅助设计微信客户端做了很多非常规的功能，比如常规的客户端测速方法是登录阶段轮询测试多个IP来选择服务器，这样会带来流量及登录速度双方面的开销，因此微信选择的方法是服务端返回最佳的IP（可能是通过历史数据分析）。客户端另外实现了一些容灾能力的配合，当一个IDC访问出现异常自动选择另外一个IDC。

• MacBook Air与工作效率

从MacBook Pro转向MacBook Air已经数月了，谈下使用Air之后带来的便利与效率提升。便利虽然进入云计算时代，由于国内网络环境原因，访问国外一些知名云提供商并不稳定。因此在相当长一段时间内，国内用户依然非常依赖本地存储，使用轻便笔记本是一个最佳的选择。随时随地使用同一个工作环境后，可以极大改善个人效率及体验。这是使用Air之后一些日常的便利。工作忙时浏览器标签页打开的文章可以在其他环境继续阅读，不需要收藏到ReadLater之类的工具中，而且ReadLater更大的障碍是，打开一个网页在粗读完之前，无法判断是否需要收藏。由于是SSD，启动程序及打开文档速度非常快，几乎不需要等待。由于Air很轻，尤其是11寸也很小，可以用方便随身携带，不需要为“今天是否要带走”思考。可以坐在床上、沙发、公园、咖啡厅或者其他随意的地方编写代码或者文档，不会感觉压腿、发烫或者沉重

• 技术方案评审

新年开始，大部分公司都在启动大量新功能的规划及设计、技术人员同时在设计对应实现方案、架构师或者技术主管则需要一天内穿梭在多个技术讨论中，评审并达成成熟稳定的设计方案。从架构师的角度来考虑，如何衡量一个技术方案的优劣呢？一、评审点从总体上讲，技术方案是衡量一个团队的开发成熟度重要一方面。技术设计是否围绕核心需求key features？模块依赖关系、兼容性是否得到充分清晰的描述及共识；设计上不同的方案是否得到了充分考虑比较？是否有正反的激烈的碰撞还是行政上的领导说了算？另外代码实现是否正确执行设计，还是代码实现边走边看，与设计方案基本脱节？从细节上来看，在软件企业内经常有不同形式的方案review，架构师在做review时候需要要考察哪些环节？从互联网系统设计的角度，总结到以下几点。简洁及可维护性从工程角度来看，避免难懂的方案。技术方案尽量象PPT那样，越傻瓜的方案越有生命力。当然

• 技术工程师的能力与目标

曾经有这样试验，随机选择一组对象进行工作的自评，几乎所有对象的自评分都在实际成绩的平均分以上。在工程师团队中也不例外，许多工程师有这样的困惑，自己觉得工作已经做得不错，但是上司好像察觉不到，甚至还对自己的工作吹毛求疵。如果有个合适参照标准，工程师或许就可以更好的对自己工作进行自评。管理者也同样面临类似困惑，在一个组织中，需要定期对团队中的成员进行考核及晋升，但是考核的标准是什么？小团队中主要取决于管理者的意志；大型组织中l流程会更规范，但也存在考核者凭感觉来给被评估者打分的情况，或者是考核者心中的衡量标准千差万别。从工程师自我提升追求及职业规划的角度，情况会更复杂。每一个工程师都有不同的追求目标，孟岩有一篇很有影响力的《技术路线的选择重要但不具有决定性》，文中工程师的追求类型被描述成事业目标型、团队精英型、技术高手型、得过且过或养家糊口型四种。文中将“独特的个性知识经验组合”看做是工程

• 程序员的工作环境与效率

很赞同《Joel on Software》中Bionic Office一文所说，办公环境需要比大部分员工的家中环境更舒适。否则老板只能招聘哪些还住在简陋公寓的员工，他们才有可能下班后情愿留在办公室继续工作。我认为程序员的办公环境的几个条件 1、足够大的桌面空间程序员的办公桌最好可以并排坐下2人，以便pair programming或者code review。在不离开座位的情况下，有足够空间用白板或者纸面展开讨论问题。协作的同事不必站在身后费力的越过肩膀...

• 有故障，毋宁死

―谈系统故障及软件质量如果你是一个7×24小时在线服务的整体（或模块）的技术或系统负责人，你的大部分生活会如游走钢丝。程序会出bug、资源会出故障、发布会操作错误、测试会有疏漏、安全会出漏洞、网络会有波动、服务器会突然坏掉。当产品的需求日益增多，判随工程师团队会日益增大，一个软件项目或功能从开发到上线的完成，都不可能由一人或者几个核心工程师去做，需要由不同背景、不同能力及做事风格的的开发、测试、工...

• 开发效率与系统稳定性杂谈

在互联网系统中，开发效率与系统稳定性与产品成败非常相关。开发效率在一定程度反映了团队的执行力，快速开发能力带来了产品的竞争优势。系统稳定性（包括安全及性能等）则是产品的后防线，稍有失误则会给产品带来很大伤害。因此开发效率与系统稳定性是衡量互联网系统开发成熟度最重要的两个指标。在软件开发周期不同阶段，这两者如何控制？在需求阶段，对开发效率的影响常见的是沟通理解偏差带来的技术风险，之外最常见的还有需...

• 服务管理框架的尝试

大型软件系统开发需要模块化，在分布式系统中，模块化通常是将功能分成不同的远程服务（RPC）来实现。比如可以用Java RMI、Web Service、Facebook开源的Thrift等一些技术。同样，在一个大型系统中，服务化之后服务的可维护、可管理、可监控以及高可用、负载均衡等因素同服务本身同样重要。服务管理目前并无直接解决方案，Thrift作者Mark Slee提到 It’s also possible to use Thrift to actually build a services managemen...

• 2011互联网技术发展浅析

编程语言由于iPhone及iPad的魅力，Objective-C获得了飞速发展。另外Python也在国外也得到稳步增长，Python在两个方面存在优势，在Web开发方面相对PHP编码更优雅，在后端服务可以充当粘合剂的作用，用于整合服务器资源及后端服务做一些快速开发，但根据观察Python在国内发展未有明显变化。其他主流语言在2010变化基本不大。从2010年5月的Go...

• Redis新的存储模式diskstore

Redis作者antirez是一个非常勤奋的开发者，在Redis性能已经非常惊人的情况下持续不断开发新的特性，比如从新的cluster源代码看到，作者已经把Dynamo及Paxos一些核心的思想考虑进去并进行了一些简洁的实现。相比其它产品如Memcached则几年没什么大变化，在Web 2.0时代，Memcached已经非常不够用，技术人员需要考虑做很多额外工作才能让Memcached适应新的变化和需求。 antirez在1月5日Google Groups发表了一篇Redis diskstore文章，...

• Redis容量及使用规划

在使用Redis过程中，我们发现了不少Redis不同于Memcached，也不同于MySQL的特征。 (本文主要讨论Redis未启用VM支持情况) 1. Schema MySQL: 需事先设计 Memcached: 无需设计 Redis: 小型系统可以不用，但是如果要合理的规划及使用Redis，需要事先进行类似如下一些规划数据项: value保存的内容是什么，如用户资料 Redis数据类型: 如String, List 数据大小: 如100字节记录数: 如100万条(决定是否需要拆分) ・・・・・・上面的规...

• Redis几个认识误区

前几天微博发生了一起大的系统故障，很多技术的朋友都比较关心，其中的原因不会超出James Hamilton在On Designing and Deploying Internet-Scale Service(1)概括的那几个范围，James第一条经验“Design for failure”是所有互联网架构成功的一个关键。互联网系统的工程理论其实非常简单，James paper中内容几乎称不上理论，而是多条实践经验分享，每个公司对这些经验的理解及执行力决定了架构成败。题外话说完，最近又研究了Redis...

• 微博架构与平台安全演讲稿

本文是在2010中国首届微博开发者大会演讲稿(PPT)，由于网上已经有演讲视频及全程文字记录，这里就不做补充，演讲稿如下。微博架构与平台安全 View more presentations from Tim Y. 需要下载请点击 view on Slideshare，在 Slideshare 打开后 Download Similar Posts:QCon Beijing qconbeijing全部演讲资料下载 Memcache mutex设计模式构建可扩展的微博架构(qcon beijing 2010演讲) 第一期广州技术沙龙演讲稿及视频 Web 2.0...

• 多IDC数据时序问题及方法论

上一周在微博架构与平台安全演讲中提到多IDC及架构设计的方法，由于最近工作中经常碰到这种情况，再举一个小案例补充一下。 Web数据访问比较好的设计模式是使用cursor方式（参考前文用Twitter的cursor方式进行Web数据分页），原理上相当于增量方式访问数据，可以极大提高访问性能。在单IDC场景中，如图1，系统的id是递增，假设用户上一次访问最新一条记录是1002，则本次访问最佳的方式是 get?cursor=1002，可以高效取到后面3条新...

• 降低应用latency方法谈

上个月发的谈团队每周技术交流引起不少同行感兴趣，如果那篇文章能起到促进业界公司内部技术交流那就是最大的贡献了。上周五我们继续内部技术讨论，对某Java Web应用进行了latency分析。Latency主要是分析一个URL高并发请求下消耗时间的分布。

• Memcache mutex设计模式

周六的S2 Web 2.0技术沙龙上介绍了memcache中使用mutex场景，有网友对详情感兴趣，简单介绍如下。场景 Mutex主要用于有大量并发访问并存在cache过期的场合，如首页top 10, 由数据库加载到memcache缓存n分钟微博中名人的content cache, 一旦不存在会大量请求不能命中并加载数据库需要执行多个IO操作生成的数据存在cache中, 比如查询db多次问题在大并发的场合，当cache失效时，大量并发同时取不到cache，会同一瞬间去访问db...

• Twitter停用Cassandra原因分析

Twitter的调整对于MySQL业界来说或许是一大利好，MySQL虽然受近期Oracle收购阴影的影响，但是对于目前大多数拥有海量数据访问的网站依然是他们第一选择。MySQL简单，可靠，安全，配套工具完善，运维成熟。业界碰到的大部分可扩展性方面的问题在MySQL中其实都有清晰明确的解决方法。虽然重复sharding的问题很烦，增删机器相关的运维工作也很繁琐，但是这些工作量还是在可以接受的范围内。

• 做卓有成效的程序员

最近阅读了《卓有成效的程序员》(The Productive Programmer) 一书，此书虽是2009年出版，但是介绍内容的价值并不会随着时间过去而降低，相信5－10年后对于大部分开发者仍然具有借鉴价值。大部分章节是介绍具体的方法来如何提高程序员工作效率。记住具体的技巧未必有太大价值，很多人都认同一种观点就是，读一本书最终的目标是忘记其中所有的观点，但是它会潜移默化影响了你以后的思维和或观点，包括你的行为。因此我认为此书直...

• 构建可扩展的微博架构(qcon beijing 2010演讲)

在使用Twitter几年的时间里面，经常思考微博如何更好的实现，恰好最近几个月也参与了相关工作，大部分都是工程实践，总结实践会促生更具实际价值的理论。因此在QCon Beijing 21010年在参考了不少网友的意见后选择了《构建可扩展微博架构》的题目。由于在决定选题时知道来自Twitter总部有30万followers的@nk也会讲一个类似的题目，心中当时有点忐忑，最大的顾虑就是我要讲的他全部覆盖了，而且讲得更深入，我就没必要班门弄斧了。...