《righting software》是 Pearson 出版社 2020 年出版的一本书，作者是 Juval
Löwy，今年国内也引进了这本书，中文名是《架构之道》。
中秋期间读完了这本书里我比较关心的部分，本文将其中的一些核心观点进行摘录。
作者首先总结自己几十年的经验(先表达一下羡慕)，提出了靠谱软件的设计方法，称为 The Method(中文译成了元方法)：
The Method = System Design + Project Design
这本书也就被分成了这两部分，System Design 和 Project
之前陶师傅推荐过这么一篇文章，Complexity has to live somewhere
[https://ferd.ca/complexity-has-to-live-somewhere.html]
，大致意思是系统的复杂度是没法凭空消失的，只能从一个地方转移到另一个地方，因为现实世界的逻辑就是那么多，边边角角的 case
就是那么多，你必须要处理，这必然会给系统引入复杂度。
尽管这些复杂度你可以转移给你的同事，或者外包给第三方系统，但复杂度是不灭的。
设计系统时，我们要注意到这一点，同时要管理好复杂度问题。
在《a philosophy of software design》这本书中，作者也提出了一个不一样的，
本人现在暂时是无业状态，所以本文不代表任何雇主观点。
到了 2021 这个时间点，大多数公司都决定拥抱云原生，但不少程序员对云原生的理解局限于“原生基于 k8s
的应用”。公司只要上云(k8s)了，就是拥抱云原生了。稍微理解多一点的人觉得除了 k8s，我们只要上了 service mesh，就是拥抱云原生了。
cncf 给云原生的定义其实非常地庞杂：
> 云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式
API。
> 这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，
Go 1.17 修改了用了很久的基于栈的调用规约，在了解 Go 的调用规约之前，我们得知道什么是调用规约。
x86 calling convention [https://en.wikipedia.org/wiki/X86_calling_conventions]
，简单概括一下，其实就是语言对于函数之间传参的一种约定。调用方要知道我要把参数按照什么形式，什么顺序传给被调用函数，被调用函数也遵守该规范去相应的位置找到传入的参数内容。
老版本的 Go 的参数传递图我们已经在很多很多地方见过了，这里贴一个我之前画的：
可以看到入参和返回值都在栈上，按顺序，从低地址，到高地址排列。
这种基于栈的传参在设计和实现上确实要简单，
最近翻看了一些 Google 的老文章/论文，发现 Google 有不少系统的设计文上都写着 planet
scale，行星级，口气那是真的大。仔细想想，FAANG 这样能把生意做到全球的互联网公司，除了这五家，也没几家其它的了，人家确实有吹行星级的资本。着实羡慕。
Google 的员工出来创业，公司名也是 TailScale(似乎是做 vpn 的)，PlanetScale(这家似乎是拿着 vitess 出来创业的)
这样，说明 ex-googler 也是比较喜欢这家公司的文化的。
