Introduction

Go内存模型指定了一系列条件，在该条件下，可以保证在一个goroutine中对某个变量的读取操作可以观察（observe）到其他goroutine对这个变量写入的值。（内存可见性）

Happens-before

指令重排序对goroutine内部的读写顺序可能有影响，但不会影响代码定义的当前goroutine整体的行为。
例如在goroutine1中有代码a = 1; b = 2;，在其他goroutine中可能观察到b先于a赋值，但对于goroutine1，其行为不会因为指令重排序发生变化。

Go语言中的Happens-Before：Happens-Before定义了内存操作的顺序。如果e1 happens-before e2, 则 e2 一定在e2发生之后才发生。如果e1 e2 没有happens-before的关系限制，则e1 e2是并发发生的。在单个goroutine内部， happens-before 次序就是程序定义的顺序。

读取操作r对变量v 可以观察到写入操作w对变量v的写入，必须同时满足如下两个条件：

1. r不能先于w发生
2. 没有其他的对变量v的写入操作w‘ 晚于 w 但 先于r发生

读取操作保证能观察到写入操作w对变量v的写入，必须同时满足如下两个条件：

1. w 先于 r发生
2. 任何其他对变量v的写入操作，要么先于w发生，要么晚于r发生。

为什么需要Pod

1. 在工业实际部署中，经常需要多个进程部署在同一个节点上。类似于Linux操作系统中的进程组的概念（pstree -g 命令查看进程组），他们之间有着”超亲密关系”，例如相互之间会发生直接的文件交换、使用localhost或者Socket文件进行本地通信、共享某些Linux Namespace等。
2. 容器的”单进程模型”，PID=1的进程往往是应用本身，无法像正常操作系统中的init进程那样拥有进程管理的功能。
3. 存在”超亲密关系”的进程，需要按照严格的拓扑顺序启动。也就是需要对容器成组进行调度（gang scheduling）。
   基于上述原因，Kubernetes提供了Pod这个逻辑概念，将需要在同一节点上，可能共享Namespace以及其他本地资源的容器进行成组调度。

Pod的实现机制

Pod是逻辑概念，其实是一组共享了某些资源（Network Namespace）的容器组。在没有成组调度时，如要实现容器A和容器B共享网络和Volume，可以通过如下命令实现：

要解决什么问题

可以方便的将用户应用的镜像部署到集群，并提供路由网关、水平扩展、监控、备份灾难恢复等一系列运维能力。这些问题，其实一个PAAS平台都可以解决。

除了解决以上问题，Kubernetes项目区别于其他PAAS平台，重点要解决的问题，来自于Borg项目的研究人员在论文中的一个重要观点：

运行在大规模集群中的各个任务之间，存在着各种各样的关系。这些关系的处理，才是作业编排和管理系统最困难的地方。

需要什么样的架构

• 节点分为控制节点Master和计算节点Node
• Master节点包含kube-controller, kube-api-server 和 kube-scheduler三个组件
• Node节点中的核心组件kubelet：
  • 通过CNI(Container Networking Interface)与网络插件交互，配置容器网络；
  • 通过CSI(Container Storage Interface)与存储插件交互，配置持久化存储；
  • 通过CRI（Container Runtime Interface）与容器运行时交互，定义容器运行时的各项操作。
  • 容器运行时通过OCI容器运行时规范，与Linux操作系统交互。
    Read more »

在吴军老师新书《态度》写给其女儿一封信中，提到了如何有效地沟通：

第一，有效的沟通要以对方确认为准，不要以为话说出去，别人就一定能接收了你传递的信息。
（那么反过来，自己要做到对别人来讲”靠谱”，就是”凡事有交代，件件有着落，事事有回应。”）

第二，要以对方听得懂的话来沟通，不要把简单的问题讲复杂了。 这里作者举了一个很好的例子：

中国的顾维钧先生是一个优秀的外交家，他在1919年的巴黎和会上向西方国家的代表讲述山东省对中国的重要性时，是这样说的：
孔子对中国人来说，相当于耶稣对西方人一样重要。西方人一直把耶路撒冷作为圣地，并且上千年一直要夺回那个地方。
山东是孔子的出生地，它在中国人心中的地位，相当于耶路撒冷在西方人心中的地位。

简单的几句话，就把意思说明白了。对方能听懂，不是因为对山东和孔子有多么熟悉，而是因为熟知耶路撒冷和耶稣。

第三，沟通要简洁，切中要害。对不同的人，表达方式也不一样。

第四，善辩不等于好的沟通，沟通的目的是让对方接受自己的想法，而非把对方驳得哑口无言。

当网络刚刚出现

当人们刚想到让两台计算机通信，模型是这样的：

但上面过于简单的建模，无法使任意两台计算机之间的通信变得通用。分层的网络协议，使应用之间的通信时，应用本身不用关心网络的底层细节，例如如何拆包粘包，如何将字节序列转化成电信号等等。

上面的模型依然存在问题，因为应用A在向B发送请求和数据包时，并不知道B是否能处理过来，如果B不能及时处理网络包，则会丢失数据。因此应用除了业务逻辑之外，还需要有专门的模块控制数据包的发送速度。

幸运的是TCP/IP传输层协议的出现，从底层解决了流量控制和拥塞避免的问题，实现了可靠传输。

上面的模型也成功的沿用了很长一段时间。

微服务出现

随后计算机逐渐变得便宜，出现了更多的节点和更可靠的网络连接。业界开始使用各种类型的网络系统，出现了更细粒度的分布式agent和面向服务的体系架构（SOA，Service Oriented Architectures）但依旧较重的服务组件。

90年代，Peter Deutsch和他的同事共同提出了有关分布式系统的8条错误假设(The 8 Fallacies of Distributed Computing):

• 网络是可靠的
• 没有延迟
• 带宽无限大
• 网络是安全的
• 网络拓扑不会改变
• 只有一个管理员
• 传输成本是0
• 网络是同构的