Dubbo的SPI原理

发表于 2019-09-07 更新于 2025-07-07 分类于 Dubbo

接口扩展策略注解 @SPI

Dubbo中的很多扩展接口，如 Protocol、Transporter、Filter 等，都是通过 JDK 的 SPI 机制实现的，也就是说这些功能都可被用户自定义的扩展所替换，接口扩展点由注解@SPI定义。
JDK 中 SPI（Service Provider Interface）的设计与策略模式如出一辙，开发者可以替换掉 Dubbo 原扩展接口的默认实现，完成自定义需求，即可以自定义实现策略。
Dubbo 在 JDK 现有 SPI 实现的基础上做了如下改进：

JDK 标准的 SPI 会一次性实例化扩展点所有实现，如果有扩展实现初始化很耗时，但如果没用上也加载，会很浪费资源。
如果扩展点加载失败，连扩展点的名称都拿不到了。比如：JDK 标准的 ScriptEngine，通过 getName();获取脚本类型的名称，但如果 RubyScriptEngine 因为所依赖的 jruby.jar 不存在，导致 RubyScriptEngine 类加载失败，这个失败原因被吃掉了，和 ruby 对应不起来，当用户执行 ruby 脚本时，会报不支持 ruby，而不是真正失败的原因。
增加了对扩展点 IoC 和 AOP 的支持，一个扩展点可以直接 setter 注入其它扩展点。

那么 Dubbo 的 SPI 机制是怎么实现的呢？以协议扩展为例，Dubbo 中协议被抽象为 Protocol 接口。

读取扩展点

ServiceConfig#protocol

1	Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension()

Dubbo 使用 ExtensionLoader 实现扩展点加载。

ExtensionLoader#getExtensionLoader()
获取 ExtensionLoader 实现，保证每种扩展点一个单例。
ExtensionLoader#getAdaptiveExtension()
根据不同的 SPI 扩展点，即不同的 interface，生成不同的 Adaptive 实例的代码。
-> getAdaptiveExtensionClass()
-> getExtensionClasses()
-> loadExtensionClasses()
加载所有的扩展点实现，直到扩展点方法执行时才决定调用是一个扩展点实现，即从众多的实现策略中决定具体使用哪一个策略。
ExtensionLoader 会依次从META-INF/dubbo/internal（Dubbo 内部实现）、META-INF/dubbo/（开发者自定义策略）、META-INF/services/这几个目录下读取扩展点实现，目录下的同名文件配置了对应扩展点的实现策略，调用 loadFile 来加载对应的扩展策略。
-> loadFile(Map<String, Class<?>> extensionClasses, String dir)

生成 Adaptive 实例

ExtensionLoader#loadFile
-> String fileName = dir + type.getName()
拼接文件路径
-> ClassLoader classLoader = findClassLoader()
拿到 ExtensionLoader 的类加载器。
-> Class<?> clazz = Class.forName(line, true, classLoader);
文件每行是一个实现类的全路径名，通过反射加载并拿到具体类型。
-> extensionClasses.put(n, clazz)
添加到 map 里返回。
ExtensionLoader#cachedClasses
-> cachedClasses.set(classes)
添加到缓存。
ExtensionLoader#createAdaptiveExtensionClass
-> ExtensionLoader#createAdaptiveExtensionClassCode
生成 Adaptive 类。
-> compiler = ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.common.compiler.Compiler.class).getAdaptiveExtension()
拿到编译接口扩展点的一个具体实现，dubbo 内部支持 jdk 和 javassist，默认是 javassist。
-> compiler.compile(code, classLoader)
编译代码，生成 Adaptive 实例类。

上面提到 Compiler 也是一个扩展点，同样也依赖这个流程来实例化，在运行时生成 Adaptive 实例的时候，需要生成 Compiler 接口的 Adaptive 实例，即运行生成 Adaptive 实例的时候需要先有一个 Compiler 接口的 Adaptive 实例，那这样岂不是陷入了死循环，这里就要提到显示指定 Adaptive 实例的情况。@Adaptive注解支持类级别和方法级别：

1
2

1、类级别：只能拥有一个，注解打在接口实现类上，显示的注册一个Adaptive实例，在编译期就存在，如`AdaptiveCompiler`，解决了上面的死循环问题，由`AdaptiveCompiler`依据dubbo配置决定使用哪个编译类；
2、方法级别：在运行期动态的生成Adaptive实例。

通过 URL 动态选择协议

ExtensionLoader#createAdaptiveExtensionClassCode
生成的 Protocol 的 Adaptive 实例类，依据 URL 中 protocol key-value 的值，选择对应的 Protocol 策略来暴露和引用服务。
扩展点方法调用会有 URL 参数（或是参数有 URL 成员），这样依赖的扩展点可以从 URL 拿到配置信息，所有的扩展点自己定好配置的 Key 后，配置信息从 URL 上从最外层传入，URL 在配置传递上即是一条总线。
以 dubbo+zookeeper 为例，暴露和引用远程服务都是注册在 zookeeper 上的，服务注册在 zookeeper 上本质其实是一个 URL，远程服务调用的过程中依据 URL 的 key-value 来动态决定执行 Protocol、Filter 等接口扩展点的执行策略。
下面是 Provider 端暴露 HelloService 服务时在 zookeeper 上注册的 URL，在 zookeeper 上的路径为/dubbo/com.dubbo.test.service.HelloService/providers，URL 表示了采用 dubbo 协议，接口为 com.dubbo.test.service.HelloService，方法为 say，要执行的 Filter 为 whiteFilter 等。

1
2

