查看原文

在 Kubernetes 之前，软件行业没有统一标准可以在分布式系统中编排应用的节点。基本上，大公司诸如 Google, M$, Amazon 等都已经在使用 Kubernetes 部署应用了。本文讨论了为什么会是 K8S, 以及程序员该如何应对。

• 像 Docker 成为打包的标准，Kubernetes 成为了分布式平台部署的标准。Kubernetes 基于容器的概念继续封装，解决诸如以下这样的问题：容器间怎么通信？容器怎么扩展？容器怎么分派流量？同时期有 Mesos，Swarm，甚至有人只用 Puppet / Chef 这些工具来编排容器。在 2016 年底，Kubernetes 差不多成为这个领域的赢家，差不多主流公司都相继吃进 Kubernetes 这套技术。
• 容器编排的需求：部署调度，资源管理（内存，CPU，GPU，硬盘，IP …

查看原文

本文作者的观点是，如果你有一个 CLI，你也可以选择将其写成一个 Server。作者认为基于 CLI 这种字符串处理脚本或命令的集成，整个系统会比较脆弱。相反地，应该写成 (HTTP) Server 的形式。这样，我们会有统一约定的 API（比较稳定，有版本）。作者认为的比较合理的做法是，将逻辑写在 Service 里面，但用户也可以通过 CLI / Server 两者来交互。开发 CLI 工具需要很清楚使用场景。事实上，Docker 就是遵循这样的设计范式的工具。

查看原文

Netflix 家观测他们复杂的微服务架构的方法是，引入一个自己撸出来的工具 Flux，方法是可视化观测流经系统的所有流量。他们的需求是：要看实时数据，数据主要是容量+延迟+请求的健康，能看到服务依赖，能在网络层看到流量，最好能钻到 IPC 级别查看流量。

一般来说，只要我们能把监控的东西转为报警或者阈值，那我们就能自动化。但对于那些实在说不清道不明的东西，只能引入人来分析，而可视化就是很好地工具：人脑最适合处理大量的视觉数据，并发的，多维的。

他们最终的呈现方案是一个图片，四个圈，分别代表互联网和三个数据中心；这四个圈互相发送光点代表发送流量。可以通过观察这些观点的数量和颜色（红色代表错误）来得出结论，一个数据中心是不是OK的。

查看原文

本文作者在 AWS 干了十年，总结了十个觉得有用的注意的地方，例如拥抱失败，避免本地状态，不可变式的架构，架构即代码，异步与事件驱动，数据库 Sharding，测量，应急预案，写代码的人负责运行，等等。

• EMBRACE FAILURE: 学东西，只看书看博客，不如弄脏自己的手，搞出几个错误来！不过在线上的服务，需要确保有回滚或者服务降级控制等机制，这样线上的失效才是可控的。Chaos Engineering 是作者认为这辈子最值的做的十件事之一。
• LOCAL STATE IS A CLOUD ANTI-PATTERN: Local State 在这里意味着有数据会因为应用被杀掉而丢失，解决办法就是将 state 放到 Memcached / Redis 中供所有实例中共享。迁移服务到云平台上，可能首要解决的问题便是处理 state。另外提到的一点是：看清场景，有些 state …

查看原文

ChAP 是 Netflix 的 Chaos 自动化平台，用于从服务级别提供像 混乱猴子(Chaos Monkey) 之类的功能。他们仍然将试验放在 Production 上做，当然，不会影响到用户体验。这意味着他们需要权衡风险和到底试验能得到多大的成果。在 ChAP 这个平台上可以写一个任务，然后平台会切一部分流量均匀分布到一个可控的集群上做实验。他们设定了一个断路器，当试验超过了错误阈值，就会自动停止试验。有了这样的系统，就很容易做 Canary Analysis 了，在滚动部署的时候，就能预先发现问题。例如，评分系统要上线，切 0.5% 的流量到上线的金丝雀环境，这也意味着几乎 100% 的功能都会被测试到。

查看原文

