困惑

内容简介：困惑

讲几则小事，都发生在最近。几则小事互不相干，但是，是我最近生活的真实体会。

三十而立

吾十有五，而志于学。三十而立。四十而不惑。五十而知天命。六十而耳顺。七十而从心所欲，不逾矩。 《论语·为政》

昨天一位相当要好的朋友生日，与这位朋友相识也是巧合，赶上了14年创业的大潮，恰好国内前端SPA开发刚刚兴起，当时我负责整个前端团队的开发。我这位朋友放弃了丰厚的薪水和优越的生活条件，在复旦旁边租了一套两层的复式大伙儿就开始干。第一次创业的拼劲很足，尤其是看到自己做的产品在高校内很受欢迎，心中的满足感油然而生。好多次大家奋斗到凌晨，夜深人静的时候撸串也会聊聊生活，谈谈理想。那段时间很幸福，虽然很累。在整个团队中，我这位朋友应该是最年长的一位，也许是因为他以前在银行做投资，在工作中，他分析问题的条理很清楚，思路也很灵活，并且作为CEO他确实能够看得更为长远，这点我相当佩服。后来因为私人原因我又重新回到了法国工作，这个创业项目已经做的很不错了，还记得当时办公室有张中国地图，上面标注着我们的产品所铺及的区域，每次看到都会感到震撼。

也就在公司逐渐步入正轨的时候，内部出现了一些问题。人心不齐，而千里之堤溃于蚁穴，后来发生的事情以及资本的干涉让这家公司几乎在一两周内崩塌。我朋友经历了从无到有，又残酷地经历了从有到无。事后，很多人谈起这个创业项目，会摆出一堆的大道理，讲资本泡沫，风口，可我知道，事情绝非如此简单，人们会用言之凿凿的理由去臆断看到的现象，但除了亲身经历过，谁也没有办法感同身受，面对那样的局面需要有多大的勇气。

朋友经历他最痛苦的那几个月，后来尝试了不同的方向，现在做回他的老本行，在金融和医疗间寻找突破点。昨天party上听几个合伙人闲聊，月流水已过千万。他昨天party上说的最多的一句话，就是觉得他现在变得平静了。

是啊，经历了这么多，那些生活中的小困难又算得了什么呢。

好的架构是迭代演进出来的

最近帮朋友做IoT的项目，涉及到很多高并发的场景，准确说是高并发与高可靠交错、需要双重保证的场景。比如说，对IoT设备心跳的处理肯定是利用高并发的架构去扛住巨大的流量，而对于每台设备上的支付请求则必须要用高可靠的方案去保证事物一致性。由于设备也处于早起摸索阶段，设备本身对于消息的处理机制也在不断的迭代，云端的解决方案也在不停的优化中。

最初，设备并没有直接上MQTT的解决方案，而是通过简单粗暴的单向HTTP请求来实现消息通信。主要分为两类消息，心跳和支付，对于心跳请求我们直接利用消息队列来顶住并发，心跳请求并不在乎返回的响应，所以做成异步处理效果更好，扩展性也更强。对于支付请求，由于缺乏设备反控机制，设备的控制只能又支付请求的响应来判断，这样做实属无奈之举，好在 Go 的并发处理能力足够强，对于支付响应我们充分利用了Redis，将整个业务异步处理，每次支付轮训尽量靠只做一次 Redis 请求来完成验证。这样的架构在1k左右的QPS时运行的很好。

后来，偶然的情况发现，支付和心跳两个API分开发送请求对电量的消耗影响还是不容忽视的，所以硬件团队决定将两个API合并，减少发送的Request数量，虽然我心里觉得这样根本不解决问题，而且由于心跳和支付合并，导致这里不能再用消息队列作为心跳的缓冲了，只能硬着头皮改我的Go来顶住所有的流量。其实原理也很简单，借鉴Nginx的异步思想，我充分利用了Channel的伸缩性，在每个Go的instance上维护了一个自己的消息队列，然后异步消耗批量处理。不同的地方在于，controller在接到request时需要对支付字段做一次校验，这里依然是依靠了Redis的强大性能。最终测试下来，4k左右的QPS也能轻松撑住，大概两个Medium Size的Go Instance。这里顺便吐槽下腾讯云跟阿里云的Load balancer，腾讯云的Round Robin算法是伪随机，一个IP永远只会被hash到固定的instance上，在instance数不变的前提下。而阿里云的LB是在第七层网络做的，腾讯云和Azure的LB都是在第四层做的，这样做的区别在于，腾讯云和Azure LB转发的request依然带着client IP，而阿里的LB只会带LB的IP，client IP被藏在了x-forwarded-for里面。