[zk： localhost：2181(CONNECTED) 1] Is /dubbo/com.dubbo.test.service.HelloService/providers
[dubbo://127.0.0.1:2O881/com.dubbo.test.service.HelloService?anyhost=true&application=dubbo-test-service&dubbo=2.4.10&group=test-prod&interface=com.dubbo.test.service.HelloService&methods=say&pid=21242&revision=l.0&service.filter=whiteFilter&side=providerxtamp=1495436105078&version=l.0]

缓存

volatile Class<~> cachedAdaptiveClass
这个是缓存 AdaptiveClass，如果一个扩展类的类上面带有 @Adaptive 注解，那么这个类就会被缓存在这个地方，每一种类型的扩展类只有一个 AdaptiveClass，如果发现有多个，则会报错。另外，当通过 getAdaptiveExtensionClass 来获取自适应扩展类时，如果当前还没有 AdaptiveClass，则会自动创建一个（动态生成 Java 代码，再编译，典型的比如 Protocol$Adaptive 就是这么生成的）
Set<~> cachedWrapperClasses
这个是缓存包装类的，Dubbo 判断一个扩展类是否是包装类比较简单，通过构造函数来判断，如果这个扩展类有一个构造函数，其中参数是当前扩展类的类型，那么就是包装类，举个例子，ProtocolFilterWrapper 就是 protocol 扩展类的包装类，因为有这个构造函数：public ProtocolFilterWrapper(Protocol protocol)
Map<~> cachedActivates
这个是缓存激活的扩展类，当然，@Activate 注解还可以规定激活的条件和时机
Holder<~> cachedClasses
这个是缓存 Adaptive 和 Wrapper 扩展类之外的普通扩展类

扩展类被加载后会根据一定的规则放入以上 4 个缓存中，比如带有 @Adaptive 注解的会被放入 cachedAdaptiveClass。

Dubbo的网络通信

发表于 2019-09-07 更新于 2025-07-07 分类于 Dubbo

Dubbo 支持多种协议，如下图所示：
Protocol扩展
在通信过程中，不同的服务等级一般对应着不同的服务质量，那么选择合适的协议便是一件非常重要的事情，需要根据应用的特征来选择。例如，使用 RMI 协议，一般会受到防火墙的限制，所以对于外部与内部进行通信的场景，就不要使用 RMI 协议，而是基于 HTTP 协议或者 Hessian 协议。

Hessian 协议

连接个数：多连接
连接方式：短连接
传输协议：HTTP
传输方式：同步传输
序列化：Hessian 二进制序列化
适用范围：传入传出参数数据包较大，提供者比消费者个数多，提供者压力较大，可传文件。
适用场景：页面传输，文件传输，Hessian 是 Caucho 开源的一个 RPC 框架，其通讯效率高于 WebService 和 Java 自带的序列化，Hessian 底层采用 Http 通讯，采用 Servlet 暴露服务，Dubbo 缺省内嵌 Jetty 作为服务器实现。

<!--定义 hessian 协议 -->
<dubbo:protocol name="hessian" port="8080" server="jetty" />
<!--设置默认协议 -->
<dubbo:service protocol="hessian" />
<!--设置 service 协议 -->
<dubbo:service protocol="hessian" />

<dependency>
    <groupId>com.caucho</groupId>
    <artifactId>hessian</artifactId>
    <version>4.0.33</version>
</dependency>

Http 协议

连接个数：多连接
连接方式：短连接
传输协议：HTTP
传输方式：同步传输
序列化：表单序列化
适用范围：传入传出参数数据包大小混合，提供者比消费者个数多，可用浏览器查看，可用表单或 URL 传入参数，暂不支持传文件。
适用场景：需同时给应用程序和浏览器 JS 使用的服务。

1 2	<!--配置协议 --> <dubbo:protocol name="http" port="8080" />

Thrift 协议

<dependency>
    <groupId>org.apache.thrift</groupId>
    <artifactId>libthrift</artifactId>
    <version>0.8.0</version>
</dependency>

<dubbo:protocol name="thrift" port="3030" />

Dubbo 使用的 Thrift 和原生的 Thrift 协议不兼容，在原生协议的基础上添加了一些额外的头信息，比如 service name，magic number 等。

Rest 协议

<!-- 用rest协议在8080端口暴露服务 -->
<dubbo:protocol name="rest" port="8080"/>

<!-- 声明需要暴露的服务接口 -->
<dubbo:service interface="com.service.OrderService" ref="orderService"/>

<!-- 和本地bean一样实现服务 -->
<bean id="orderService" class="com.service.OrderServiceImpl" />

在代码中需要通过注解指定访问路径：

public class OrderService {    
   void createOrder(Order order);
}

@Path("orders") // 访问Url的相对路径
public class OrderServiceImpl implements OrderService {

    @POST
    @Path("create") // 访问Url的相对路径
    // 将传递过来的JSON数据反序列化为Order对象
    @Consumes({MediaType.APPLICATION_JSON}) 
    public void createOrder(Order order) {
        // create the order...
    }
}

长连接 OR 短连接

Dubbo 协议缺省每服务每提供者每消费者使用单一长连接，如果数据量较大，可以使用多个连接。

<!-- 表示该服务使用 JVM 共享长连接 -->
<dubbo:service connections="0"> 
<dubbo:reference connections="0">
<!-- 表示该服务使用独立长连接 -->
<dubbo:service connections="1"> 
<dubbo:reference connections="1">

为什么要消费者比提供者个数多

因为 dubbo 协议采用单一长连接，假设网络为千兆网卡 3，根据测试经验数据每条连接最多只能压满 7MByte（不同的环境可能不一样），理论上 1 个服务提供者需要 20 个服务消费者才能压满网卡。

为什么不能传大包

因 dubbo 协议采用单一长连接，如果每次请求的数据包大小为 500KByte，假设网络为千兆网卡 3，每条连接最大 7MByte(不同的环境可能不一样，供参考)，单个服务提供者的 TPS(每秒处理事务数)最大为：128MByte / 500KByte = 262。单个消费者调用单个服务提供者的 TPS(每秒处理事务数)最大为：7MByte / 500KByte = 14。如果能接受，可以考虑使用，否则网络将成为瓶颈。

为什么采用异步单一长连接

因为服务的现状大都是服务提供者少，通常只有几台机器，而服务的消费者多，可能整个网站都在访问该服务，比如 Morgan 的提供者只有 6 台提供者，却有上百台消费者，每天有 1.5 亿次调用，如果采用常规的 hessian 服务，服务提供者很容易就被压跨，通过单一连接，保证单一消费者不会压死提供者，长连接，减少连接握手验证等，并使用异步 IO，复用线程池，防止 C10K 问题（服务器无法服务 1w 左右的并发连接）。

<!-- 配置协议端口和服务提供方最大连接数，防止服务被压垮 -->
<dubbo:protocol name="dubbo" port="20880" accepts="1000" />
<!--配置dubbo默认协议 -->
<dubbo:provider protocol="dubbo" />
<!--配置dubbo设置服务协议 -->
<dubbo:service protocol="dubbo" />

Docker 与常用中间件

发表于 2019-09-07 更新于 2025-07-07 分类于 Docker

参考

ZooKeeper

Zookeeper error: Cannot open channel to X at election address

Elasticsearch

Docker MySQL

Docker MySQL

Docker MySQL 双机热备实现

Redis

RabbitMQ

Nginx

Visualizer

docker-swarm-visualizer

ZooKeeper

使用 Docker 一步搞定 ZooKeeper 集群的搭建

Docker官方入门文档

发表于 2019-09-07 更新于 2025-07-07 分类于 Docker

相当于给官网上的get-started翻译了一下。

阅读全文 »

Docker 概述

发表于 2019-09-07 更新于 2025-07-07 分类于 Docker

Docker 是什么

Docker 是开源应用容器引擎，轻量级容器技术。
基于 Go 语言，并遵循 Apache2.0 协议开源。
Docker 可以让开发者打包他们的应用、依赖包及配置文件打包到一个轻量级、可移植的容器中，然后发布到任何流行的 Linux 系统上，也可以实现虚拟化。
容器完全使用沙箱技术，相互之间不会有任何接口。
类似于虚拟机技术（vmware、vitural），但 docker 直接运行在操作系统（Linux）上，而不是运行在虚拟机中，速度快，性能开销极低。
Docker 支持将软件编译成一个镜像，然后在镜像中对各种软件做好配置，将镜像发布出去（Docker Hub），其他使用者可以直接使用这个镜像。运行中的这个镜像称为容器，容器启动是非常快速的。类似 windows 里面的 ghost 操作系统，安装好后什么都有了。
docker容器可以理解为在沙盒中运行的进程。这个沙盒包含了该进程运行所必须的资源，包括文件系统、系统类库、shell 环境等等。但这个沙盒默认是不会运行任何程序的。你需要在沙盒中运行一个进程来启动某一个容器。这个进程是该容器的唯一进程，所以当该进程结束的时候，容器也会完全的停止。

常见应用场景

Web 应用的自动化打包和发布。
自动化测试和持续集成、发布。
在服务型环境中部署和调整数据库或其他的后台应用。
从头编译或者扩展现有的 OpenShift 或 Cloud Foundry 平台来搭建自己的 PaaS 环境。

Docker 特点

Docker 是一个基于容器的应用开发、部署和运行平台，它为开发者和系统管理员们提供了一种新式的应用部署方式，具有灵活（最复杂的应用都能容器化）、轻量（容器共享一个服务器内核）、可替换的（可以在容器运行过程中更新服务器）、可移植的（本地、云上皆可）、可伸缩的（可以轻松地进行复制）、可栈化（指的是可以将多个服务部署在一起，比如用 docker-compose）的特性。
Docker is a platform for developers and sysadmins to develop, deploy, and run applications with containers. The use of Linux containers to deploy applications is called containerization. Containers are not new, but their use for easily deploying applications is.
Containerization is increasingly popular because containers are:

Flexible: Even the most complex applications can be containerized.
Lightweight: Containers leverage and share the host kernel.
Interchangeable: You can deploy updates and upgrades on-the-fly.
Portable: You can build locally, deploy to the cloud, and run anywhere.
Scalable: You can increase and automatically distribute container replicas.
Stackable: You can stack services vertically and on-the-fly.

Docker 优势

容器技术相比虚拟机，主要优势在于性能上，其性能优势可以说达到了一个量级的差距。根据 Boden Russell 在 OpenStack 上做的一次基准测试报告，一个 KVM 实例的平均内存消耗有 292MB，而一个 docker 实例的平均内存消耗在 49MB 左右。在 CPU overhead 和启动时间方面，docker 基本都比 KVM 有一个量级的优势。
目前，一个 AWS 上的 micro 实例，每小时的按需使用成本大约在一美分多一些。如果用 docker 来提供实例，那么每小时的按需使用成本很可能会做到 0.1 美分。这一点对于云经济至关重要。正如经济学家 William Stanley Jevons 的理论所呈现的，随着商品的价格越便宜，人们使用它们的场景和频率会越来越多。

container 是一种部署单元，用户可以自由决定部署的范围（dev、test、production），即组织容器的方式，换句话说，容器可以简化工作流和软件的开发、部署生命周期；
可以从传统的虚拟机环境平滑过渡到裸机生产环境内；
保证了线上线下环境的一致性。我们在线下的开发环境使用 Docker 构建好 weaapp 的镜像后，可以直接在线上使用一个镜像，保证了线上线下环境的一致性，再也不会有在线下开发环境中运行正常，而部署到线上各种错误了。
实现了模块化，提高了复用性。
我们可以将数据库和 Tomcat 运行在不同的容器中，从某种角度来说，这也降低了模块之间的耦合性，便于拓展。比如我们要把 MySQL 替换为 oracle，只需要再构建一个 oracle 镜像并启动与 Tomcat 连接即可，非常方便。对于我们构建的镜像，在其他 app 中直接拿来用就可以了，不必重复劳动。
提高整体效率；
极大的简化了 webapp 的部署流程。在不使用 Docker 时，我们部署 app 时，要先搭建好 app 运行所需环境，这个过程做过的人都知道多么枯燥繁琐，一不小心还出错。而有了 Docker，我们只需要直接构建一个我们 webapp 的镜像然后将其运行即可，无论在多少台服务器中部署，都是如此。再比如，使用 Docker 之前要搭建一个 WordPress 对于新手来说是有些困难的，而有了 Docker，只需要从 DockerHub 上 pull 一个 WordPress 镜像并启动就可以了，非常非常方便。
实现了虚拟化，提高硬件利用率，有了 Docker，我们可以在一台服务器上运行很多 webapp，充分利用闲置资源。
这时候，服务器的操作系统就类似于货轮，而一个个 Docker 容器就相当于货轮上的一个个集装箱。现在大热的云服务市场，不少就用了 Docker。举个例子来说，现在我们有一台操作系统为 Ubuntu14.04 的服务器，我们构建不同版本的 ubuntu 镜像并启动，并且为不同的用户分配不同的容器。这样，用一台服务器可以虚拟出 n 个运行着不同操作系统的虚拟服务器，而对于用户来说，这些是透明的––用户则认为自己拥有一台完整的服务器。据我推测，阿里云的服务器就是这么干的。这充分利用了闲置的硬件资源。
Fast
- 传统方式慢，传统情况下，应用服务器扩容缩容步骤繁多流程冗长,从服务器申请、初始化、应用部署、测试、加入退出集群、服务器下线。比如，业务遇到突发的流量高峰时,无法进行快速的扩容,当准备好的时候可能流量高峰已经过去了。
- 传统不稳定，代码上线发布历经多个环境,在某个环境中测试时修复了 bug,代码等无法及时同步各环境中,提升了服务上线的风险。
- Runtime performance at near bare metal speeds (typically 97+ percent or bare metal – a few ticks shaven off for bean counters).
- Management operations (boot, stop, start, reboot, etc.) in seconds or milliseconds.
Agile
- VM-like agility – it’s still “virtualization”.
- Seamlessly move between virtual and bare metal environments permitting new development workflows which reduce costs (e.g. develop on VMs and move to bare metal in the “click of a button” for production).
Flexible
- Containerize a “system” (OS less the kernel).
- Containerize “application(s)”.
Lightweight
- Just enough Operating System (JeOS); include only what you need reducing image and container bloat.
- Minimal per container penalty which equates to greater density and hence greater returns on existing assets – imagine packing 100s or 1000s of containers on a single host node.
Inexpensive
- Open source – free – lower TCO.
- Supported with out-of-the-box modern Linux kernels.
Ecosystem
- Growing in popularity – just checkout the google trends for docker or LXC.
- Vibrant community and numerous 3rd party applications (1000s of prebuilt images on docker index and 100s of open source apps on github or other public sources).
Cloudy
- Various Cloud management frameworks provide support for creating and managing Linux Containers – including OpenStack my personal favorite.

Docker 劣势

既然容器技术有如此大的优势，为什么基于容器的云现在还没有成为主流？我认为主要还是安全性的问题。虚拟机可以利用来自硬件的信任机制来提升安全性，这些机制在 Intel Virtualization Technology Evolution 的演示中有详细的介绍。即使如此，虚拟机仍然被视为相对不安全，比如前一段时间 Xen（半虚拟化，在硬件层和 OS 层之间的虚拟层）爆出一个漏洞，导致 AWS 不得不大量升级自己的主机。

Docker Hub（镜像管理中心）不稳定
第一个就是很重要的 Docker Hub 的访问问题。我们知道国内访问一些海外的网站有时候会有稳定性的问题。Docker Hub 在我们的实践中就经常出现访问不了的问题。但这种访问的问题并不是持续的，而是时有时无。由于大量的成熟 Docker 映像（image）都需要从 Docker Hub 下载，很多脚本在执行到这一步时，结果很难预料。一种方案是修改缺省的 Docker Hub 地址，改为采用国内的一些镜像（mirror）。但是在没有官方认证的成熟稳定的镜像网站时，Docker 映像的更新不容易得到保证；另一种方案是自行搭建自己的 Docker Hub。但是一来这样就失去了强大的社区贡献的映像资源，二来要花费很多精力来保持更新和同步。容器技术带来的简单化，又因为映像管理而复杂化，得不偿失。
运维难度大
第二个就是容器技术的资源管理和运维。因为容器技术本身更适于解决大规模应用场景，所以通常都是集群基础上的部署、运维，但是目前对这一系列任务的自动化处理尚无统一的或者标准的框架。如果要让 Docker 真正在实际环境中发挥最大的效能并且易于维护，就需要有很成熟稳定的资源编排（orchestration）、资源调度（scheduling）和部署（deployment）的支持，但是这方面暂时还没有很明显的最佳解决方案，所以大多数人都在摸索和搭建自己的解决方案。我们在微软开放技术内部也是在一些开源技术的基础之上，自行开发了容器在微软公有云 Azure 上的资源管理调度和部署运维的系统，传统上的开发运维和持续集成，持续部署的技术，比如 Chef，Puppet，Jenkins 等，都可以很容易的与容器技术一起工作。

镜像和容器（Images and containers）

A container is launched by running an image. An image is an executable package that includes everything needed to run an application–the code, a runtime, libraries, environment variables, and configuration files.
A container is a runtime instance of an image–what the image becomes in memory when executed (that is, an image with state, or a user process). You can see a list of your running containers with the command, docker ps, just as you would in Linux.
一个镜像是：

一个只读模板，可以用来创建容器，一个镜像可以创建多个容器
Docker 提供了一个很简单的机制来创建和更新现有的镜像，甚至可以直接从其他人那里获取做好的镜像直接使用
可以理解为 Java 中的类
一个容器是：
容器是从镜像创建的运行实例，也就是镜像启动后的一个实例称为容器，是独立运行的一个或一组应用。
docker 利用容器来运行应用，他可以被启动、开始、停止、删除，每个容器都是相互隔离的、保证安全的平台。
可以把容器看做是一个简易版的 Linux（包括 root 用户权限、进程空间、用户空间和网络空间等）和运行在其中的应用程序。
可以理解为 Java 中通过类创建的实例。

服务端和客户端

Docker系统有两个程序：docker服务端和docker客户端。其中docker服务端是一个服务进程，管理着所有的容器。docker客户端则扮演着docker服务端的远程控制器，可以用来控制docker的服务端进程。大部分情况下，docker服务端和客户端运行在一台机器上。
Docker开放的API与Docker的守护进程进行通信。

docker 仓库（Resoisitory）

仓库是集中存放镜像文件的场所，类似 git 代码仓库等。
仓库（Respository）和仓库注册服务器（Registry）是有区别的。仓库注册服务器一般存放多个仓库，每个仓库又有多个镜像，每个镜像又有不同的标签（tag）。
仓库分为公开仓库（public）和私有仓库（private）两种形式。
最大的公开仓库是 Docker Hub，国内的公开仓库有阿里云等。
可以在本地网络创建一个私有仓库。
当创建好自己的镜像后，可以通过 push 命令把它上传到公开或私有仓库。
仓库的概念类似 Git，仓库注册服务器可以理解为 GitHub 这种托管服务。

Containers & virtual machines

传统的部署云服务的方式是通过虚拟机完成的，虚拟机会在宿主机上运行一个完整的操作系统、通过hypervisor来间接使用宿主机的硬件资源，实际上这远远超出了应用运行所必须的资源。而容器正相反，它在操作系统中作为进程运行，与所有其他容器共享同一内核、占用相同容量的内存空间，相对来说，会更加轻量。
A container runs natively on Linux and shares the kernel of the host machine with other containers. It runs a discrete process, taking no more memory than any other executable, making it lightweight.
By contrast, a virtual machine (VM) runs a full-blown “guest” operating system with virtualaccess to host resources through a hypervisor. In general, VMs provide an environment with more resources than most applications need.
下图是Docker（容器）和传统虚拟机之间运行架构的示意图。
Container stack example Virtual machine stack example
In reality virtualization and Docker can and are used together in modern dev-ops. Most VPS providers are running bare-metal full virtualization technologies like Xen and Docker usually runs on top of a virtualized Ubuntu instance.

Docker 与 LXC（Linux Container）

LXC利用Linux上相关技术实现容器，Docker则在如下的几个方面进行了改进：
移植性：通过抽象容器配置，容器可以实现一个平台移植到另一个平台；
镜像系统：基于AUFS的镜像系统为容器的分发带来了很多的便利，同时共同的镜像层只需要存储一份，实现高效率的存储；
版本管理：类似于GIT的版本管理理念，用户可以更方面的创建、管理镜像文件；
仓库系统：仓库系统大大降低了镜像的分发和管理的成本；
周边工具：各种现有的工具（配置管理、云平台）对Docker的支持，以及基于Docker的Pass、CI等系统，让Docker的应用更加方便和多样化。

Docker与Vagrant

两者的定位完全不同
Vagrant类似于Boot2Docker（一款运行Docker的最小内核），是一套虚拟机的管理环境，Vagrant可以在多种系统上和虚拟机软件中运行，可以在Windows。Mac等非Linux平台上为Docker支持，自身具有较好的包装性和移植性。
原生Docker自身只能运行在Linux平台上，但启动和运行的性能都比虚拟机要快，往往更适合快速开发和部署应用的场景。
Docker不是虚拟机，而是进程隔离，对于资源的消耗很少，单一开发环境下Vagrant是虚拟机上的封装，虚拟机本身会消耗资源。因此对于开发环境来讲，使用Docker是更好的选择。

开始使用Docker

查看操作系统版本

Docker是基于LXC（Linux Container）的，因此最好在Linux环境下使用。
Docker要求内核版本高于3.10（如果是Ubuntu则需要高于12.04的发行版）可以使用下面命令查看操作系统版本：

uname -r

安装（Ubuntu）

最好上官网下载安装最新版docker-ce，命令行下的太旧了：

1 2	sudo apt-get install docker.io docker version

或者按照官网上的步骤：

# 安装插件，可以使用HTTPS来下载仓库软件
sudo apt-get update
sudo apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    software-properties-common
# 获取GPG公钥
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
# 验证公钥是正确的
sudo apt-key fingerprint 0EBFCD88
# 设置stable仓库
sudo apt-get install software-properties-common python-software-properties # 如果缺少了add-apt-repository命令需要安装一下
sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"
# 安装
sudo apt-get update
sudo apt-get install docker-ce
# 安装某个特定版本
#apt-cache madison docker-ce # 列出可用版本
#sudo apt-get install docker-ce=<VERSION>
# 运行hello-world
docker run hello-world

安装（CentOS）

yum update
yum install docker
systemctl start docker
systemtctl enable docker # 设定为开机启动
systemtctl stop docker

安装（Mac）

下载镜像

# 搜索可用的镜像，或者上http://index.docker.io/查找
docker search tutorial
# 下载镜像，在docker的镜像索引网站上面，镜像都是按照用户名/镜像名的方式来存储的。有一组比较特殊的镜像，比如ubuntu这类基础镜像，经过官方的验证，值得信任，可以直接用镜像名来检索到。
docker pull learn/tutorial

运行容器

# docker run命令有两个参数，一个是镜像名，一个是要在镜像中运行的命令。
docker run learn/tutorial echo "hello word"
# 在容器中安装一个软件，在执行apt-get 命令的时候，要带上-y参数。如果不指定-y参数的话，apt-get命令会进入交互模式，需要用户输入命令来进行确认，但在docker环境中是无法响应这种交互的
docker run learn/tutorial apt-get install -y ping

保存对容器的修改

当你对某一个容器做了修改之后（通过在容器中运行某一个命令），可以把对容器的修改保存下来，这样下次可以从保存后的最新状态运行该容器。docker中保存状态的过程称之为committing，它保存的新旧状态之间的区别，从而产生一个新的版本。

# 获得查看正在运行中的、安装完ping命令之后容器的id
docker ps -l
docker container ls --all
# 查看更详细的信息
docker inspect 
# 将镜像保存为learn/ping，无需拷贝完整的id，通常来讲最开始的三至四个字母即可区分，比如94b82c71517f可以简写为94b
docker commit [CONTAINER ID] learn/ping
# 查看刚保存的镜像
docker images
# 在新的镜像中运行ping www.baidu.com，旧的镜像中没有安装所以不能运行、会返回奇怪的信息
docker run learn/tutorial ping www.baidu.com
docker run learn/tutorial ping www.baidu.com

发布镜像

# 列出本地的所有镜像
docker images
# 将某一个镜像发布到官网
docker push

设置用户

使用root用户运行
通常我们使用Docker的时候都是使用root用户身份运行的，官方说法如下：

1
2

The docker daemon binds to a Unix socket instead of a TCP port. By default that Unix socket is owned by the user root and other users can access it with sudo. For this reason, docker daemon always runs as the root user. 
To avoid having to use sudo when you use the docker command, create a Unix group called docker and add users to it. When the docker daemon starts, it makes the ownership of the Unix socket read/writable by the docker group.

使用普通用户运行

1
2
3

sudo groupadd docker # docker组可能已经存在了
sudo gpasswd -a ${USER} docker # 将当前用户加入docker组
sudo systemctl restart docker # 重新启动docker服务（下面是CentOS7的命令）

然后当前用户注销再重新登录就可以正常使用docker命令了：

docker ps

Docker Daemon

Docker迁移

将一台宿主机上的Docker环境迁移到另一台宿主机上是比较方便的，只需停止Docker服务，将整个docker存储文件复制到另外一台宿主机上，然后调整另外一台宿主机的配置即可。

Docker Hub

仓库（Repository）、注册服务器（Registry）、注册索引（Index）

仓库是存放一组关联镜像的集合，比如同一个应用的不同版本的镜像；
注册服务器是存放实际的镜像的地方；
注册索引则负责维护用户的账号，权限，搜索，标签等管理。注册服务器利用注册索引来实现认证等管理。

QA

Docker Hub

docker pull老超时
试试国内的加速：https://www.daocloud.io/mirror#accelerator-doc
或连接VPN后试试
pull或push时出现一直Waiting的情况
网上没有找到答案，开了VPN也没啥用，最后把环境变量改回来（eval $(docker-machine env -u)）就好了。
从非官方仓库（如：dl.dockerpool.com）下载镜像的时候，有时候会提示“Error：Invaild registry endpoint https://dl.docker.com:5000/v1/…”?
Docker 自1.3.0版本往后以来，加强了对镜像安全性的验证，需要手动添加对非官方仓库的信任。
DOCKER_OPTS=”–insecure-registry dl.dockerpool.com:5000”
重启docker服务

参考

原理

使用 Docker

发表于 2019-09-07 更新于 2025-07-07 分类于 Docker

Docker容器命令

运行中的镜像我们称之为容器，有点类似程序和进程的概念。

运行容器

1	docker run --name container-name -d image-name

运行一个容器，使用 docker run 命令即可。另，docker run -参数含义：

– name：为容器起一个名称；
-d：detached，执行完这句命令后，控制台将不会阻塞，可以继续输入命令操作，不会阻塞，也就是启动守护式容器，如果执行 docker run –name mycentos -it centos 会进入启动容器的命令控制台，也就是启动交互式容器；
-i：以交互方式运行容器，通常与 -t搭配使用；
-t：为容器重新分配一个伪输入终端，通常与 -i 搭配使用；
-P：随机端口映射；
-p：指定端口映射，后面会有端口映射详细讲解；
image-name：要运行的镜像名称；
如果以守护式方式启动 centos 容器，执行如下命令：docker run –name mycentos -d centos，会正常返回 container-id，但是通过 docker ps 查看，却发现没有在运行，通过 docker ps -a 发现，原来已经停止了，这是为什么呢？
1
2
# 接下来我们创建一个守护态的Docker容器
sudo docker run -itd ubuntu:14.04 /bin/bash

查看容器

1 2	# 查看运行中的容器列表 docker ps

输出内容中：

CONTAINER ID：启动时生成的 ID；
IMAGE：该容器使用的镜像；
COMMAND：容器启动时执行的命令；
CREATED：容器创建时间；
STATUS：当前容器状态；
PORTS：当前容器所使用的默认端口号；
NAMES：启动时给容器设置的名称。

另外，docker ps -参数，有：

-a：查看所有容器，包括已停止运行的；
-q：静默模式，只显示容器编号；
-l：显示最近创建的容器；
-n 3：显示最近创建的 num（此处为 3）个容器；
–no-trunc：不截断输出，显示完整信息。

1 2	# 可用通过如下命令查看容器中正在运行进程： docker top container-id/container-top

1 2	# 可用通过如下命令查看容器内部细节，返回为 json： docker insepct container-id

进入容器

docker attach

1	sudo docker attach 44fc0f0582d9

但在，使用该命令有一个问题。当多个窗口同时使用该命令进入该容器时，所有的窗口都会同步显示。如果有一个窗口阻塞了，那么其他窗口也无法再进行操作。
另外，官方文档中说 attach 后可以通过 CTRL-C 来 detach，但实际上经过我的测试，如果 container 当前在运行 bash，CTRL-C 自然是当前行的输入，没有退出；如果 container 当前正在前台运行进程，如输出 nginx 的 access.log日志，CTRL-C 不仅会导致退出容器，而且还 stop 了。这不是我们想要的，detach 的意思按理应该是脱离容器终端，但容器依然运行。好在 attach 是可以带上 –sig-proxy=false 来确保 CTRL-D 或 CTRL-C 不会关闭容器。

1	docker attach --sig-proxy=false 7f237caad43b

因为这些原因，所以docker attach命令不太适合于生产环境，平时自己开发应用时可以使用该命令。

ssh

在生产环境中排除了使用docker attach命令进入容器之后，相信大家第一个想到的就是ssh。在镜像（或容器）中安装SSH Server，这样就能保证多人进入容器且相互之间不受干扰了，相信大家在当前的生产环境中（没有使用Docker的情况）也是这样做的。但是使用了Docker容器之后不建议使用ssh进入到Docker容器内。
但是不建议，原因在这。

nsenter

在上面两种方式都不适合的情况下，还有一种比较方便的方法，即使用nsenter进入Docker容器。
关于什么是nsenter请参考如下文章：
https://github.com/jpetazzo/nsenter
在了解了什么是nsenter之后，系统默认将我们需要的nsenter安装到主机中
如果没有安装的话，按下面步骤安装即可（注意是主机而非容器或镜像）
具体的安装命令如下：

$ wget https://www.kernel.org/pub/linux/utils/util-linux/v2.24/util-linux-2.24.tar.gz  
$ tar -xzvf util-linux-2.24.tar.gz  
$ cd util-linux-2.24/  
$ ./configure --without-ncurses  
$ make nsenter  
$ sudo cp nsenter /usr/local/bin

安装好nsenter之后可以查看一下该命令的使用。
nsenter可以访问另一个进程的名称空间。所以为了连接到某个容器我们还需要获取该容器的第一个进程的PID。可以使用docker inspect命令来拿到该PID。
docker inspect命令使用如下：

1	$ sudo docker inspect --help

inspect命令可以分层级显示一个镜像或容器的信息。比如我们当前有一个正在运行的容器

可以使用docker inspect来查看该容器的详细信息。

1	$ sudo docker inspect 44fc0f0582d9

由其该信息非常多，此处只截取了其中一部分进行展示。如果要显示该容器第一个进行的PID可以使用如下方式

1	$ sudo docker inspect -f {{.State.Pid}} 44fc0f0582d9

在拿到该进程PID之后我们就可以使用nsenter命令访问该容器了。

1 2	$ sudo nsenter --target 3326 --mount --uts --ipc --net --pid $ sudo nsenter --target 3326 --mount --uts --ipc --net --pid

其中的3326即刚才拿到的进程的PID
当然，如果你认为每次都输入那么多参数太麻烦的话，网上也有许多做好的脚本供大家使用。
地址如下：
http://yeasy.gitbooks.io/docker_practice/content/container/enter.html
http://www.tuicool.com/articles/eYnUBrR

exec

除了上面几种做法之外，docker在1.3.X版本之后还提供了一个新的命令exec用于进入容器，这种方式相对更简单一些。

1	sudo docker exec -it 775c7c9ee1e1 /bin/bash

exec和attach的区别：

attach：直接进入容器启动命令的终端，不会启动新的进程；
exec：在容器中打开新的终端，并且可以启动新的进程，可在宿主机中直接执行操作容器的命令，比如docker exec -it 7f237caad43b ls /tmp列出容器 /tmp 目录下的文件

容器和宿主机互相拷贝文件

宿主机拷贝文件到容器：

docker cp 文件 container-id:目标文件/文件夹
eg. 
docker cp /tmp/suzhuji.txt 7f237caad43b:/tmp
将宿主机tem文件夹下suzhujia.txt文件拷贝到容器7f237caad43b中tmp目录中

从容器拷贝文件到宿主机：

docker cp container-id:目标文件/文件夹 宿主机目标文件/文件夹
eg.
docker cp 7f237caad43b:/tmp/yum.log /tmp
将容器7f237caad43b中tmp目录下yum.log拷贝到宿主机/tmp目录下

停止、启动、重启容器

# 通过以下命令来停止运行中的容器，停止后需要使用docker start命令来重新启动
docker stop container-name/container-id
# 强制停止容器（类似强制关机）：
docker kill container-name/container-id
# 停止所有正在运行的容器
docker kill $(docker ps -q)
# 通过以下命令启动容器：
docker start container-name/container-id
# 通过以下命令启动容器：
docker restart container-name/container-id

容器退出（或者显示调用docker stop）后会进入终止（exited）状态，此时可以通过 docker ps -a 查看，其中数据不会丢失，还可以通过docker start 来启动，只有删除容器才会清除数据。

删除容器

# 删除单个容器：
docker rm container-id
# 删除多个容器：
docker rm container-id container-id 
# 删除所有容器：
docker rm $(docker ps -a -q )

另，docker rm -参数含义：

-f：强制删除，如果在运行中，先停止，再删除

查看容器日志

1 2	# 查看当前容器日志，可通过如下命令： docker logs container-id/container-name

另，docker logs -参数含义：

-t：加入时间戳；
-f：跟随最新的日志打印；
–tail：显示最后多少条。

端口映射

容器中可以运行一些网络应用，要让外部也可以访问这些应用，可以通过 -P（大写）或 -p （小写）参数来指定端口映射。启动容器的时候如果不指定对应参数，在容器外部是无法通过网络来访问容器内的网络应用和服务的。
Docker 的端口映射通过 -p 或 -P 参数实现，-p 和 -P 区别为：

-P : 随机映射一个49000~49900的端口到内部容器开放的网络端口
-p : 可以指定要映射的IP和端口，但是在一个指定端口上只可以绑定一个容器

1
2
3

# 把主机端口 8888 请求映射到 Docker 容器内部端口 8080
docker run --name tomcat1 -d tomcat
docker run --name tomcat2 -d -p 8888:8080 tomcat

使用docker ps查看端口映射情况，访问localhost:8080和localhost:8888，发现前者无法访问，后者可以。

端口映射格式

ip:hostport:containerport #指定ip、指定主机port、指定容器port

1 2	docker run -d -p 127.0.0.1:5000:5000 training/webapp python app.py 指定映射使用一个特定地址，比如 localhost地址 127.0.0.1

ip::containerport #指定ip、未指定主机port、指定容器port

docker run -d -p 127.0.0.1::5000 training/webapp python app.py
绑定 localhost 的任意端口到容器的 5000 端口，本地主机会自动分配一个端口
还可以使用 udp 标记来指定 udp 端口
docker run -d -p 127.0.0.1:5000:5000/udp training/webapp python app.py

hostport:container #未指定ip port、指定主机port、指定容器port

1 2	docker run -d -p 5000:5000 training/webapp python app.py 将本地的 5000 端口映射到容器的 5000 端口，默认会绑定本地所有接口上的所有地址

查看端口映射

1 2	# 可以通过如下命令查看容器映射了哪些端口及协议： docker port container-id

如果返回空表示没有进行端口映射。

QA

docker ps（等其他指令）没有响应

我的情况比较简单，是因为云主机内存不够了，所以没有响应。但是如果是某个容器出问题了就需要另外想办法了：docker之 docker ps无响应。

连接进入docker

https://stackoverflow.com/questions/30172605/how-to-get-into-a-docker-container

查看Docker日志

https://docs.docker.com/config/daemon/#read-the-logs

https://takacsmark.com/docker-logs/

docker logs <Container-ID> 、docker service logs <Service-ID> 命令能查看某一容器或服务的日志，但是怎么查看Docker守护进程的执行日志？

docker logs 和 docker service logs 命令会显示类似于终端中交互式运行命令的输出。UNIX 和 Linux 命令在运行时通常会打开三个 I/O 流，分别称为 STDIN，STDOUT 和 STDERR。STDIN 是命令的输入流，可能包括来自键盘的输入或来自另一个命令的输入。STDOUT 通常是命令的正常输出，而 STDERR 通常用于输出错误消息。默认情况下，docker logs 显示命令的 STDOUT 和 STDERR。

https://stackoverflow.com/questions/30969435/where-is-the-docker-daemon-log

比如Ubuntu：sudo journalctl -fu docker.service

查看已经退出的容器的日志

运行容器直接退出

使用docker-logs命令（或者使用docker ps -a查看正在运行中的容器）发现容器启动后直接退出，原因是Docker容器后台运行,就必须有一个前台进程，进程结束，容器就会退出，如果不是那些一直挂起的命令（eg. top, tail等），就会自动退出。

正常情况下，启动服务只需启动相应的service即可，例如：service nginx start && service php5-fpm start，但是这样做的话nginx和fpm均以后台进程模式运行，就会导致docker前台没有正在运行的应用，因此容器会立即自杀，因为已经没有事情能做了。

* 将要运行的程序以前台进程的形式运行，如果容器需要同时启动多个进程，那么只需要将其中的一个挂起到前台即可，比如对上面所说的 web 容器，只需要将启动指令修改为`service php5-fpm start && nginx -g "daemon off;"`

* 对于不知道怎么在前台运行的程序，只需要在启动的命令后面添加类似tail、top这种可以前台运行的程序，以上面所说的web容器为例，可以写成`service nginx start && service php5-fpm start && tail -f /var/log/nginx/error.log`，又如，在启动centos/ubuntu容器的时候，可以做一个死循环，持续输出任意内容，这样容器就不会认为没事可做而自杀了：`docker run -d centos /bin/sh -c "while true; do echo hello world; sleep 1; done"`。

* 可以加上-it选项，-i 开启了input(输入)功能 -t开启了一个连接容器里边的terminal(终端)（是不是相当于在容器内开启了一个bash进程？），如果希望在后台运行，可以再加上-d选项。

一般来说我们不推荐在同一个容器内运行多个应用程序，这会影响容器的效率，因此最后一种方法是最好的。

日志中出现 not support swap limit capabilities

https://segmentfault.com/q/1010000002888521

开启服务失败（elasticsearch）

在查看日志（journalctl -fu docker.service）的时候发现是内存不够用，在docker-compose.yml中去掉resources配置项就可以了。

如果没有设置限制，也有可能是物理机本身内存不够了，实在不行可以创建swap来凑空间。

使用远程主机作为docker-machine时“connection refused”

调用docker-machine env <docker-machine名>出现连接失败的情况

查看了一些资料但并没有什么卵用，/etc/default/docker这个文件根本没有被读进去。

据说是因为docker的daemon默认监听fd，而远程连接时用的是tcp。

根据这里的说明修改配置文件，但是发现无法重启docker服务，查看daemon日志发现-H的配置项重复了，而/etc/systemd/system/下并没有发现配置文件，在这里了解到原来配置文件还有一个位置/lib/systemd/system/，将相关内容（”-H fd://“）去掉就行了。

但是这样配置完毕后仍然不能在ECS上创建Docker Machine，最后采用了generic驱动成功了，具体配置见我的另一篇[App & Cloud]。

就优先级来说，/etc/docker/daemon.json > /etc/systemd/system/ > /lib/systemd/system/，优先级高的会覆盖低的。

对阿里云美西节点 docker-machine create 时 tls: DialWithDialer timed out

刚开始我也试着regenerate-certs了，但没什么卵用。

在stackoverflow上查不到相关的讨论。

官网相关页面上也没有。

github上对这个问题的讨论，也有了解决，在代码里把超时时间改大了，但还是写死的，我在连接美国服务器时仍然超时。

有的人提议提议将超时时间作为一个命令行参数提供出来，但是下面一个傻逼一直坚持说“suggest retrying”。

最后还是放弃了在这个节点上部署docker。

PS：在这里看到开发者的想法：用户是愚蠢的，不能把危险的选项公布出来，所以TLS任何方法不能关闭！WTF！！！随便搜索了一遍releases列表，没有发现对TLS的更改，所以我彻底放弃了。

如何让Docker启动时执行自定义命令/脚本？

如果官方提供的Dockerfile已经内置了这个功能是最好的（比如MySQL官方Dockerfile），如果没有的话，就需要自定义Dockerfile了（How to run bash command after startup?），ENTRYPOINT和CMD命令都可以用于执行命令，CMD会被接到ENTRYPOINT后面，主要用于提供一些可变的参数，docker run后面的参数其实就是CMD。

在docker-compose.yml文件中不适合自定义执行命令，command命令可以定义启动时命令，但是只能定义一条，我尝试command: a.sh && b.sh，结果也只是执行了前面的指令，所以就不要白费力气了。

docker 中怎么修改应用的配置？
- 官方镜像已有提供该功能
- 使用volumes将宿主机文件夹挂载到容器内
- 自定义镜像
怎么查看容器的启动命令
- 在宿主机上docker inspect
- 在容器内部ps -fe，其中1号进程就是启动命令（有可能出现ps命令找不到的情况）
- 查看这个镜像的Dockerfile，其中的ENTRYPOINT和CMD指定了容器的运行时执行命令
如何临时退出一个正在交互的容器的终端，而不终止它？

按Ctrl+p，后按Ctrl+q，如果按Ctrl+c会使容器内的应用进程终止，进而会使容器终止。

使用docker port 命令映射容器的端口时，系统报错Error: No public port ‘80’ published for …，是什么意思？

创建镜像时Dockerfile要指定正确的EXPOSE的端口，容器启动时指定PublishAllport=true

可以在一个容器中同时运行多个应用进程吗？
一般不推荐在同一个容器内运行多个应用进程，如果有类似需求，可以通过额外的进程管理机制，比如supervisord来管理所运行的进程
如何控制容器占用系统资源（CPU，内存）的份额？
在使用docker create命令创建容器或使用docker run 创建并运行容器的时候，可以使用-c|–cpu-shares[=0]参数来调整同期使用CPU的权重，使用-m|–memory参数来调整容器使用内存的大小。

参考

容器

容器编排

Swarm基本使用

Swarm运维

Swarm原理

持续部署

Docker持续部署图文详解

服务发现

docker swarm获取客户端IP

OpenStack（开源云计算平台）

客户端

自制LinuxContainer

发表于 2019-09-07 更新于 2025-07-07 分类于 Docker

预备知识

进程和clone系统调用

进程（Process）是运行中的程序实例，又可以称为任务（Task），进程在Linux内核中使用一个PCB来表示，主要包含运行状态、信号、进程号、父进程号、运行时间累计值、正在使用的文件（文件描述符表）、本任务的局部描述符及任务状态段信息。
不同于fork，clone系统调用允许子进程共享部分父进程的上下文，如内存空间、文件描述符表、信号等。

/* Prototype for the glibc wrapper function */
#define _GNU_SOURCE
#include <sched.h>
int clone(int (*fn)(void *), void *child_stack,
          int flags, void *arg, ...
          /* pid_t *ptid, void *newtls, pid_t *ctid */ );
/* For the prototype of the raw system call, see NOTES */

clone常用于实现多线程，因为子进程和父进程可以共享内存。
不同于fork创建的子进程会从调用的位置开始执行，clone创建的子进程会执行实参传入的fn(arg)，并将实参中的arg传入。
当fn(arg)返回后子进程页会终止，返回值即为子进程的exit code，当然子进程在遇到显式的exit调用或终止信号也会立刻退出。
子进程与父进程共享内存，它们不能（也不应该）使用同一个栈，因此必须使用child_stack参数指定子进程使用的栈所在的内存空间。栈是从上向下生长的，因此最好指定最顶层的一个地址。
flags的低位包含子进程退出了发送给父进程的信号，If this signal is specified as anything other than SIGCHLD, then the parent process must specify the __WALL or __WCLONE options when waiting for the child with wait(2). If no signal is specified, then the parent process is not signaled when the child terminates.
flags 还可以指定子进程和父进程间可以共享的内容，具体内容见man clone。

虚拟网络设备和veth pair

Linux container 中用到一个叫做veth的东西，这是一种新的设备，专门为 container 所建。veth 从名字上来看是 Virtual ETHernet 的缩写，它的作用很简单，就是要把从一个 network namespace 发出的数据包转发到另一个 namespace。veth 设备是成对的，一个是 container 之中，另一个在 container 之外，即在真实机器上能看到的。

veth设备实现原理

VETH设备总是成对出现，送到一端请求发送的数据总是从另一端以请求接受的形式出现。创建并配置正确后，向其一端输入数据，VETH会改变数据的方向并将其送入内核网络子系统，完成数据的注入，而在另一端则能读到此数据。（Namespace，其中往veth设备上任意一端上RX到的数据，都会在另一端上以TX的方式发送出去）veth工作在L2数据链路层，veth-pair设备在转发数据包过程中并不串改数据包内容。
这里写图片描述
显然，仅有veth-pair设备，容器是无法访问网络的。因为容器发出的数据包，实质上直接进入了veth1设备的协议栈里。如果容器需要访问网络，需要使用bridge等技术，将veth1接收到的数据包通过某种方式转发出去。

VETH: Typically used when you are trying to connect two entities which would want to “get hold of” (for lack of better phrase) an interface to forward/receive frames. These entities could be containers/bridges/ovs-switch etc. Say you want to connect a docker/lxc container to OVS. You can create a veth pair and push the first interface to the docker/lxc (say, as a phys interface) and push the other interface to OVS. You cannot do this with TAP.

veth设备特点

veth和其它的网络设备都一样，一端连接的是内核协议栈
veth设备是成对出现的，另一端两个设备彼此相连
一个设备收到协议栈的数据发送请求后，会将数据发送到另一个设备上去

常用命令

1 2	# 创建veth ip link add name veth0 type veth0 peer name veth1

其他细节见Linux篇《虚拟化-网络设备》

资源隔离、namespace和cgroup

namespace的主要作用是对两个系统内的标识符的命名进行隔离，namespace有以下几种。
Linux-namespace种类
这几个flag 可以在调用clone进行进程创建的时候作为参数传入，从而实现namespace的隔离，从这个角度来说，container主要是进程角度的隔离，而不是传统的虚拟机（一些虚拟机实现同样是基于对操作系统层的虚拟化，所以应该和container是类似的，比如普通vmware），因为container底层用的是同一个内核来调度。

cgroup 是linux 内核的另外一个控制和隔离进程的特性，他分为cpu ，memory，net，io等几个子系统，从而实现对进程cpu，内存，磁盘，网络等资源使用的控制。

虚拟文件系统（VFS）和chroot

自制容器

docker 只是一个工具，container 技术的核心还是linux 内核的cgroup + chroot + namespace 技术。

制作image

制作自己容器，需要一个image ，可以从网上下一个，也可以自己制作，制作很简单，新装一个操作系统，安装一些需要用到的软件包，然后用tar 制作 / 目录下的压缩包，去掉一些虚拟文件系统的文件，本文用的是自己制作的centos 6.5 的image。

容器实现过程

容器实现过程可以归纳为

用clone系统调用创建子进程，传入namespace的那几个参数，实现namespace的隔离；
父进程中创建veth pair ，一个veth在自己的namespace，将另一个设置为子进程的namespace，实现container和宿主机的网络通信；
父进程创建cgroup memory和cpuset子系统，将子进程attach到cgroup子系统上，实现container 的资源限制和隔离；
子进程在自己的namespace里，设置主机名，mount proc虚拟文件系统，设置veth ip，chroot到centos 6镜像的位置，最终将进程镜像替换成/bin/bash；
父进程调用waitpid 等待子进程退出。

容器实现

见下面的《源码》部分

实验

在解压好镜像后，该镜像根目录下可能还没有必须的命令文件及其依赖的动态链接库，主要是由于用chroot改变根目录后，原来路径下的一些文件在当前镜像内都找不到了，一般安装完操作系统后这些文件应该都安装好了，如果需要可以通过手动移动来解决。

1 2	ldd /bin/bash cp --parents /lib/x86_64-linux-gnu/libtinfo.so.5 ./

编译执行容器代码。

1 2	gcc lxc_demo.c -o lxc_demo -lcgroup sudo ./lxc_demo

接下来分别在宿主机和容器内执行命令，可以得出一些结论：

容器和宿主机镜像可能不同，但是内核相同；

# （宿主机内）
hgc@hgc-X555LD:~$ uname -r
4.13.0-45-generic

# （容器内）
bash-4.4# uname -r
4.13.0-45-generic

根目录下的文件不同；
1
ls /
hostname，宿主机内为用户设定的主机名，容器内为mydocker，说明UTS namespace隔离成功；
1
hostname

网络方面有回环网络卡lo和veth1，veth1 169.254.1.2 能ping 通veth0的地址（宿主机上的veth）169.254.2.1，如果在外面加iptables 做nat 转换的话，container里面还可以和外面通信。我们看不到外面宿主机的eth0 和 eth1，说明container 的network namespace 隔离成功。

# （宿主机内）
$ ip addr
......
19: veth0@if18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 46:c0:eb:a8:34:8d brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 169.254.1.1/30 scope global veth0
       valid_lft forever preferred_lft forever
    inet6 fe80::44c0:ebff:fea8:348d/64 scope link 
       valid_lft forever preferred_lft forever

# （容器内）网络方面有回环网络卡lo和veth1
bash-4.4# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
18: veth1@if19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ce:04:78:b6:5a:2d brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 169.254.1.2/30 scope global veth1
       valid_lft forever preferred_lft forever
    inet6 fe80::cc04:78ff:feb6:5a2d/64 scope link 
       valid_lft forever preferred_lft forever
# 尝试ping宿主机上的veth0设备
bash-4.4# ping 169.254.1.1
PING 169.254.1.1 (169.254.1.1) 56(84) bytes of data.
64 bytes from 169.254.1.1: icmp_seq=1 ttl=64 time=0.101 ms
......

目前container 里面只有/bin/bash , 且进程号为 1，不是我们常见的init进程，或者systemd 。因为/bin/bash 为该namespace 下的第一个进程，说明我们的pid namespace隔离成功。
1
2
3
4
5
# 查看进程
bash-4.4# ps -aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
0 1 0.0 0.0 9924 3264 ? S 01:02 0:00 /bin/bash
0 8 0.0 0.0 30524 2820 ? R+ 01:02 0:00 ps -aux

mount 显示挂载的文件系统，和宿主机的不一样，说明mount namespace隔离成功。

# 查看挂载情况（这里有点问题，原文里还有rootfs、sysfs等）
bash-4.4# mount
proc on /proc type proc (rw,relatime)
......

就cgroup的隔离情况来说，在cgroup文件系统内，memory的限制是我们设置的512M，cpu使用的是0-1号。

hgc@hgc-X555LD:~/tools/virtualmachines/ubuntu-16.04$ cd /sys/fs/cgroup/memory/mydocker_1530580167/
hgc@hgc-X555LD:/sys/fs/cgroup/memory/mydocker_1530580167$ cat memory.limit_in_bytes 
536870912
hgc@hgc-X555LD:/sys/fs/cgroup/memory/mydocker_1530580167$ cd /sys/fs/cgroup/cpuset/mydocker_1530580167/
hgc@hgc-X555LD:/sys/fs/cgroup/cpuset/mydocker_1530580167$ cat cpuset.cpus 
0-1
hgc@hgc-X555LD:/sys/fs/cgroup/cpuset/mydocker_1530580167$ cat cpuset.mems 
0
hgc@hgc-X555LD:/sys/fs/cgroup/cpuset/mydocker_1530580167$ top

从下面执行情况可以看出，只有0号和1号cpu idle为0 ，其他的都接近100%，说明cgroup隔离效果是很好的。

# （宿主机内）执行top命令并点击1查看CPU负载情况
hgc@hgc-X555LD:/sys/fs/cgroup/cpuset/mydocker_1530580167$ top
top - 10:02:22 up 13:19, 1 user, load average: 0.74, 0.68, 0.72
Tasks: 348 total, 1 running, 346 sleeping, 0 stopped, 1 zombi
%Cpu0 : 5.3 us, 2.3 sy, 0.0 ni, 91.7 id, 0.0 wa, 0.0 hi, 0.7
%Cpu1 : 8.3 us, 12.6 sy, 0.0 ni, 78.8 id, 0.0 wa, 0.0 hi, 0.3
%Cpu2 : 4.0 us, 2.0 sy, 0.0 ni, 93.9 id, 0.0 wa, 0.0 hi, 0.0
%Cpu3 : 3.0 us, 2.4 sy, 0.0 ni, 94.6 id, 0.0 wa, 0.0 hi, 0.0
%Cpu4 : 7.1 us, 5.7 sy, 0.0 ni, 87.2 id, 0.0 wa, 0.0 hi, 0.0
%Cpu5 : 4.4 us, 1.4 sy, 0.0 ni, 93.9 id, 0.3 wa, 0.0 hi, 0.0
%Cpu6 : 3.3 us, 2.7 sy, 0.0 ni, 93.7 id, 0.0 wa, 0.0 hi, 0.3
%Cpu7 : 3.7 us, 1.3 sy, 0.0 ni, 94.6 id, 0.0 wa, 0.0 hi, 0.3
......

# （容器内）执行多个死循环任务，强行使CPU忙碌
bash-4.4# while true; do echo > /dev/null; done &                   
[1] 10
bash-4.4# while true; do echo > /dev/null; done &
[2] 11
bash-4.4# while true; do echo > /dev/null; done &
[3] 12
bash-4.4# while true; do echo > /dev/null; done &
[4] 13
bash-4.4# while true; do echo > /dev/null; done &
[5] 14
bash-4.4# while true; do echo > /dev/null; done &
[6] 15
bash-4.4# while true; do echo > /dev/null; done &
[7] 16

# （宿主机内）同样是执行top命令并点击1，可以看到头两个CPU的负载情况有了明显变化
hgc@hgc-X555LD:/sys/fs/cgroup/cpuset/mydocker_1530580167$ top
top - 10:05:05 up 13:22, 1 user, load average: 4.25, 1.68, 1.06
Tasks: 355 total, 1 running, 353 sleeping, 0 stopped, 1 zombi
%Cpu0 : 9.9 us, 34.8 sy, 0.0 ni, 53.2 id, 2.0 wa, 0.0 hi, 0.0
%Cpu1 : 14.4 us, 43.6 sy, 0.0 ni, 40.2 id, 1.7 wa, 0.0 hi, 0.0
%Cpu2 : 2.2 us, 0.6 sy, 0.0 ni, 92.0 id, 0.0 wa, 0.0 hi, 5.1
%Cpu3 : 2.6 us, 1.3 sy, 0.0 ni, 95.0 id, 0.0 wa, 0.0 hi, 1.0
%Cpu4 : 6.4 us, 10.0 sy, 0.0 ni, 83.6 id, 0.0 wa, 0.0 hi, 0.0
%Cpu5 : 2.3 us, 1.2 sy, 0.0 ni, 95.3 id, 0.0 wa, 0.0 hi, 1.2
%Cpu6 : 1.7 us, 0.7 sy, 0.0 ni, 97.6 id, 0.0 wa, 0.0 hi, 0.0
%Cpu7 : 2.0 us, 2.7 sy, 0.0 ni, 95.3 id, 0.0 wa, 0.0 hi, 0.0
......

源码

#define _GNU_SOURCE

#include <sys/types.h>
#include <sys/wait.h>
#include <stdio.h>
#include <sched.h>
#include <signal.h>
#include <unistd.h>
#include <errno.h>
#include <stdlib.h>
#include <sys/mount.h>
// 必须先安装：sudo apt-get install libcgroup-dev
#include <libcgroup.h>
#include <time.h>
#include <signal.h>
#include <string.h>
#include <fcntl.h>

#define STACK_SIZE (1024 * 1024)
#define MEMORY_LIMIT (512*1024*1024)

//const char *rootfs = "/data1/centos6/rootfs/"; //centos6 镜像位置
//const char *rootfs = "/home/hgc/tools/virtualmachines/ubuntu-16.04/"; // 镜像位置
//const char *hostname = "mydocker"; //container 主机名
static char child_stack[STACK_SIZE];
//char *const child_args[] = {
//    "/bin/bash",
//    NULL
//};
int pipe_fd[2]; //父子进程同步

int child_main(void *args) {
  char c;
  // TODO:子进程里无法使用全局变量rootfs和hostname
  // 镜像位置
  const char *rootfs = "/home/hgc/tools/virtualmachines/ubuntu-16.04/";
  // container 主机名
  const char *hostname = "mydocker";
  // 在子进程（容器）内执行的任务
  // TODO:因为chroot改变了根目录的位置，所以在保证目标命令存在容器内的基础上（这里是/bin/bash），
  // TODO:必须保证该命令依赖的资源同样存在于容器内（动态链接库，使用ldd查看）
  char *const child_args[] = {
      "/bin/bash",
      0
  };

  printf("In child process(container)\n");
  chroot(rootfs); //用chroot 切换根目录
  if (errno != 0) {
    perror("chroot()");
    exit(1);
  }
  // TODO:这里不能使用sizeof
  //clone 调用中的 CLONE_NEWUTS起隔离主机名和域名的作用
  sethostname(hostname, strlen(hostname));
  if (errno != 0) {
    perror("sethostname()!");
    exit(1);
  }
  //挂载proc子系统，CLONE_NEWNS 起隔离文件系统作用
  // 需要在rootfs目录下创建proc目录
  mount("proc", "/proc", "proc", 0, NULL);
  if (errno != 0) {
    perror("Mount(proc)");
    exit(1);
  }
  //切换的根目录
  chdir("/");
  close(pipe_fd[1]);
  read(pipe_fd[0], &c, 1);
  //设置veth1 网络
  system("ip link set lo up");
  system("ip link set veth1 up");
  system("ip addr add 169.254.1.2/30 dev veth1");
  //将子进程的镜像替换成bash
  printf("[%s]\n", child_args[0]);
  if (execv(child_args[0], child_args) == -1) {
    perror("execv(path, argv)");
  }
  return 1;
}

struct cgroup *cgroup_control(pid_t pid) {
  struct cgroup *cgroup = NULL;
  int ret;
  ret = cgroup_init();
  char *cgname = malloc(19 * sizeof(char));
  if (ret) {
    printf("error occurs while init cgroup.\n");
    return NULL;
  }
  time_t now_time = time(NULL);
  sprintf(cgname, "mydocker_%d", (int) now_time);
  printf("%s\n", cgname);
  cgroup = cgroup_new_cgroup(cgname);
  if (!cgroup) {
    ret = ECGFAIL;
    printf("Error new cgroup%s\n", cgroup_strerror(ret));
    goto out;
  }
  //添加cgroup memory 和 cpuset子系统
  struct cgroup_controller *cgc = cgroup_add_controller(cgroup, "memory");
  struct cgroup_controller *cgc_cpuset = cgroup_add_controller(cgroup, "cpuset");
  if (!cgc || !cgc_cpuset) {
    ret = ECGINVAL;
    printf("Error add controller %s\n", cgroup_strerror(ret));
    goto out;
  }
  // 内存限制  512M
  if (cgroup_add_value_uint64(cgc, "memory.limit_in_bytes", MEMORY_LIMIT)) {
    printf("Error limit memory.\n");
    goto out;
  }
  //限制只能使用0和1号cpu
  if (cgroup_add_value_string(cgc_cpuset, "cpuset.cpus", "0-1")) {
    printf("Error limit cpuset cpus.\n");
    goto out;
  }
  //限制只能使用0和1块内存
  // TODO:使用0-1作为参数会报错“Invalid argument”
  if (cgroup_add_value_string(cgc_cpuset, "cpuset.mems", "0")) {
    printf("Error limit cpuset mems.\n");
    goto out;
  }
  ret = cgroup_create_cgroup(cgroup, 0);
  if (ret) {
    printf("Error create cgroup%s\n", cgroup_strerror(ret));
    goto out;
  }
  ret = cgroup_attach_task_pid(cgroup, pid);
  if (ret) {
    printf("Error attach_task_pid %s\n", cgroup_strerror(ret));
    goto out;
  }
  return cgroup;
  out:
  if (cgroup) {
    cgroup_delete_cgroup(cgroup, 0);
    cgroup_free(&cgroup);
  }
  return NULL;
}

int main() {
  char *cmd;
  printf("main process: \n");
  pipe(pipe_fd);
  if (errno != 0) {
    perror("pipe()");
    exit(1);
  }
  // 调用clone创建子进程，传入namespace的几个flag参数，实现namespace的隔离
  // 子进程执行child_main函数，其堆栈空间使用child_stack参数指定
  // clone与线程的实现息息相关：http://www.xuebuyuan.com/1422353.html
  int child_pid = clone(child_main, child_stack + STACK_SIZE, \
            CLONE_NEWNET | CLONE_NEWNS | CLONE_NEWPID | CLONE_NEWIPC | CLONE_NEWUTS | SIGCHLD, NULL);
  struct cgroup *cg = cgroup_control(child_pid);
  // 添加veth pair，设置veth1 在子进程的的namespace，veth0 在父进程的namespace，为了实现container和宿主机之间的网络通信
  // linl3 实现起来太繁琐，借用命令行工具ip 实现
  system("ip link add veth0 type veth peer name veth1");
  asprintf(&cmd, "ip link set veth1 netns %d", child_pid); // asprintf根据字符串长度申请足够的内存空间，但在之后必须手动释放
  system(cmd);
  system("ip link set veth0 up");
  system("ip addr add 169.254.1.1/30 dev veth0");
  free(cmd);
  //等执行以上命令，通知子进程，子进程设置自己的网络
  close(pipe_fd[1]);
  waitpid(child_pid, NULL, 0);
  if (cg) {
    cgroup_delete_cgroup(cg, 0); //删除cgroup 子系统
  }
  printf("child process exited.\n");
  return 0;
}

参考

LXC

虚拟网络设备

Linux-虚拟网络设备-veth pair

clone

linux的Clone()函数详解

Linux namespace

分布式 Session 和 OAuth

发表于 2019-09-02 更新于 2025-07-07 分类于分布式系统

不论一家企业做什么领域业务，登录基本都是绕不过去的功能——任何操作都必须在已经登录的前提下才能执行，我这里主要聚焦登录中分布式 Session 的设计，然后连带提一下其他方方面面。

阅读全文 »

Java-线程池

发表于 2019-09-01 更新于 2025-07-07 分类于 Java

执行异步任务最简单的方式就是通过线程来执行，因为线程本质上是操作系统的资源，应用如果不加限制地占用——最严重的情况下——将会导致系统的宕机。因此，本地线程任务主要依赖线程池来执行，线程池可以看做一种线程资源池，提供了对线程资源的调度功能。当然，提到线程就不得不提并发安全，这又是一个非常复杂的主题，水平有限，无法一一道清。

阅读全文 »

并发的定义

发表于 2019-09-01 更新于 2025-07-07 分类于 Java

异步编程富有魅力，但是错误的使用不仅不会带来益处，还会使得系统变得难以维护、Bug 遍地，接下来我希望总结一下遇到的异步任务场景，减少以后遇到类似问题阻塞在设计上的时间。

曾经经历过因三方（传统行业）接口效率过低而导致服务不可用的情况，交流发现对方根本没有考虑在系统里加入缓存、消息队列等中间件，原因竟然是希望保证高一致性。
实际上大部分场景中，查询操作并没有保证一致性的意义，而写操作就算不能马上被看到结果也不会对体验造成太大的影响——只要最终能成功即可，这是符合BASE设计原则的。这个问题后续经排查发现原因是对方因为系统设计有问题、导致频繁大规模的接口超时，重启了后问题缓解，对方就不再追究了，非常无奈。没有不能解决的技术难题，只是有时候沟通、惰性等会阻碍问题的定位。
并发的话题真是非常的多，从最底层的硬件到高级语言 Java 中的 JUC，从最繁琐的业务系统（现在一般是微服务架构）到比较新的人工智能（如分布式机器学习），几乎无所不包，一直想爬出坑来，但是总觉得差点意思，在此我也仅仅能根据一些现成的资料总结出一些结论。

[x] 异步和非阻塞
[x] 并发和并行
[x] 并发模式 STM 介绍
[x] 并发模式 Actor 介绍

阅读全文 »