正常加载资源需要经历 DNS 查找，TCP 握手，TLS 协商等环节才能开始下载数据，我们可以引入一个 preconnect 的提示让浏览器预先连上网站，从而加速资源的获取，提高网站的性能。具体做法在 link 标签里面填写 rel="preconnect", href="https://the-website-you-want-to-connect" 即可。在本文的示例中可以看到在设定了 googlefont 的预先连接后，资源加载时间减半。需要注意的一点是，crossorigin 标识在这个场景下是必须的，因为字体加载是异步的操作。另外注意的一点是，这个标识只是给浏览器的 hint，具体能不能生效，得看具体的浏览器，一般来说，chrome 会没啥问题。

查看原文

entr 的功能六个词说清楚：Run arbitrary commands when files change。示例：

ag -l | entr make

它的基本使用场景是“修改-测试”这样的循环。它的基本假定是文件查找那部分交托给更好的程序，例如 ag, ack, grep, ls 等。它的设计哲学是接口最小化，尽可能简洁。甚至于对于新增文件的用户都需要自己写下 while true; do ls *.py | entr command。

简单也意味着强大，它可以跟很多工具配合起来使用，例如 pkill, tmux, reload-browser 等等。另外，简单的接口不意味着它面对的场景简单，事实上，它的正确实现要考虑很多细节，例如 NFS 文件系统上 inotify 通知不一样 …

查看原文

技术更新换代很快，程序员得有居安思危的意识，不断开阔眼界，才能不被时代淘汰。以本文为例，作者试图解决一个从有向图中找无向图的问题，用上了各种优化的算法技巧，但最后发现其实相对简单的做法是把一行 Python 代码 edges = edges.intersection(edges.map(lambda x: (x[1], x[0]))) 部署到 Spark 集群里即可。

技术进步，往往带来了更简单和优雅的解决方案。为此，作者认为可以向懂得新式编程范式的人虚心请教。另外，作者也觉得修炼内功依然很重要，对CS 学科的基础知识要足够扎实。

查看原文

响应式宣言，是指一种系统架构方法，系统能够快速响应，故障自回复，负载变化能够伸缩资源，以及基于异步的消息传递（Responsive, Resilient, Elastic, Message Driven）。在系统设计之初就考虑这些以后会省心不少。

• Responsive: 系统尽可能地在给定时间里给出响应。
  • 这个特性意味着我们可以快速高效检测系统的可用性。
• Resilient: 即便面临 failure，系统仍然可以给出响应。
  • 这样的特性不一定非要是高可用的系统才需要满足，普通系统也可以做到，技巧：replication, containment, isolation, delegation.
  • 系统的部分可以失效，但整体仍然可以响应。
  • 系统的每个组件恢复，可借由另外的组件来完成。
• Elastic: 负载变化，能够通过增加或减少资源来处理请求。
  • 这个特性意味着系统必须得很容易 shard / replicate
• Message Driven：
  • 系统组件之间更多地靠异步消息来传递信息。

查看原文

HTTPS 比较难理解的部分就是密码学的部分，比较学术的解释是通过 Alice 同学和 Bob 同学，本文作者尝试用信鸽来解释 HTTPS。

• Bob 用信鸽给 Alice 发了空消息。
• Alice 让信鸽把开着锁的箱子送回给 Bob，给自己留下了钥匙。
• Bob 把信息放入箱子，锁起来，送回给 Alice。
• Alice 收到箱子，用一把只有自己能打开的钥匙查看信息。

一个问题是 Bob 怎么确保这个箱子真的来自 Alice，而且没有被人调包过。解决方案是引入 Ted，一个值得信任的人，让 Ted 给箱子签名，大家都信任 Ted。

这就是非对称加密：你可以公钥加密任何信息，但只有有对应那把私钥的人才能查看消息。Ted 在这个系统里就是 Certificate Authority，管签名的。

另一个问题是箱子太重：非对称加密比起对称加密太慢。我们的解决办法是只用这个方法传输 …