如何管理成千上万的访客（用户请求）和内部员工（服务间调用）的流动，确保一切井然有序、安全高效？这就是今天要讨论的这套“交通管理系统”要解决的问题。

1. 微服务拆分

1.1 康威法则

康威定律 (康威法则)：”设计系统的架构会与产生该系统的组织的通讯结构相匹配”。

简而言之，这意味着一个组织在设计软件系统时，系统的架构往往会反映出该组织内部的沟通和协作方式。例如，如果一个组织被划分为多个团队，每个团队负责一个独立的模块，那么最终的软件系统也可能是由多个独立的模块组成。

康威法则的实际意义在于提醒我们，组织结构和沟通方式会直接影响到软件系统的设计和质量。因此，在设计和开发软件时，优化组织结构和沟通方式是非常重要的。

1. 领域模型

RocketMQ 中消息的生命周期主要分为消息生产、消息存储、消息消费这三部分。

1. 探测机制

Kubernetes有以下三种探测容器的机制：

• HTTP GET探针

对容器的IP地址（你指定的端⼜和路径）执⾏ HTTP GET请求。如果探测器收到响应，并且响应状态码不代表错误（换句话说，如果HTTP响应状态码是2xx或3xx），则认为探测成功。如果服务器返回错误响应状态码或者根本没有响应，那么探测就被认为是失败的，容器将被重新启动。

• TCP套接字探针

尝试与容器指定端口建⽴TCP连接。如果连接成功建⽴，则探测成功。否则，容器重新启动。

• Exec探针

在容器内执⾏任意命令，并检查命令的退出状态码。如果状态码是0，则探测成功。所有其他状态码都被认为失败。

Deployment，⽀持声明式地更新应⽤程序。

1. Deployment是⼀种更⾼阶资源，⽤于部署应⽤程序并以声明的⽅式升级应⽤，⽽不是通过ReplicationController或ReplicaSet进⾏部署，它们都被认为是更底层的概念。
2. 当创建⼀个Deployment时，ReplicaSet资源也会随之创建 。
3. 在使⽤ Deployment 时 ， 实 际 的 pod 是 由Deployment 的Replicaset创建和管理的，⽽不是由Deployment直接创建和管理的。

1. Service 基础

⽔平伸缩意味着多个pod可能会提供相同的服务——每个pod都有⾃⼰的IP地址，客户端⽆须关⼼后端提供服务pod的数量，以及各⾃对应的IP地址。它们⽆须记录每个pod的IP地址。相反，所有的pod可以通过⼀个单⼀的IP地址进⾏访问。为了解决上述问题，Kubernetes提供了⼀种资源类型——服务（service）

1. ReplicationController(弃用)

ReplicationController旨在创建和管理⼀个pod的多个副本（replicas）。这就是ReplicationController名字的由来。

ReplicationController会持续监控正在运⾏的pod列表，并保证相应“类型”的pod的数⽬与期望相符。如正在运⾏的pod太少，它会根据 pod模板创建新的副本。如正在运⾏的pod太多，它将删除多余的副本。

1. Pod引入

1.1 pod

⼀个pod是⼀组紧密相关的容器，它们总是⼀起运⾏在同⼀个⼯作节点上，以及同⼀个Linux命名空间中。每个pod就像⼀个独⽴的逻辑机器，拥有⾃⼰的IP、主机名、进程等，运⾏⼀个独⽴的应⽤程序。

每个pod都有⾃⼰的IP，并包含⼀个或多个容器，每个容器都运⾏⼀个应⽤进程。pod分布在不同的⼯作节点上。

Kubernetes是⼀个软件系统，它允许你在其上很容易地部署和管理容器化的应⽤，Kubernetes可以被当作集群的⼀个操作系统来看待。包括服务发现、扩容、负载均衡、⾃恢复，甚⾄领导者的选举。

如果把 Kubernetes 比作云时代的操作系统，那容器就是操作系统中的进程。容器的本质是个特殊的进程，就是云时代的操作系统 Kubernetes 中的进程。

在一个真正的 os 内，进程并非“孤苦伶仃” 独自运行，而是以进程序，有原则的组织在一起。如 rsyslogd 程序负责 Linux 日志处理，rsyslogd 的主程序 main 以及它要用到的内核日志模块 imklog 同属于 2312 进程组。 而 Kubernetes 所做的，其实就是将“进程组”的概念映射到容器技术，并使其成为云原生操作系统“os”内的“一等公民”。