系统稳定运行了一段时间后，团队也在不停地扩大，BD的需求也越来越多，对于设备的历史状态的分析需求也越来越多，原本的 SQL 对高频且复杂的Query日显乏力，而Redis中仅保存了最新的设备状态。在此前提下，我开始引入HBase来管理如此大量的历史数据。在此之前也做了多方考量，考虑过几个主流的时间序数据库，以及ElasticSearch和HBase，最终选择了HBase，主要还是因为阿里和腾讯云都有现成的HBase服务，不需要自己搭建和维护，省去了很多成本，并在一定程度上保证了数据的可靠性（当然，这个决定也为后来的一些需求埋了坑）。在通读了Google的Big Table的最佳实践后，我开始着手开发历史数据的Data Store。同样，在这个系统中，也引入了热数据和冷数据的不同模块来handle不同的业务需求，这里以后再谈，我们正在演进第四套架构，在此保证设备一切正常工作的基础上，期望能够handle更多更丰富的上层需求。

各种面试

继上个月实习生疯狂面试之后，现在做phone screening和onsite都感觉更加淡定，不会像以前那么局促害怕犯错，说太多怕引导太多干扰candidate思考，说太少怕交流太少没有办法evaluate candidate的真实水平。

前几天给一个22岁的小伙子做phone screening，他拿过微软的MVP，在dotNet社区非常活跃，Github上面看到他在很多的organization里面。考虑到工程经验比较丰富，所以题目更偏数据结构，而不是tricky的算法。整体面下来两个感觉特别明显，一是太年轻，缺乏经验，不知道如何表达清楚，在谈简历的时候对很多项目的细节都没有说清楚，给我的回答无法切中要害。第二个是基础不够扎实，在这道数据结构的题目里面，由于对List.RemoveAt()这个函数的时间复杂度不了解，导致设计存在漏洞。我不能武断下结论说不知道这个时间复杂度就一定不行，但只要学过数据结构的人，把RemoveAt的实现稍微想一想应该就能得出答案了，这个不是死记硬背的知识。

除了这位小伙子，还面试了三四个工作五到十年的dev，有两个是interview + lunch，面试完之后再带过去吃饭，也没人告诉我吃饭的时候是不是还要继续考察，我基本就是跟candidate闲聊了。在这几个candidate里面，印象比较深的是有A和B两位，A擅长Java，人比较聪明，思维比较快，这点很不错。另外做的项目也不少，跟我们team做的内容也比较match，对于高并发以及分布式也有过实战经验，这个我们还是比较看中的。另一位candidate B，做了好多年的dotNet开发，对C#底层的实现很熟，这是个plus，在实际面试做题时，他能够非常职业地优先考虑线程安全、输入合法性、模版化等方面，这个很不错，而且在做完implementation，他还会提出做对应的Unit test和load test，这点是我之前面试的candidate中没有人提过的，big plus。

现在回头看看，面试了这么多轮，其实自己的收获也是非常多的，通过candidate，我能够更客观的看待自己的水平，取长补短。很感谢能在这么早起就能接触到不同的人，说不定这些面试技巧，以后也能帮自己一把呢。

社交网络

最近两周，一鼓作气把Black Mirror看完了，不停感叹编剧敏锐洞察力的同时，也不得不把自己生活的状态跟剧中的情节做比较。想到自己生活也就那样，难免看完一集都会郁闷好一会儿。网上对该剧的评论很多，这里就不长篇大论了。这里主要分享些网上别人没提到的。

编剧一定绝顶聪明才能观察如此细致，并能透过现实的表象看清其本质。不仅如此，编剧还能找到一个恰当的故事做载体，通过夸张的艺术手法将这本质呈现给观众。不论是像Hated in the Nation还是White Bear，其背后都涉及到了同一个问题，人性。互联网如此发达的今天，社交网络平台恰好给了人们自由表达的平台。就像人类简史里提到的那样，人类可以通过语言表达自己的观点，并借此收获一群簇拥自己观点的粉丝。回头想想，所谓的国家意志、阶级、宗教，这些人类所发明出来的以追求共同利益而抱团的现象，才是人类和动物最大的区别。

TODO: Not finished yet, to be completed.

以上所述就是小编给大家介绍的《困惑》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！

查看所有标签

猜你喜欢:

• 困惑
• 令人困惑的strtotime
• 令人困惑的 TensorFlow！(II)
• 机器学习中那些必要又困惑的数学知识
• android触摸事件分发机制，曾困惑你我的地方
• 【译】关于Webpack中一些让人困惑的地方的解答

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。