Home | About | English | RSS

  • Feeds

    • 软件的体验障碍与解决之道

    May 6th, 2015 | 5 Comments
    Filed under: 随想

    earl grey decaffeinated
    目前好的app会将数据存储在云上，给我们生活带来很多便利，我们可以方便的多屏之间获取到数据，也不用担心app及数据在本地删除后丢失的问题。但很多基于云平台的优秀软件到了国内就会出现一些使用上的问题。

    比如Day One是一款跨平台笔记工具，得过苹果设计奖，也得到不少人推荐，功能确实很简洁实用。白天在路上用Day One写了一些文字，回来后发现uploading一直卡住，不知道是否跟文章中某些词语相关。打开iPhone VPN后，终于上传成功，但在电脑上还是半天下载不回来。忙了一些其他事情之后，发现终于同步完成了。

    Day One底层可以选择用iCloud，Dropbox等云平台存储。这些云服务在国内访问速度及稳定性方面会存在一些问题。Day One可能出于功能简洁的考虑，将同步设计成后台进行。当同步出现问题时，界面上通常看不到相关提示，系统自动在后台重试同步。界面上也找不到任何同步按钮及菜单，也没有状态信息显示何时会进行同步，因此在同步失败时候，用户只能一筹莫展了。

    在国外，由于云平台在基础网络链路及带宽方面都具有优势，因此同步阶段不会出现这么多曲折的情况。上面的问题更多是国内特殊的网络环境造成，软件开发商也无辜的被躺着中枪了，这是app存在的一类问题。

    但并不是说国内的app就可以处身事外了，国内也有自身奇特的网络问题，比如一些厂商的DNS不定期的被劫持指向一些奇怪的IP。但开发商即使了解到这个反馈，未必有有效的手段短时间解决，这也是app存在的一类问题。

    做互联网分布式系统的通常也有这样一种情况，在主从同步等场景下，数据只能保证最终一致性；互联网业务通常不会使用transaction来保证数据提交一致性，因此可能会存在半状态的数据，用户如果碰到这种情况并且会存在困惑，但开发商通常会采用事后修复的办法，从CAP理论的角度不会首先考虑引入事务来彻底解决，这又是一类问题。

    上述问题是否能有效的解决？是否值得花大的精力解决？从“用户第一”的角度，所有用户的问题确实需要第一时间第一优先级解决，特别在影响用户范围足够的情况下。但上述这些问题都是小众群体及场景出现，而且都是在使用标准化方式的情况下出现了异常。

    从架构师的角度，我是极力赞成使用通用化技术而反对自建轮子，比如不赞成用自己维护的UDP代替TCP，不赞成使用非主流或自己开发的数据库、框架、工具包；不赞成通讯上使用自定义的协议来代替XMPP，或者为了防止DNS劫持而去搭建自己的DNS方案。可以预见，这些自建方案的决策在一定程度上打开了一个潘多拉盒子，社区通用技术体系经过5-10年或更长时间的演进，经过较多问题的修改与避免。比如上面的TCP/HTTP RESET/URL关键词错误属于一个问题的话，TCP/HTTP协议已经很好的解决了前100个你看不到的问题。自建的体系从0开始搭建系统，可能需要将大量时间放在重复业界已经完成的功能上。

    从工程师体验来说不太倾向于对各种特殊小众的环境都做一个适配方案。如果有机会能做这样一个比较，在“工程师体验第一（类似facebook的Hacker文化)”与“用户第一”做一个优先选择的话，究竟谁的成效很更好一些？老板们通常会倾向后者，类似有阿里的“客户第一，员工第二”文化；一些声称工程师文化主导的公司可能会声称选择前者，而且某些持这种理念的人也认为工程师主导产品改进的环境会激励工程师的主动参与及改进精神，而导致成效更好。另外一方面文化层面的东西很难直接比较优劣。

    感谢新买到的低因伯爵红茶，让我写完这些文字后接着睡觉不会失眠。

    微信红包金额分配的算法

    Apr 30th, 2015 | 22 Comments
    Filed under: 架构

    虽然春节已经过去一段时间，但不少微信群里面依旧乐此不疲的在玩发红包活动，用户自发的将最初的一个春节拜年的场景功能慢慢演化成一个长尾功能。

    用户在微信中抢红包时分成抢包和拆包两个操作。抢包决定红包是否还有剩余金额，但如果行动不够迅速，在拆包阶段可能红包已经被其他用户抢走的情况。

    红包的金额是在什么时候算？ 据某架构群腾讯财付通专家反馈，红包的金额是拆的时候实时计算，而不是预先分配，实时计算基于内存，不需要额外存储空间，并且实时计算效率也很高。每次拆红包时，系统取0.01到剩余平均值*2之间作为红包的金额。

    为了保证每次操作的原子性，拆包过程中使用了CAS，确保每次只有一个并发用户拆包成功。拆包CAS失败的用户可以由系统自动进行重试。但也有可能在重试过程中被别的用户抢得先机而空手而归，因此严格意义拆包的调用也未能保证用户先到先得。

    基于上面的原因，当时在群中提到这种算法有些复杂，微信红包为了减少存储，每次进行了一个理解稍复杂的实时计算。对比大部分架构师想到的预分配金额的做法，预先分配金额需要将金额保存在一个内存队列中，如果红包的份额较多，则需要较大的存储空间。而微信红包仅保存 count:balance 这样2个数字。count指还剩几个人可以抢，balance只还剩下的金额。

    但是预分配金额也并不是非得需要额外存储。比如利用随机算法，在种子相同的情况下，随机数实际上返回的随机序列也是固定的。如以下Python代码，对于给定的seed 1024，每次执行返回的结果都是相同的。
    >>> import random
    >>> random.seed(1024)
    >>> random.randint(1,100)
    80
    >>> random.randint(1,100)
    49
    >>> random.randint(1,100)
    39
    >>> random.randint(1,100)
    83
    >>> random.randint(1,100)
    88

    因此预分配金额也只需要额外存储一个种子，或利用一些红包id做加密变换做seed达到零存储。而在发放红包时候，无需进行CAS操作，而只需要对剩余红包count做一个DECR操作。当count<0时，表示红包被拆包抢完。由于DECR是原子操作，无需加锁，用简单的方法达到了先拆包先得，原理上不存在早拆包但由于并发冲突失败而抢不到红包的情况。 每个人分配的金额是：total * random(n) / random_total，不需要重复计算。 random(1)..random(n)不需要保存，因为对于给定的seed，random(1)到random(n)返回是固定的。 以上算法评论与对比，与Tim所在雇主的红包算法无关，特此声明。

    部分细节下面列表已做说明，未做详细阐述。

    Reference:
    1、微信红包的架构设计简介
    2、网友周航老师基于聊天记录整理的微信红包架构图（点击查看大图）
    wechat architecture
    3、微信红包实现原理

    对于上文中提到的架构群感兴趣的朋友可以关注Tim公众号“TimYang_net”后回复“arch”获取进群方式。

    出品人眼里的一次QCon技术大会

    Apr 27th, 2015 | 7 Comments
    Filed under: tech

    上千人的技术大会非常壮观，这次QCon北京全球软件开发大会的参会人数有可能达到了历史新高。考虑到北京国际会议中心会场的容载能力不足，对于参会人员来说，在这次大会中选择听一些热门内容的演讲注定是一次艰苦的历程。演讲开始前如果刚好从别的分会场跑过来，就很有可能堵在门口进不去；坚守一个分会场不转场的同学保留住了席位，但几百人挤在一个会场持续几个小时，感觉离烤肉的距离已差不远。

    本次Tim继续担当了可扩展高可用专题分会场的出品人，可扩展是指软件架构中项目及产品在快速成长的阶段具备很好的扩展及应对能力。而可用性则关注项目在长时间运行以及碰到极端压力的情况下仍然具有较好的稳定性，包括应用柔性可用策略的能力。考虑到国内互联网创业的蓬勃发展，大量的成长型企业会碰到架构瓶颈的问题，前几个月曾经出现一个爆款的app太火，一堆外援的技术专家和云平台去救火的情形。因此预计专题会得到较多的关注，主办方也特意保留了一个较大的分会场并策划了全天的专题内容。跟以往的情况比较类似，考虑到在可扩展及高可用的行业代表性，分享的讲师大多是来自知名的互联网公司，但是在与讲师们准备演讲内容时，Tim会建议讲师将不具有广泛适用性（比如需要依赖大公司自研系统的一些做法）内容去除，让介绍的经验能让大部分参会群体包括初创型企业有较好的借鉴性，方便应用到听众各自的环境。

    由于此专题在历届QCon关注度和评价都不错，也曾经产生过不少互联网界经典的架构案例，因此本次的讲师们也都非常有压力，分享的内容在准备期间就经过多个版本的迭代，比如来自微博的讲师秦迪总结了一篇做一场不被喷的技术分享
    ，其对待分享的态度以及一场让听众满意的分享如何去做值得架构师参考。

    选择是否去参加一场技术大会也是个很痛苦的抉择，不去的话感觉错失了好多信息，尽管这些信息最终会通过社交媒体传到你眼前；去了的话又感觉学习效果还不如坐在书桌前喝着茶静静的看一个网上的演讲视频。当参会者选择艰苦的到达会场参会，通常希望能得到一些启发及经验，并进一步应用到自身的工作中，参会者把这些具有很强启发及可借鉴性的经验称为“干货”。由于资讯高效传播的特性，要做到这一点实际上越来越难。大公司中或者国外一些具有广泛借鉴意义的方法一经出现，就会迅速被各种技术媒体及技术大V在行业内传播，捂着一个好方法到某个技术大会再揭秘这种可能是非常低，讲师要将分享打造成一场受欢迎的演讲挑战越来越大，大多情况讲师介绍的内容属于大家日常通过网络可获取到的知识。

    尽管获得满意“干货”的机会不好保证，但最近几年参会的人员越来越多。思考其原因，技术大会越来越类似电影行业，技术大会的主角是各种技术大拿，还有幕后出谋划策的策划编辑及专题出品人；电影也是由导演、演员及剧本决定。由于观众的审美品位越来越高，相同的题材出现一次后就不太好再次重演，因此导演和技术大会的策划都在挖空心思寻找观众感兴趣的题材。从理性角度，如果在电影院碰到满意的的电影可能越来越低的情况，观众会减少去看电影。但在事实上，未得到满足的是观众还是一次次乐此不疲走进电影院。技术大会也越来越多的表现出这种倾向。

    也许，相比于其他获得启发的方式，观众就是喜欢这种通过现场感和全心身投入相应主题的专注感来获得思考及满足。一周前打包的slides放在网上（或躺在硬盘的角落）无人问津，赶2小时的地铁去看一场现场分享的事情却乐此不疲。

    一些人确实通过现场学到了一些新知识；另外一些人在体验不佳时候则选择更多通过大会去找大牛瞻仰或切磋、与很久没见到的同行交流等，当然也有抱着单一目的去认识更多牛人的。因此不少技术大会也被戏称程序员的线下社交平台。但是社交只是一个伴随物，经常出现在社区或者技术大会上，每个人都跟你有点头之交，但没有人想到跟你探讨专业问题，沉迷于交际的价值会非常有限。

    从讲师的角度，大部分讲师具有不错的行业代表性，但也不排除一些讲师是为了存在感而参与。一类讲师是有了非常满意的素材并且受邀才会出现在分享的讲台上；而也有一类讲师是先报名则去慢慢找演讲的题材，这种情况就表现出更多宣传及表达存在感的诉求。不过这两种例子都极端一些。

    (EOF)

    最后如果你是一位架构师或首席工程师，并且很愿意参加社区讨论，请了解下面介绍的这个可扩展高可用群的介绍。

    Tim也加入过不少会议群，99%的情形加了一群人之后还没留下一些有效的讨论就无疾而终了，一群缺乏组织的陌生人聚在一起的讨论区通常很难持久下去。在纠结的心情中创建了一个群，周末通过圈子之间的互相邀请目前积累了不少人，也暂时还没有沉寂，并意外的是还输出了一些不错的讨论内容，如这篇WebIM实践过程中可能遇到的问题及总结。这个群欢迎架构师、首席架构师、首席工程师或一线技术负责人加入，潜水的成员会定期清除，有兴趣的可以关注Tim公众号“TimYang_net”后回复“arch”获取群进入方式。

    First...567...Last