本文是一系列对Docker与Kubernetes的学习总结。源材料来源参见文中的链接和最后的参考资料。

容器的原理

虽然有些人会把容器和虚拟机类比，称之为“轻量级的虚拟机”。刚开始接触Docker的时候大多看过下面这张图：

忘记这张图吧。从上一节我们讨论的“容器的意义”就可以看到，容器和虚拟机关注的不是一个层面。

但虚拟机和容器也有共通之处：本质都是欺骗。虚拟机的原理是欺骗CPU/物理内存/物理IO，让硬件感觉自己还是在接收宿主机而非虚拟机的指令。而Docker的原理是欺骗一组进程，让这些进程以为自己活在另一个的操作系统里。
用专业一点的术语，就是：容器的核心功能，就是通过约束进程和修改进程的动态表现，为进程创造出一组“边界”。

以电影作为比方，虚拟机就像《火星救援》里在火星上种土豆的宇航员，在火星上模拟地球的环境，连空气和水都需要自己从头开始制备，成本高昂。

而容器就是《楚门的世界》。男主（容器进程）生活在一个大型影棚里，所有能接触到的世界只有这个影棚。男主住的房子，吃的东西，呼吸的空气来自于地球，生产成本很低。但他所能阅读的报纸，乘坐的载具，观看的电视都是影棚工作人员提供给他的，受到了严格的限制。

对于Docker来说，修改进程的动态表现是通过Namespace，构成进程依赖的文件系统是通过union mount，约束进程是通过Cgroups。

Namespace-欺骗的6种手段

1. 问题起因

Java应用的某个功能里有个循环，每个循环中调用MyBatis的SQL来获取Oracle的序列Sequence，然后把序列值填充到实体中，调用jpa的save方法将实体保存到数据库。
取序列号的sql没啥特殊的：

1

select seq_name.nextval from dual

但实际保存到数据库的时候，发现所有循环保存的实体的序列值都相同。

2. 问题分析

首先排除了Oracle数据库的问题。从这篇stackoverflow的回答，可以看到Oracle的序列实现是考虑很周到的。并发/Oracle部署方式/回滚都不会使序列重复。那么疑点就落在了MyBatis上。

以MyBatis为关键字，从网上能找到一些解答，例如如下这篇回答：

1
2
3
4
5

（该问题的原因）是因为其每次都会去取一级缓存中的值。
1.拿出@Transactional，就不会出错。
2.加上useCache="false" flushCache="true",不保存在二级缓存中，并清空缓存
3.mybatis.configuration.localCacheScope=STATEMENT,修改一级缓存的作用域
4.mybatis.configuration.cacheEnabled = false,禁用一级和二级缓存

Spring Cloud Config架构图

从上图可以看到，Spring Cloud Config（Git版）的架构还是非常简单的。简单的代价就是缺少可视化配置界面，无法实现灰度发布和自动回滚。要实现比较复杂和细粒度的权限控制也比较困难。
如果只使用Spring Cloud Config也没法实现配置自动刷新，还要依赖于Spring Cloud Bus。

技术资料

Spring-Cloud-Config-官方文档-server
Spring-Cloud-Config-官方文档-client
Spring-Cloud-Config-配置中心-git

对配置中心的期望

在具体评估技术之前，可以先列一下我们希望该技术能实现的目标，然后进行逐一确认是否能实现。
对于配置中心，我们的期望如下：

从代码和项目管理角度

问题症状

为了做一个Spring MVC的Java Web项目的CI，我写了个编译war包后启动tomcat的脚本。CI脚本很简单：

1
2
3
4
5
6

sit:
   script:
     - cd /root/
     - ./test-publish-xxx-sit.sh
   only:
     - develop

SSH到服务器手工执行脚本一切顺利。但通过gitlab-runner执行脚本，到最后一步执行./startup.sh启动tomcat的时候，遇到了两个很奇怪的现象：

• 和SSH下执行./startup.sh不同，没有打印环境变量（例如Using CATALINA_BASE:）。只显示了最后一句“Tomcat started.”
• 虽然打印了“Tomcat started.”，tomcat却没有正常启动。catalina.out里完全没有启动日志信息
  尝试过从权限和执行用户方向排查，都没有找到原因。

解决方法

在gitlab的论坛看到有人回答需要部署为linux的service，或者加个setsid，才能启动。结果证明这两种方式都是可行的解决方案。

问题是解决了。但疑问还是没解决：

实施计划

• 先以测试环境一个应用作为试点，实施配置中心
• 稳定运行至少两周后，在生产环境的该应用上实施配置中心
• 再稳定运行两周后，在测试和生产环境的所有应用都改为使用配置中心
• 配置中心先使用Spring Cloud Config。不够用的话再考虑评估Apollo和Nacos

选型的考量

Spring Cloud Config的原理和架构相对比较容易理解，所以先以Spring Cloud Config作为一个具体的实例，介绍一个简化版本的配置中心。如果只是小团队的话，Spring Cloud Config已经足够用了。
但对于大一些的团队来说，还是存在以下两个不足：

• UI只能依赖Gitlab的界面
• 依赖于Git的权限控制粒度比较粗，也很难扩展

什么是配置中心

这里引用几篇配置中心的科普文。

第一篇

概述

英文版
https://12factor.net/zh_cn/
中文版
https://12factor.net/

这篇文章是Spring Cloud文档的总述部分提到的。12要素指的是构建SaaS应用的方法论的总结，一共有12条。
当得知这12要素是在2011年就提出的时候，我不禁由衷地钦佩。想想11年的时候我[消音–]都在做些啥。。。
从另外一个角度可以学习到的是如何从实践中提炼和总结经验，然后总结为理论。通过“实践-理论-实践-理论”这样的循环，实现螺旋式地提升。

意义

类似“社会主义核心价值观”（手动狗头），12要素对我们的意义主要在对实现的指导性。我们有些时候会觉得当前的代码管理/配置管理/部署方案/运维方案不够好，但又不知道怎么改进；有些时候看到了多种改进方案，但不知道哪一种更好。在这种时候可以参考12要素来决策。

12要素归类

我认为12要素可以粗略分为几类：

代码管理