您现在的位置：首页
--> Tim[后端技术]
最近在高可用架构群、EGO会员群等多个场合，大家都在讨论架构师的能力的问题，架构师应该具备哪些能力？在面试时如何合适的评估一个架构师的能力？
《火星救援》是最近一部受到广泛关注的片子，讲述在一次人类登陆火星的任务中，宇航员马克·沃特尼经历了一场恶劣的风暴后，与他的机组成员失联，所有人都认为他在这次任务中丧生。然而，马克却幸运地活了下来，然而他发现自己孤单地置身于异星球。面对贫乏的生命补给，马克必须用他的聪明才智和顽强的精神存活下来，并如何寻求求救的故事。
Pinterest首页的Feed消息流，最早是按照用户的关注对象的Pin（类似微博）聚合后按时间进行排序（自然序，类似朋友圈），后来版本的feed系统放弃了自然序，而是根据一定规则及算法来设计，内部称之为Smart feed，其算法及架构根据其公开资料整理如下，值得业界做信息流产品的技术架构师参考。
可能通过「高可用架构」听说过在微博的系统中，单张 MySQL 在线业务表 60 亿条数据的场景。很多关注互联网架构的工程师也非常关注如何如何设计类似系统。下面是一道微博新兵训练营的分布式存储课堂练习，要设计合格才能上岗。
一个成熟的中大型组织中，专业人员会有不同序列技术级别上升通道，比如腾讯及百度的T系列，阿里的P系列等。一些公开介绍的腾讯职级情况如下。
上文为什么超长列表数据的翻页技术实现复杂提到了超长列表翻页技术设计上一些问题，今天讨论下部分解决思路。
Kubernetes是Google开源的容器集群管理系统。前几天写的 分布式服务框架的4项特性 中提到一个良好的分布式服务框架需要实现 服务的配置管理。包括服务发现、负载均衡及服务依赖管理。 服务之间的调度及生命周期管理。
最近一两年，大部分系统的数据流由基于日志的离线处理方式转变成实时的流式处理方式，并逐渐形成几种通用的使用方式，以下介绍微博的消息队列体系。
在过去几年，所在的微博技术团队在一定程度成功解决了feed架构的扩展性与性能的问题，大部分精力已经从应对峰值性能或者数据扩展中解放出来。 几天前，拿着上面这张架构图问内部一些架构师，目前完成的工作及存在的主要问题是什么？
一次某用户在使用系统时候碰到一个问题，但不确认是系统的bug，于是问题通过各级的微博@ 消息反馈到产品与技术团队。在反馈链中，每一个同事都需要确认一下自己是否也出现这个问题，以便确认是否属实以及问题的范围（你可以理解互联网的从业人员为什么那么忙了）。 当这个@ 消息最终传递到当事的工程师手里，他也需将描述的问题再测试一遍，如果不能重现，问题就变得更加复杂，工程师需要从一堆海量的日志去定位当时用户出现这种现象的原因。
有如下一个场景，某个服务需要构建一个列表数据返回给调用方（调用方通常是客户端），服务本身是一个数据聚合器，它由内部多个远程服务的数据聚合而生成。在正常情况下，需要将所有内部服务的结果全获取成功后再返回。但是在一个大系统中，多个服务中某个服务出现不稳定的概率会比较大，当出现如图远程服务3不可用的时候，有3种不同的解决思路。
服务器平均响应速度如果慢下来，慢慢消耗掉系统所有资源，进而导致整个系统不可用。因此在分布式系统中，除了远程服务本身需要有容错设计之外，在应用层的远程调用的环节，需要有良好的容错设计。应用层的容错设计有哪些方法？以下是微博团队使用过的一些实践。
在list长度较少时候，我们可以直接的使用数据库的翻页功能，如LIMIT offset, row_count，根据经验，在大部分场景下，单个业务的list数据长度99%在1000条以下，在数据规模较小时候，上面的方法非常适合。但剩下的1%的数据可能多达100万条，在数据规模较大的时候，当访问offset较大的数据，上述方法非常低效，但在实现方案的时候不能忽视这些超大数据集的问题，因此要实现一个适合各种变长list的翻页方案，考虑到数据的长尾问题，并没有简单高效的方案。这也体现了常说的80%+的时间在优化20%-的功能。
主要出于可用性及高性能的考虑。传统的架构使用基于一致性哈希的分布式缓存，数据只存在一份副本，在出现cache节点单点故障时，虽然可以由一致性哈希算法将请求均匀落到其他节点，但由于穿透的请求较多，仍然给数据库带来较大的访问压力。为了避免对数据穿透带来的冲击，数据使用两份副本可以避免穿透的问题。同时在数据访问较大时候，也可以更好的分担流量，避免峰值单份数据跑满对系统带来的冲击。
• 享受造轮子的乐趣
在业内，由于技术布道师的传播，“重复造轮子”成了一个讳莫如深的话题，一个新的项目在各种讨论场合总是会小心翼翼的避开这方面讨论，一旦触及则会马上描述自己系统的独特性和必要性。富有经验的项目管理者，通常在开工前就会想好各种质疑的应对。但是造轮子也并非是一个雷区，有时候造下轮子也是无妨，不必遮遮掩掩，真的需要考虑清楚的是，轮子为了KPI、晋级、虚有的声誉，还是真的出于兴趣及热爱？他们是否可以放在阳光下，和另外一个社区的产品从技术的角度去比较？
• 结网随想
最近看了图灵的《结网 – @改变世界的互联网产品经理》修订版，这本书是糗百创始人王坚编著，书中有马化腾前言的光环，也有不少不错的案例分析。仅从技术角度谈一些心得。现在产品经理群体里面部分群体不懂技术，确实技术不是必要条件，但也看到不少缺乏对技术理解，而对产品未来视野存在瓶颈的情况。在大多情况下，对技术有更深理解的产品经理应该更具备竞争优势。
大部分工程师包括架构师都是从微观架构起步的。微观架构指在一个局部的领域达到设计及实现的合理性，比如写一个排序的程序，达到时间空间复杂性的合理性，同时在代码的易读性、扩展性及可维护性方面也达到一个合理的标准。但一个系统中不仅只是存在微观问题，宏观架构指一个更高层级的，全局领域的策略及架构设计，通过架构来最终达到对产品或系统在效率、成本上的收益。当系统变大之后，宏观架构的问题更突出，也更能取得收益。
微博上经常看到一些企业或产品的历史介绍，观众很容易把成功的因素归结到“机遇”或者“努力”上，但是除了机遇与努力之外，结合前几篇文章中的“connect the dots”思路顺便谈一些感想。
很多心怀理想的年轻人并不懂得做选择，常看到为了高考志愿或者毕业后的去向在十字路口彷徨的同学。在平时，当我们并不需要做选择时，我们忘记去创造自己的dot。由于整个社会的功利文化，从象牙塔出来的学生，追求短期或可见的利益成为主流，期望财富能不期而遇。选择之道是无形的，过于追求“有形”的目标，未必能轻易获取。
最近和一些志趣相同的同事组织了一个业余的演讲小组，每人每次进行10分钟左右的演说，其他参加者作为评委轮流对其演讲进行简单的点评，通过练习来发现自己的不足，从而在知识的广度与深度、材料的把握能力、逻辑思考(critical thinking)、言辞表达方面来提高自己。
• 跨领域人才
我们也经常碰到技术人员对某一领域的执着。如果这个领域具有可挖掘空间，这当然是一个不错的选择。但是工程领域，到达一个阶段之后，很难再得到一个量级的突破，这时候即使重新学习一种全新领域，未必不是“越狱”后的一个全新开始。即使是具有深度的领域，长时间自我封闭在一个领域，外延也会愈走愈窄。
近3天十大热文
-
[308] Go Reflect 性能 -
[14] [译]Google Chrome中的高性能网
-
[10] Mac下.apk的反编译
-
[10] 在FreeNAS/BSD搭建基于Nginx+
-
[10] webapp网页调试工具Chrome Dev
-
[10] 精于图片处理的10款jQuery插件
-
[9] jQuery性能优化指南
-
[9] 程序中的“多线程”
-
[9] rsync同步的艺术
-
[8] Linux常用系统信息查看命令
赞助商广告
