扇贝丁彦：大家好，我是扇贝的技术总监丁彦，之前在暴走漫画，先后在暴走漫画和扇贝设计和主导了基于 Docker 的微服务架构系统，以及数据收集和分析系统。去年来到扇贝，这里是 Python 的开发环境。后来发现业务增长快，水平扩展一些机器，出现问题需要换个机器等等，都需要非常熟悉业务的少数开发去做。另外公司对预算控制严格，机器基本都是满负荷运作，平时也不可能多开空置的机器，已有的机器还要根据负载情况调整服务分布情况，所以这种切换服务，增删服务的操作还是比较频繁的。因此，我们用了2-3个月的时间将所有的运行环境都切换到 Docker上，这大大提高了我们的运维能力。
Docker 包装有几个好处。
第一个好处是，环境升级非常方便。因为只要pull 一下最新的镜像，启动一个 Container，环境就升级了。而如果直接基于公有云的镜像升级的话就很难，因为一台机器上跑哪些服务其实不一定是固定的，并且之前做的镜像只要有一台机器是还基于它的话，就删除不掉的，镜像数量又有上限。所以docker 非常好地解决了我们的问题。
其次是环境的颗粒度会更小，一台机器上配好几个应用的话，往往配着配着，到最后你就不太能精确地记得上面装的程序或者库是给哪个应用服务的，应用之间如果依赖有版本的冲突也很难调和。你想做些服务的迁移，把负载比较小的放一起，把负载比较大的抽出来，这个时候就非常痛苦，但你如果用 Docker 包装后就非常简单，只要在不同的机器上起不同的 Container，就可以实现这一点。
第三，我们不光用了 Docker，还加入了服务发现，刚刚讨论配置管理这些，我们一并做了。Docker 启动时候，我们自己写了一些工具，可以自定义Docker启动参数，包括配置参数，比如说，一些程序要运行的参数，我们主要用两种方式，一种方式是通过环境变量灌进去，还有一种方式让程序的启动脚本支持参数，然后拼接不同的参数灌进去，最终都是落实到Docker的启动命令上。服务发现是基于 Consul，Docker 的启动命令是从 Consul 里取的。首先 Consul有 HTTP 的 API，我们是自己写的 pip 包，只要 Include 一下这个包就可以了，Docker 的服务启动后会自动注册到 Consul。比如要在负载后加一个服务，只需要找到一台机器，启动对应的container，剩下的事情它自己会到 Consul，注册它的参数地址一系列东西，自动把它加进去。所以这些都是自动化的，如果检测那台机器/服务挂了，Health Check 也会到 Consul 里面更新。该增加机器就增加机器，该下线就下线。总体来说，我们的生产环境全部跑在 Docker 上面的，然后区分有状态和无状态两种，有状态的定死在机器上，无状态的灵活的自由切换。还有一点，如果是有状态的容器要定死在机器上的时候，我们一般来说都会采取冗余的结构，至少保证有两个在运行，一个挂了，保证整体的服务在运行。其次基于 Docker，我们还做了一套数据搜集以及分析的机制。数据搜集是基于日志来搜集的，利用 Docker 的 Log driver，把日志打到 Filter，把结果存在存储服务上。同时监控也是基于日志做的。第三部分非生产环境，比如开发环境跟测试环境都是 Docker 做的，因为我们每一个服务都做了 Image、镜像，用容器方式跑的。通过参数来决定启动方式的，我们可以在开发环境以及测试环境采用不同的参数来启动容器。 通过 Consul 来隔离的，因为 Consul 的服务发现，开发、生产、测试环境在不同的自动发现框架里不会相互影响到。目前机器在 120 台左右，基于云服务。有些基础的东西不需要依赖于 Docker，比如说申请云主机，申请的时候就可以指定它的 CPU 和内存这些服务器资源的配置。所以这部分东西还是属于 Human schedule，不是完全让编排的系统自己决定该怎么样。
编排工具我们现在在研究进一步，我刚来这工作的时候，所有的服务没有一个跑在 Docker 上面的，我现在把它迁进来。现在数据增长，已经有一些编排的瓶颈，现在在做调研，可能基于 Swarm，做自动编排的设计。
第二轮话题交流
主持人:容器多的情况下 Kubernetes 存在性能问题，各位在这方面有没有好的经验?
扇贝丁彦：我们其实也遇到了这个问题，找不到办法所以放弃了 Kubernetes。我们也是用公有云，网络直接依赖公有云的网络，有可能是因为公有云造成的，我没有试过在祼机上试过。