查看原文

Microservices 的注意要点：单一职责，松耦合，Conway 定律。

• 单一职责：设计一个软件组件，使其做一件事情，做到最好。现在大多数 microservices 有两种类型：web services & messaging workers。
• 松耦合：软件组件之间的依赖关系尽可能低。这意味着组件挂了会降低对别的服务的影响。
• Conway 法则：一个自洽的组织，设计出来的服务也会像这个组织一样高度独立。服务可能会有自己的数据库，开发团队也可能不会有专职 QA & DBA 来跟进。

查看原文

本文是关于软件复杂度的好文章，Vista 是个失败的系统，十年之后，在后续的开发中，微软吸取了很多经验。

上千个工程师，测试，项目经理，安全，设计，销售跟进开发 Windows。Windows 内部有核心，服务器，客户端三个组，核心管内核供其它两组用，服务器管服务端市场，客户端管桌面系统。

操作系统三年发版，但只有其中六到九个月真正在开发新代码，剩下都在集成测试测试测试。有些比较耗时的项目写完后才合进来，那个时候主干仓库几乎就是半瘫痪不能运行。每个组都有自己的日程，进度不一搞得很多组不得不在最后时刻冲刺调试。作者认为三年一版这样做根本跑不赢市场。解决方案就是要加速！像 cloud service 那样更快的将特性推到市场去。

课后习题：文中的 Play schedule chicken 是啥意思？

查看原文

DevOps 很重要的关注领域是部署。部署关心以下这几件事情：调度，兼容，环境，回滚：

• 如何调度部署
• 部署的组件相互兼容
• 部署的组件可以在各种环境里运行
• 迅速回滚到前一版本
• 错误检测和监控

查看原文

BGP 是互联网的路由基础技术，是基石，透过 BGP 承载的流量，我们可以窥见整个互联网的进化。简单来说，BGP 可以让路由器学习互联网的路由结构，然后路由信息的变更也会通过协议传导到所有相邻节点。每个节点会给一跳一跳的数据包挑最好的路线走。

节点里的路由表的增长会让机器性能趋于极限。另外路由表内容的更新需要本地好几次数据查询，系统要保证有能力处理更新。自 1994 年有 BGP 系统的数据依赖，整个 IPv4 & IPv6 路由表在过去的二十多年里每年都在变大。

查看原文

Redux 中的核心是 state（状态，数据），Redux 就是管理 state 的工具。我们在设计系统的时候，会有如下两种常见场景。

• 全局 state 逐层注入到子组件中。
• 子组件可能会有 state 回馈回父组件。

由于系统组件像树一样组织，这个数据流向会扩散到到各个组件。想象一下，一旦这个流程超过三五级，系统中存在几十上百种这样的流程，那简直就是没法维护。那怎么解决呢？Redux 的方案是引入一个 message bus 和一个小数据库。引入这两个组件以后，系统的数据流只有一条，稍微好维护了一些。

衍生思考：对数据流进行抽象，是简化系统设计的一个方法。

查看原文

CPython 中字符串是不可变对象，解释器有可能会将一些字符串指向相同的对象以节省内存。这里有一些 intern 的规则：

• 长度为 0 或 1 的字符串是 interned 的。
• literal 的字符串是 interned 的，动态拼接的不是，例如 "WTF" 是，"".join(["W", "T", "F"]) 不是。
• 对于第二条规则，加一个特例，字符串中只能出现字母数字和下划线，否则就不是，例如 "WTF~" 就不是。
• 对于第三条规则，再加一个特例，在交互模式中，如果出现了 a,b="a!","a!", 这个字符串又是 interned，原因是解释器优化。

另外，文章提及了几个边界 case：

• r …

查看原文

简洁就是美是 Unix 的一个信条，这个网站归纳了一些具体操作的实践指南。

• 砍！慎重丢掉不重要的功能。
• 有条不紊地组织！系统通过坚持不断地将无序变为有序，从而走向简洁。整理组织的核心问题就俩：放在哪里，藏在哪里。
• 想想怎么操作会省时间。
• 深入学习<磨刀不误砍柴工。
• 参考复杂的设计，做出简单的设计。

查看原文

小时候觉得长大比较好可以做各种好玩的事情，但很多人长大后发现要赚钱，不行，很多时候很痛苦一点也不好玩。但也有一些人工作地非常开心，不仅做的事情自己喜欢，成果也是同事们认可的。本文作者 Paul Graham 提出的观点是（也是借用别人的）：做一件让同事朋友觉得你很厉害的事情，同时坚持实践下去。如果工作一开始就不是自己喜欢的，那就让自己能力变强，到最后就是你挑工作，而非工作挑你。

衍生思考：从心理学的角度考虑，正向反馈非常重要。也许财务自由并非是最快乐的事情，一直在做喜欢做的事情的那些人真是很羡慕。我的建议：搞清楚自己喜欢什么，然后一头扎进去做。就像我现在在做 Techshack 一样，做的很开心 :)

查看原文

Airbnb 家的支付系统遭遇的挑战是全球化服务面临多币种多支付网关，核心问题在异步的，分布式的系统里保障事务的一致性。这个流程中需要注意的地方是要做好追踪，一旦断掉一环，就很有可能出现错误和数据丢失。他们解决方案第一保障数据链完整，第二一旦检测到不一致立马自动修复。

整个交易流程中会遇到买卖方，银行，支付网关等等，每个实体都会往支付数据中注入自己的数据。支付系统需要保证的是帐要绝对算对。这里面遇到的支付方有些甚至奇葩到好几天才能帐目生效。也许网络不好，也许某方bug，也许其它原因，支付链条里只要有一方不响应或停止数据流动，整个事务就坏了（out-of-sync)。

好在这类型系统每一方都提供事务报告（transaction reports），我们可以根据事务报告，源头的帐目文件，以及银行流水。在排除掉重复文件后，我们是有办法检测到是不是有一个事务的链条断掉了。

Airbnb 还提供了一条流水线专门跟踪支付退款等数据，从监控的角度来看，他们基于支付的业务来监控整个系统的可用性。Operation 可以很容易将这种指标纳入监控从而进行快速事故响应。

查看原文

给出这个命题，能给出一个不错的解答其实需要大量的涉猎，作者给出的答案是 router_cr(crystal) 最快，Python 框架中最快的是 Japronto，语言上 crystal > rust > python > go, 但也得看具体框架的性能。测量的基准是 8 核 CPU 的 CPU，遵循的 Rule 是无逻辑，就是做 route 解析和响应生成。