分类目录归档：Design Pattern

理工男是如何选择iPhone 8 (Plus)和iPhone X的

发表于由
回复

上一台手机是iPhone 6 Plus 64G, 使用到现在将近快3年半。6p在升级iOS 10以后，速度就算不上流程了，使用微信和支付宝的时候尤其明显。特别是使用支付宝付款的时候，经常卡在story board画面，没少受后面排队哥们白眼。

现在（2018.03）并不算是购买苹果这代手机最好的时机，因为一般最好的价格都是出现在双十一。而且本着早买早享受的原则，现在入手其实体验周期也间接变短了。这次考虑换机原因只有一个：6p实在是不能战斗下去了。虽然并不喜欢这代的iPhone，但是，也只能矮子里面拔将军了：选iPhone 8 (Plus)还是iPhone X？

习惯性的打开哈乎看了一下，纠结着两个选项的人好像还挺多的：

  • 你会买 iPhone 8 还是 iPhone X？
  • 你会选择买iPhone X还是iPhone 8，或者其他手机?
  • iPhone 8 (Plus) 和 iPhone X 你会买哪个？为什么？
  • iphone X 和 iphone 8/8plus 哪个更值得买？
  • iPhone 8/8p/X，不知道选哪个？

其实上面的问题只会越看越不知道自己选什么，因为每个人都有自己的需求和背景。

这里我就不卖关子，直接给出自己的选择：iPhone 8 Plus, 容量看自己的需要，因为自己的6p是64G且容量将满，因此选的是256G。主要理由如下：

face id解锁交互用在了错误的场景

face id解锁是一个自己无论如何也无法接受的交互方式。我仔细体验过同事的iPhone X，成功率尚可，但是做不到「存在于无形之中」。人脸解锁如果做不到这一点，就是一个半成品。

这一点类似于汽车行业之前大规模使用触屏代替物理按键（呃，好吧，马斯克同学还在坚持在特斯拉车型中大规模使用触屏……），不是说触屏控制本身存在技术障碍，而是在这个场景中使用了一个高成本且不合适的技术。

我甚至无法想象晚上在被窝中要解锁iPhone X时，必须要让手机的主动探照光闪瞎狗眼的酸辣情景。那么，什么场景是适合face id的呢？我认为是在结合其他id因子的安全领域，比如在大额支付时，使用touch id和face id进行双重校验。

iPhone X的全面屏是个笑话，全面屏最终都会变成笑话

齐刘海问题肯定算不上优点，但是问题并不大（好吧，其实苹果开发者还是挺吐槽这个刘海带来的额外开发工作量的……）。重点是，全面屏在当前阶段并不是一个手机尺寸上能够提升用户体验的发展方向。

以前手机尺寸的发展方向是变薄，有些厂家甚至以此作为卖点。但是几年下来，还有哪个厂家将自家机器薄作为卖点？就连以前乔帮主健在时，发布会现场直击从文件袋里拿出来的iPad Air也不在突出它薄的数值了。

空口无凭，我们看一下苹果历代16款手机的厚度数据对比：

结果是不是很意外？

  • 从iPhone 5开始，苹果手机的厚度基本就没有太大变化。
  • iPhone 6是迄今为止，苹果最薄的手机。
  • iPhone 6开始，苹果手机厚度是逐年上升的！
  • 更加有意思的是，iPhone X是水果这5年来最厚的手机?

那么这个问题跟全面屏有什么关系呢？我们先看一下全面屏的定义：

全面屏从字面上解释就是手机的正面全部都是屏幕，手机的四个边框位置都是采用无边框设计，追求接近100%的屏占比。但其实到目前为止没有一个严格意义上的全面屏幕定义，而比较主流的看法是要有18：9的屏幕，正面取消任何实体或者触摸按键，只有一块完整的屏幕，而且屏幕占比至少要达到80%以上。显然目前有很多手机虽然也号称全面屏幕，但屏幕占比却没有达到这个要求，所以看上去边框很宽，并没有特别好的效果。

