转载

docker为什么这么火？

【有段时间没有接触docker了，今天偶然想了以前做的服务器程序，联想到了docker为什么会如此受欢迎。我只是想谈谈自己的感受。】

记得是09年到10年这一年我有幸参与了当时还算比较火的即使通信工具飞信的服务器研发与运维工作。我的服务要在12台服务器上做集群部署，用来支撑全国的短信下行与上行通信，并与其他服务进行对接。当时全国每秒钟单台峰值10000个请求，整天是1到2亿的规模。除了正确路由消息还要记录日志，过滤敏感词等计算密集的job。可以想象维护这样的服务并不是轻松的事，而且当时上行短信还要计费，对账。可以想象，如果把这些服务放在一个进程中是多么可怕的事，但是，现实是我接手时差不多就是如此的，所以我们需要做切分。我读研究生时，记得有个老师说的话很有道理，我一直都记得——人们面对复杂事物的一般性解决方法就是：切分。比如将大而复杂的问题划分成比较小的子问题，然后对子问题求解，进而归纳，演绎，跌代出整体问题的解。很多算法的套路如分治算法，动态规划都是采用类似的思想，大多的算法题也逃不出这个思维方向，难点应该是在如何去划分问题本身了，得出的效率也是有较大差异的。那么我们当时是如何做切分的呢？现在大家每天在谈分布式，集群，大数据应该对这类问题都很清楚了，而且做服务也尽量会主动向分布式方向思考，而在6年前，真正懂分布式的人并不多，google也刚刚发布了著名的三篇论文，很多人也在消化。而我们将业务切分为三个服务，消息路由服务，日志服务与经营分析服务。消息服务接到消息后根据类型进行投递，并通知日志模块记录日志，经营分析模块定期与日志模块通信进行计费。当时为了完成三个服务的切分，必须对程序进行了大量的改造，包括编写ha-master与ha-slave来管理服务消息路由与配置分发与反向拉取，现在想想，当时要是用zookeeper就好了，但是决策层决定要自己开发。当时很多代码都得自己完成，测试，并维护，对进程的控制，RPC（当时用的pb）消息序列化反序列化程序；然后包括服务的监控，自动化部署，服务起停，心跳等都得自己写；开发周期太长，太难管理，太难运维了，太难测试了，而且bug很多，挺影响运营周期的。但是也从侧面反应出docker为什么会如此流行，因为大多数重压力服务必须做分布式部署，微服务化部署，因为服务要做切分嘛，而分布式程序不是所有程序员都能handle的，写出来的程序要么bug多，要么性能达不到，要么就是无法运维；幸好docker出现了，它可以很方便的将你切分的服务放入一个隔离的容器中运行，从而大幅降低使用，维护，改造分布式服务的门槛，而不用每次都掉坑里，也不用重复发明轮子，因为docker将一个分布式程序要做的基础工作都已经用最优的方式完成了。当然你如果是个技术控，你想要翻一翻原理的话直接读docker源代码就行了。

大数据时代的到来提高了人们工作的效率，生活的质量；使得工程师可以通过分析海量的数据了解或者预测以前不能预测以及无法了解的事情，从而带来巨大的社会与商业价值；而大数据分析的需求又驱动着技术形态的变革，使得服务器的计算构架发生了重大的变化，单个计算机，甚至小型中型大型机的瓶颈也变得凸显，人们不再追求CPU的频率，而逐步致力于提升程序运行的并行性，革新出所谓的双核，4核乃至8核的CPU；服务器的集群，云平台的出现也使得计算能力变得触手可得；甚至可以用来贩卖。因此，分布式，并行化的程序是未来的方向；而docker等技术正是迎合了时代变革产物。

正文到此结束