本文正在参加“最佳上云实践”评选，来给我们投票吧：https://yq.aliyun.com/activity/158（编号3）
在2015年12月29日，菜鸟推出了中国首个物流云平台，韵达成为首家战略合作伙伴，也是国内首家业务系统全面上云的快递企业。
所谓物流云，是一个基于云计算的物流基础信息服务平台，它能提供安全稳定的云设施环境，帮助快递企业和物流订单涉及所有链路成员建立连接、沉淀大数据，并在此基础上提供多样化的智能产品。
上云过程
下图是韵达上物流云的整个进度。
![317e70d39ad3fc4ce435912b3072f88fe37f72ec]()
刚开始讨论是否上物流云的时候，还是很纠结的。整个的核心系统要从IDC机房整体搬上物流云的过程中会遇到哪些问题？如何保证业务不受影响？所以前期和菜鸟进行了多次的合作讨论和方案论证。项目立项完成之后，针对十六个核心的业务系统（订单、COD、仓储、客服、跨境等）进行了拆分，降低关联性。上云之后继续和菜鸟进行深度合作，解决上云之前遇到的一些问题（系统架构优化、云上数据推送、大数据分析、全链路日志监控等）。
混合云架构
下图是韵达所采用的混合云架构。
![87569e4bafd0b190064e93bd4a9715a4e5bb71bf]()
上图左边部分是韵达自有的IDC机房的一些应用服务，主要为涉及财务结算的系统。中间部分是韵达核心系统上云之后的架构图。右边是跨境业务在香港机房的系统架构图。从图中可以看出，上云过程中做了很多系统改造工作，比如使用多可用域、跨多个物理机房做了相关的集群部署。
数据迁移上云
典型的问题是数据迁移。怎么在线下把韵达大量的数据搬到云上又不能对线下的系统造成影响？
最终讨论得到的解决方案是：在云上用了一台ECS服务器安装了MySQL的备库，对IDC机房做了一个主从的同步，使用了阿里云DTS工具从中间库向最终的目标RDS库进行数据同步。这个方案可同时实现存量数据迁移、增量数据同步到云上，数据同步的网络延迟毫秒级（DTS同步速度理论上可达到70Mbps）。
云上资源调度
考虑到降低IT成本，我们采用了Docker技术。Docker是集装箱演变过来的，集装箱可以对货物进行标准化的分装，不同集装箱之间可以做很好的隔离，Docker就是引用这种理念产生的。
Docker可以将文件系统进行隔离，包括将资源、网络进行隔离，每个容器相互之间不会受到影响，并且可以通过cgroup的技术对资源进行很方便的分配。
为什么要使用Docker？
作为一种新兴的虚拟化方式，Docker跟传统的虚拟化方式相比具有众多的优势：
- 首先，Docker容器的启动可以在秒级实现，这相比传统的虚拟机方式要快得多；
- 其次，Docker对系统资源的利用率很高，一台主机上可以同时运行数千个Docker容器；
- 容器除了运行其中应用外，基本不消耗额外的系统资源，使得应用的性能很高，同时系统的开销尽量小。传统虚拟机方式运行10个不同的应用就要起10个虚拟机，而Docker只需要启动10个隔离的应用即可。
对开发和运维（devop）人员来说，最希望的就是一次创建或配置，可以在任意地方正常运行。开发者可以使用一个标准的镜像来构建一套开发容器，开发完成之后，运维人员可以直接使用这个容器来部署代码。Docker可以快速创建容器，快速迭代应用程序，并让整个过程全程可见，使团队中的其他成员更容易理解应用程序是如何创建和工作的。Docker容器的启动时间是秒级的，大量地节约开发、测试、部署的时间。
下面从六个维度将Docker和传统虚拟机进行了对比。
![b767673a1ffec688f425b8ee19840bd21ba990c6]()
传统型软件开发，从开始搭建开发环境到测试，再到上线，是一个很繁琐的过程。如下图：
![c32dd1eb2c06019b40eaf27d7a282e56d7f8430d]()
这个过程中存在以下不足之处：
- 资源利用效率低；
- 单物理机多应用无法有效隔离（进程空间，cpu资源，磁盘）；
- 运维部署不便；测试、版本管理复杂；
- 迁移成本高；
- 传统虚拟机，空间占用大，启动慢，管理复杂。
采用Docker仓库，把需要的环境封装好，把相关的镜像上传到仓库里面。开发人员直接从仓库里获取相关的镜像来进行相关的开发测试。测试人员和运维人员同样可以从仓库获取相关镜像进行相关工作。整个过程十分便捷，而且占用的资源比较少。
![894a89cdaa68a4c38b6f4279c023b5bf5d9e5079]()
开发人员编写好代码之后，进行环境定义，最终把定义好的文件打包封装成一个镜像上传到仓库中。当存在对多个Docker镜像进行管理的时候，可能会遇到一些问题，Docker官方提供了Docker-compose工具。这个工具多个具有依赖关系的镜像进行管理。
Docker化过程中踩过的“坑”
下面是我们在使用Docker的过程中遇到的一些问题，希望对大家能有一些参考：
- dockerfile不要放到代码根目录下，docker编译dockerfile时，会把dockerfile同级目录所有文件传递给docker deamon，避免大量文件传递给docker deamon，导致内存爆掉；
- Dockerfile行数尽可能少，否则最终生成的镜像会很大；
- Dockerfile注意字符编码环境变量以及时区设置。
尽管Docker相对虚拟机有诸多优势，但是也有一些不足之处，比如：
- 安全性问题。docker目前并不能分辨具体执行指令的用户，只要一个用户拥有执行docker的权限，那么他就可以对docker的容器进行所有操作，不管该容器是否是由该用户创建。比如A和B都拥有执行docker的权限，由于docker的server端并不会具体判断dockerclient是由哪个用户发起的，A可以删除B创建的容器，存在一定的安全风险；
- docker目前还在版本的快速更新中，细节功能调整比较大。一些核心模块依赖于高版本内核，存在版本兼容问题。
上云带来的好处
上云之后，带来的好处也是显而易见的，投入成本大大降低，云上运维变得简单。现在我们的人员投入已经减少到6人，云资源的使用成本相比自建硬件投入成本大大降低，另外，上云项目周期也缩短到了2个月，由于不需要维护基础设施，云上的运维也变得更加简单。
下一步的工作
怎样自动化的完成后续交付和部署的工作？目前采用的方式是开发人员把代码上传到SVN上，通过第三方的开源工具、自动化的发布工具进行相关的管理工作。后续跟菜鸟多次探讨之后，可能会使用阿里云的持续交付平台来解决持续发布过程中遇到的一些问题。
未来计划做的一些工作：
- 优化：Docker本身的性能优化，比如，dockercontainer 在stdout/stderr有大量数据传输会导致内存泄露；
- 监控：服务级别的监控；
- 负载均衡：容器根据机器负载情况自动迁移；
- 统一管理页面：统一的根据服务来管理的WEB页面；
- 微服务：应用程序功能模块拆分，适应Docker的使用。
![6e89d791a2746231f030c9d1fbc40e2adb23ca48]()