所以，仔细想想，你就发现，在现阶段各家手机屏占比越做越高的今天，全面屏已经基本成为或接近事实，并不需要为了迎合这个概念而调整手机本来已经验证多年的设计，尤其是正面的按键和触感器排列。这一点上，锤子手机罗永浩是深谙其道的，他发布的坚果 2 Pro手机宣传语就很准确「Almost 全面屏」?

因此，当前阶段，行业对全面屏的疯狂追捧跟当年恨不得手机能够用来切菜的追逐是如此神似。当然，也有头脑清醒的人只是跟着喊口号，但是并没有真的跳进坑里，比如老罗。

手机是需要握持使用的，两边的边框是一定会有所保留的，无论是iPhone X还是小米的MIX系列。有意思的是，这两个厂家疯狂宣传他们全面屏的同时，却没有告诉你，他们把手机两旁的边框做了轻微加高和立面加厚处理，当你进行从屏幕边缘划入屏幕操作时，感觉手指被一个圆铁丝顶了一下一样，还不如以前「正常屏」手机顺滑。而iPhone X的全面屏还有一个额外的槽点：话说你提高屏占比是为了显示更多的信息吧，但是你看看iPhone X现在的屏幕显示情况，很多情况下屏幕下方很大一截都是空的，要这铁棒有何用？

小结苹果的全面屏：

  • 全面屏是一个伪概念，在当今屏占比越来越高的今天，全面屏就是个概念和幌子。
  • 在屏占比提到到一定程度以后，对用户体验影响的提高就很小了，甚至会降低用户体验。
  • 如果一定要为了全面屏而改变正面的一些布局，无疑是舍本逐末、因小失大的做法。

iPhone X的优点

但并不是说iPhone X就全无优点。

结合其深度传感器使用的Animoji可能如当初Emoji一样影响整个行业，前提是深度传感器能够迅速降低成本并普及。

摄像头双重防抖对于喜欢拍照的同学来说更是锦上添花。

OLED屏幕显示效果主观观感的确非常赞。

选择iPhone 8 Plus的困扰

  • 没有辨识度。其实换手机有好几天了，但是同事根本没有发现我换了手机。但是，iPhone早就过了可能装X的年代了，所以也没觉得损失什么。
  • 多年使用同一个设计ID的产品。6p用了三年多，8p估计也会用2年以上，意味着6年都用着一个外观的产品。这点自己并不排斥，要知道设计不是一直向前的，有时候还会轻微倒退。正如我一直觉得ThinkPad T61/T400的设计是一代经典，因此我现在还在用着这10年前的笔记本电脑做一些简单的文档处理和网页浏览。
  • 手机重量历代之最，用久了手腕疼。但是有些人觉得这才是质感
  • 玻璃后盖易碎。但是有些人认为这才叫温润如玉。

其实上面说的都谈不上困扰，只是你选了8p以后需要考虑能否接受的小妥协。

为什么不选择iPhone 7 (Plus)?

选iPhone 7 (Plus)的唯一原因当然是价格。但是，作为一名理工男+参数党，通过研究苹果这一代的芯片发现，iPhone 7可能并不适合自己。

