又读到一篇很好的文章，忍不住就翻译了过来。每个月我可能会读一百来篇来自英语世界的文章，其中可能有些好文会让我忍不住想翻译过来分享下，这也算是百里挑一吧。

今天是西方的「情人节」，读到一篇很有趣的文章，算是今天这个“特殊”日子的特别篇吧。对于我这种孩子都快打酱油的人来说，只能感概早该读到这样的文章的，当然现在读到也不晚 :)。

去年以来关于人工智能（AI）的讨论非常火热，最近读到一篇这个主题的文章觉得非常不错，翻译过来分享下。这不是一篇烧脑的关于人工智能技术文，而是一篇开阔的思辨性文章。

今年连续两场年会中开会的环节都是最长的，北京场开了整整一天，成都这场也开了半天。以前曾写过一篇关于程序员和会议的文章《程序员都讨厌开会？》，其中提及关于参会原则：“若没有在会议上发言的潜在可能，就不需要参加。”，但年会呢，却是唯一个比较特殊的会议，属于该原则的特例。

最近线上碰到一点小问题，分析其原因发现是出在对 RPC 使用上的一些细节掌握不够清晰导致。很多时候我们做业务开发会把 RPC 当作黑盒机制来使用，但若不对黑盒的工作原理有个基本掌握，也容易犯一些误用的微妙错误。

今年初，正好是工作的第十个年头，再次在公司技术职级这条路上晋级了一小步。这一小步也基本走到了我曾在《程序员的成长阶梯和级别定义》 一文中写过的资深级尽头。再往后如果继续走技术之路，似乎就该走上「专家」之路了，但我没有立刻迈步，而是在此停留思考了一阵。

近一年公司在努力推进全站的 HTTPS 化，作为负责应用系统的我们，在配合这个趋势的过程中，顺便也就想去搞清楚 HTTP 后面的这个 S 到底是个什么含义？有什么作用？带来了哪些影响？毕竟以前也就只是模糊的知道大概是更安全，但到底怎么变得更安全的，实际上整个细节和流程并没有掌握的特别清晰。

本文翻译 Scott H.Young 的博文 Two Types of Growth，读到这篇立刻激发了我的元认知模式，好好回想了一下过往的大部分经历，确实如此。所以翻译过来，分享给大家，看看如今你处于哪种增长类型的哪个阶段？

李笑来老师的专栏开设有一百天了，在上周日的推送中公开向读者征集一百天来的成长反馈。我刚看完一下涌上了很多经历和想法，本打算赶快写上一篇反馈的，但一周以来一直没能抽出一整块的安静时间来。临到周末，闲了下来，干脆就以此为题，认真写上一篇关于成长的记录与心得吧。

看过一部电影，引发点思考感想，写出来，这叫「影评」；听过一首歌，引发点思考感想，写出来，这叫「乐评」；看过一本书，引发点思考感想，写出来，这叫「书评」。

如果云时代如我们今天所设想的那般，云计算如水电气一般成为互联网的基础设施，无所不在般的到来，那这的确又是一个巨大的技术时代变迁，而感觉上一次我所经历的技术变迁是从传统的 IT 到互联网。

刚过去不久的七月，火辣辣的热，在这份热辣中却也有一份略显冰凉的愁绪。一批刚毕业的学生刚告别了校园，进入了职场，一个新的江湖。这次来到我所在公司的同学，不说全部，至少百分之九十五都会成为一名新入行的程序员了。

这几年来每次碰到性能问题，我都会想起这篇文章，它并不像很多其他关于性能问题的文章，告诉你利用什么工具怎么去解决性能问题，这类文章更多属于「术」的层面，而术的层面在不同的技术栈会有很不同的选择。而本文则高屋建瓴的帮助读者建立起对性能的正确认识，从而能够获得更全面的视角去看待和思考性能问题。这是「道...

我记得上次参加技术大会已经是三年前了，现在各类技术大会似乎比以前多了不少，参加这类大会的价值有多大呢？我想先从我自己以前参会的一些经历来说说。