从上图可以发现，这两代CPU的制程一个是16nm, 一个是10nm. (苹果历代CPU参数可以参见这里。 无论是理论还是实际测试，A11芯片都比A10芯片能效更高，续航时间更长。而iPhone 8 Plus更是做到了在电池容量比iPhone 7 Plus少10%左右的情况下，续航反而增加了一个多小时。

另一方面，A11采用的是两个高性能+4个能效核的设计，比A10多两个效能核。理论上A11的CPU跑分会更高。使用Geekbench 4也应证了这一点：

单核性能提升23%，多核性能提升76%!

之于iPhone 8 Plus加入的无线充电，聊胜于无吧。倒是快充功能在紧急场合能够发挥一点作用。

另一方面，由于自己换机频率不高，因此，对于自己而言，iPhone 8 Plus更加适合自己。而且这几天购买正好碰到3.8女王节活动，直降1000，性价比也不算低。

总结

不选iPhone X有很多理由，选择iPhone 8 Plus则是因为被动选择。虽然当前的iPhone X只是一个半成品，但是库克肯定认为它是以后苹果手机的发展方向，自己对下一代iPhone X也没有任何期待。因此iPhone 8就是苹果以iPhone 6为设计语言的一代产品的绝唱了，这也算是自己选8的一个原因。

微服务架构下的立体监控系统设计和实现

发表于由
回复

背景

GOPS全球运维大会（北京站）听到了不少干货。特别受益的是来自腾讯SNG事业部聂鑫分享的
《从0到1到N，腾讯监控体系全透视》。

在他的主题分享中，他将腾讯这些年的监控系统的发展历程概括为点监控-->面监控-->深度监控：

看到他这页幻灯片的时候，有一种醍醐灌顶的感觉。因为在听他分享的时候，我们的系统才刚刚完成架构微服务化没多久，我们上线了调用链：分布式追踪系统来解决在微服务分布式系统中排查跟踪特定问题，但我们的监控系统还没有针对架构微服务化后进行相应的进化。比如，大部分监控系统停留在点监控的层面，少数进行关联多个服务的面监控也做得比较初级，需要人工分析和干预。

点监控比较好理解，就是对系统布置监控点，根据阈值触发告警。

面监控则是对告警信息进行时间和空间关联，有效消除毛刺告警，使告警更加准确。因为告警本身有时效性，时效性源于告警延时，连续性可能是干扰，因此只进行时间关联是不够的。链路相关性（空间相关性）和时间相关性一起决定准确性。

深度监控其实有点追深度学习的热点，从分享看，实际就是对面监控的链路相关性进一步完善，以及根据收集到的系统进行使用机器学习进行简单的分类。

参加会议回来以后，我们明确了自己监控系统的进化方向，根据自身系统的特点进行了一些取舍，确定了立体监控的方案。

立体监控方案目标

所谓「立体监控」即指在我们当前系统点监控为主的情况下，尽可能复用当前监控的探针，进行时间和空间（服务链路之间）维度上的扩展，实现对整个系统时空上的监控。

立体监控需要消除点监控带来的监控毛刺，如服务存在依赖情况下，级联告警通过立体监控分析融合后，应该只对最后一级进行告警。

立体监控可以快速的定位系统故障，定位粒度根据不同监控类型可以做到微服务级别、接口级别、数据库实例级别、缓存实例级别等。

立体监控方案设计和实现

对于微服务，我们通过data bus将需要进行监控的信息发送到kafka进行收集。这种方式在调用链分布式追踪系统也有使用。不得不说，data bus是架构微服务化后非常重要和实用的基础组件。

为了尽可能降低各个微服务集成监控组件的侵入性，我们通过修改基础库的方式进行集成。比如，微服务使用了MySQL数据库，那么我们就修改微服务使用的数据库驱动来对数据库进行监控，一旦发生错误或warning信息，将消息写入data bus；某个微服务需要调用腾讯的某个接口，我们就对修改我们的http客户端基础库，将错误和超时消息写入data bus实现对该接口的监控。

因此，我们的微服务监控集成几乎不需要研发人员的介入，只需要运维人员更新服务依赖库，然后重新发布上线即可。事实上，我们在微服务监控集成上就没有安排独立的发布上线时间，都是在研发上线feature或hotfix时搭车上线的，将近两百个微服务在2周内完成集成。需要注意的是，基础库的修改一定是由团队中相对资深的开发人员来做，并且测试一定要做到位，否则会引起大规模的问题。

对于k8s集群、数据库、redis等基础设施的监控沿用以前的点监控数据，只是将事件统一上报到了Event Collector事件收集服务。Event Collector除了收集事件数据，也对一些不符合通用规则的数据进行过滤。

Event Analyzer事件分析服务根据Event Collector收集到的事件，进行时间和空间上的分析监控结果，并发送告警通知。

在事件分析上，时间维度非常简单，选取一个时间窗口内的事件信息即可（我们当前根据经验设定的是1min）。空间维度方面，则相对麻烦一下。我们没有采用腾讯使用的全链路分析算法。主要是因为该算法需要预生成链路拓扑图。而微服务架构中，各个微服务的增加、减少和变更是非常频繁的，预生成拓扑图有点反模式，也会产生一定的成本。我推测腾讯之所以觉得预生成拓扑图不是问题，跟它当前架构没有完全微服务化以及内部严格的管理流程有关。

因为不想预生成链路拓扑图，分享中给出的链路面积计算公式也就无法使用。另一方面，因为腾讯给出的全链路分析算法其实没有完备的理论证明，在我们数据量没有腾讯庞大的情况下，我们是否能用该算法取得同样效果是缺乏信心的。

但是，思想是可以借鉴的。通过讨论，我们一致认为所谓的链路分析其实就是关联性分析，而关联性分析那就毫不犹豫的使用Google Page Rank算法：

如上图所示，我们将服务(1, 2, 3, 4)之间的告警事件作为一个超级链接指向，然后计算PR值，那么，PR值最大的是我们认为出现问题可能性最大的服务。理论证明这里略过，这个锅我们扔给Google背即可。

需要说明的是，任何一个复杂的系统在出现故障时，往往不是一个组件或服务出现问题，很可能是多个服务同时出现问题。那么在计算PR时，可能就是面对多个独立的PR有向图。这个时候独立图之间的关系处理就可以根据历史数据进行机器学习，以进一步给出故障原因，然后根据预案快速处理故障，恢复服务。

Event Analyzer也提供了一个页面，可以查看历史的告警信息链路：

也可以对链路流量（边越粗流量越大）进行监控和分析：

总结

立体监控上线后，运维方面以前只能从点入手排查问题转变为直接根据Event Analyzer的聚合告警信息联系对应服务的开发者解决问题。同时，发现了很多以前被经验标记为系统抖动没有重视的潜在问题。至此，我们的微服务架构在调用链和立体监控的双重加持下，又完成了一次进化。

低延迟与用户体验杂谈

发表于由
回复

最近在做系统设计梳理的时候，明显感觉到「低延迟」已经成为被提及越来越频繁、考量权重越来越大的因素。 并且，越是靠用户近的系统，对延迟越敏感，对用户体验影响越大，对低延迟要求越高。

HTTP/2如今（2018.02）已经逐渐普及，其设计的第一目标就是降低延迟。主要采用了两个手段来解决：

  1. TCP连接复用。连接复用减少了TCP每次握手带来的延迟，同时避免了每次新建TCP连接的窗口慢启动带来的数据吞吐开启延迟。
  2. 使用数据分帧解决队头阻塞问题。当然，这个问题HTTP/2解决得不彻底，具体可以参见《当我们在谈论HTTP队头阻塞时，我们在谈论什么？》了解细节。

HTTP/2毕竟只能解决应用层的低延迟问题。如果要继续降级延迟，就需要下潜到传输层。因此，Google的QUIC和TLS 1.3应运而生。QUIC目前主要是Google主导，除去其自家的服务，如Google搜索首页，G+等，支持的网站还非常少。TLS 1.3则由标准化组织加持，目前在最新的OpenSSL、nginx已经支持。TLS 1.3能够做到新连接3RTT，恢复连接2RTT（TLS 1.2分别是4RTT, 3RTT；而2RTT已经与http的RTT持平！），的确非常吸引人。

回顾WEB技术过去十几年的发展，很多的特性引入和改进都是基于降低延迟。有些是技术层面的，比如上面提到的HTTP/2的低延迟设计、DNS查询缓存、HTTP1.1并发多个TCP连接请求资源、雪碧图等；有些是用户体验层面的，比如异步加载/预加载js资源、优先加载影响首屏渲染的CSS资源、避免使用大表布局、图片渐变加载、过渡动画等。

而这些年技术层面的发展其实都是受物理定律限制的。祭出程序员延迟心经Latency Numbers Every Programmer Should Know:

软件工程师无论是做什么职位和方向，心里都应该对此有B树。

有了这些当前人类所认识的物理极限，才能做到在「在边界内做事情」(这句话不是我说的，第一次看到这句话是吴军老师的《硅谷来信》)。

举个例子，当前人类认知范围内最快的速度是光速，这是一个上限，而广泛使用的光纤通信速度大概是光速的2/3。那么，要想优化上海到加州的网络延迟，无论你如何优化线缆布设以及质量，RTT都不可能低于127ms. 因此，如你所见，这些年虽然新架设了不少新的跨太平洋光缆，但是最优网络延迟没有什么太大变化，反倒是这些光缆带来的扩容让网络拥塞得到了缓解，让我们感觉出口网络「好像」更快了。

那么在光速这个物理边界的限制下，我们要如何降低延迟呢？显然，固定的两点之间的网络延迟是无法突破该边界的（这里不讨论空间扭曲力场?‍♀️）。但是，很多时候，我们要解决的问题是「让用户感觉延迟低」就可以了。

在这个思想下，CDN应运而生。将内容分发到距离用户近的网络节点来降低用户访问延迟。这个idea非常简单，甚至简陋，但是非常有效，并且廉价。

顺着这个思路下去，如果把算力分发到距离用户近的节点，那是不是也可以让用户觉得计算任务也变快了呢？在一定程度上，这是可以做到的。比如，我们使用了数十年运行于浏览器的javascript，以及我们的多IDC、多主架构方案，都有这方面的考量。近来流行的serverless、边缘计算其实也可以是认为是将算力部署到离用户尽可能近的物理位置或业务流程中。

有时候，技术参数指标的提升在短期内是难以低成本解决的。这个时候，尽量避免死磕参数，投入100%的精力去换取1%的性能提升。可以尝试从设计交互上给用户形成反应很快的体验，降低体感延迟。比如，1）耗时的任务后台化并给出进度条；2）区块处理的逻辑任务尝试修改成流处理，加速部分处理结果的输出，典型应用如以视频直播服务为代表的流媒体服务全力优化首屏播放延迟；批处理任务每处理完一个子任务就反馈结果等。

不仅软件系统的延迟影响着用户体验，硬件更是如此。现在人们普遍认为iPhone的用户体验是优于安卓的。因素有很多，那些复杂的系统参数普通用户未必搞得懂，但是很多用户却承认在滑动屏幕的时候iPhone比安卓更加「跟手指」，打开应用也「感觉更快」。「跟手指」这个体验跟苹果的软件+硬件的技术优化有关，目前安卓阵营也没有赶上。打开app快则是典型的交互优化：苹果打开app未必真的比安卓快，但是从点击app图标到显示story board的确非常快。无论苹果是否鸡贼，至少从这个层面看，它的确是非常了解延迟与用户体验之间的奥义的。至于苹果每次升级系统「故意」让老设备变卡……咳，咳，同学，你怎么有又抬杠呢?

喜欢汽车并且喜欢驾驶的朋友一定知道甚至深入研究过这几款车：马自达3/6/BRZ/86-宝马M2/M4-保时捷718/911。排名分先后，每一辆都是不同级别的驾驶者之车，也是很多玩车朋友的玩车升级路线。这些车都是「运动取向」，这是一个非常抽象的概念，普通消费者未必明白，但是你会发现他们的消费者大多会用「操控好」「响应快」来评价这些车。如果你是参数党，你会发现其实这些车在同级别中都不是最好的，但却是给人愉悦感最强的。

由物及人，当上司交给你一个任务的时候，有反馈好过无反馈，快反馈好过慢反馈。

总结

在节奏日益变快的今天，低延迟很多时候意味着良好的用户体验。而做到低延迟可以通过技术优化，也可以通过一些产品的交互方式和有选择的强调某些方面来让用户感觉很快。内容比较分散，但是都是顺着这根主线，希望你也有所思考和收获。

参考文献

Introducing Zero Round Trip Time Resumption (0-RTT)