今天打算写写关于 IM 去中心化涉及的架构模型变化和设计思路，去中心化的概念就是说用户的访问不是集中在一个数据中心，这里的去中心是针对数据中心而言的。

咚咚是什么？咚咚之于京东相当于旺旺之于淘宝，它们都是服务于买家和卖家的沟通。 自从京东开始为第三方卖家提供入驻平台服务后，咚咚也就随之诞生了。 我们首先看看它诞生之初是什么样的。

又过了一年 618，六月是公司一年一度的大促月，一般提前一个月各系统就会减少需求和功能的开发，转而更多去关注系统可用性、稳定性和管控性等方面的非功能需求。大促前的准备工作一般叫作「备战」，可以把线上运行系统想象成一辆车，大促即是它即将面临的一次严峻驾驶考验。

2011 年，当初选择 Redis 作为主要的内存数据存储，主要吸引我的是它提供多样的基础数据结构可以很方便的实现业务需求。另一方面又比较担心它的性能是否足以支撑，毕竟当时 Redis 还属于比较新的开源产品。但 Redis 官网宣称其是提供多数据结构的高性能存储，我们对其还是抱有幻想的。

如果再给我一次回到好几年前的机会，对于使用 Redis 我一开始就要好好考虑将来的扩展问题。就像我们做数据库分库分表，一旦决策了分库分表，通常一次就会分到位，比如搞上 8 或 16 个库，每个库再分 256 或 1024 个表。不管将来业务再怎么发展，基本这个量级的分片都足够应对，而且底层库可以做成逻辑的，扛不住时再换成...

最近听了吴瀚清（俗称道哥）分享安全，他是西安交大少年班毕业，专注于安全技术领域，23 岁加入阿里巴巴成为集团最年轻的高级技术专家，目前在阿里任 P10 职级。对于这类少年天才，一般会冠与神童的美誉。

在系统引入 MongoDB 也有几年了，一开始是因为 MySQL 中有单表记录增长太快（每天几千万条吧）容易拖慢 MySQL 的主从复制。而这类数据增长迅速的流水表，对数据一致性也没那么高要求，而且业务上也不需要关联查询它，就考虑分出去。为什么是 MongoDB？刚巧赶上公司 DBA 团队引入了这个数据库，有人帮助运维，对业务团队...

今天分布式应用、云计算、微服务大行其道，作为其技术基石之一的 RPC 你了解多少？一篇 RPC 的技术总结文章，数了下 5k+ 字，略长，可能也不适合休闲的碎片化时间阅读，可以先收藏抽空再细读:)

两年前接触到了微服务的概念，面对日益膨胀的系统感觉豁然开朗。之后的两年逐步把系统按微服务的架构理念进行了重构，并将业务迁移到了新架构之上。感觉现在差不多是时候写一篇关于微服务的总结文章了。

拜占庭位于如今的土耳其的伊斯坦布尔，是东罗马帝国的首都。由于当时拜占庭罗马帝国国土辽阔，为了防御目的，因此每个军队都分隔很远，将军与将军之间只能靠信差传消息。在战争的时候，拜占庭军队内所有将军必需达成 一致的共识，决定是否有赢的机会才去攻打敌人的阵营。但是，在军队内有可能存有叛徒和敌军的间谍，左右...

前段时间应 CSDN 邀请审核 Java 知识库内容，借此我也有机会好好梳理了下自己的 Java 知识体系， 成文一篇望能帮到即将走进或正在 Java 世界跋涉的程序员们。

作为后端应用的开发者，我们经常开发、调试、测试完我们的应用并发布到生产环境，用户就可以直接访问到我们的应用了。但对于互联网应用，在你的应用和用户之间还隔着一层低调的或厚或薄的负载均衡层软件，它们不显山不露水默默的发挥着重要的作用，以至于我们经常忽略了它们的存在。因为负载均衡层通常不在一般开发人员...