更多云场景实践研究案例，点击这里：【云场景实践研究合集】联合不是简单的加法，而是无限的生态，谁会是下一个独角兽
南京路特软件的产品线内子产品太多，并且相互有重叠，导致基础服务大量重复，并且无法在开发阶段将其拆开，面对40台服务器和一堆服务，公司却仅有一个专职运维人员，此外，公司的持续交付产品/服务效率非常低，也无法有效掌握负载峰谷，进而合理调配资源。通过使用阿里云容器服务，较好地解决了其所面对的敏捷、成本、可靠这困扰南京路特的三大核心问题。当然，在这一过程中，南京路特也在Docker实践中不断踩坑，也不断地总结经验教训，并总结出了适合中小企业实践Docker技术的两个常用场景。
“从痛苦到曙光，从濒临放弃到看到曙光，再到磕磕绊绊行至远方，感谢我们所有的媒体客户和阿里云默默的支持。路还很长，你我同在...”
——戚俊
南京路特软件有限公司CTO
采用的阿里云产品
- 阿里云云服务器 ECS
- 阿里云负载均衡 SLB
- 阿里云文件存储 NAS
- 阿里云对象存储 OSS
为什么使用阿里云
敏捷、成本、可靠是南京路特面临的三大核心问题。使用阿里云容器服务可以帮助开发人员实现敏捷开发，降低业务成本，提高系统的可靠性。
阿里云容器服务可以通过设置参数进行配置，当集群挂掉之后，可以有办法把容器放到另一个集群里面去。
关于 南京路特软件
南京路特软件有限公司是国内专业的媒体融合解决方案的提供商和服务商，国内领先采用云计算技术和互联网服务模式的媒体融合解决方案，已取得多项国家发明专利和软件著作权，目前发布的服务产品：全媒体系统、内容发布系统、智慧掌媒系统、数字报系统、微媒体系统、融媒体应用平台等。
南京路特使用阿里云容器服务之前所遇到困境
南京路特在使用容器服务之前的系统遇到了很多挑战，首先是产品线内子产品太多，并且相互有重叠，进而导致基础服务有大量的重复，如邮件服务、短信服务等，但在开发阶段，无法将其拆开。其次，在运维方面，目前全公司共有40台服务器和一堆服务，但只有一个全职运维人员。最为核心的问题是公司的持续交付产品/服务效率非常低，导致人力的极大浪费和挥霍。此外，传统架构设计无法有效掌握负载峰谷，并且无法合理调配资源。并且公司对可靠性和安全性的要求非常高。每天有几百家媒体依赖公司产品进行生产，但公司却无法提高业务可靠性。
南京路特使用容器服务之前的架构设计
如图所示的是南京路特使用容器服务之前的架构设计，每一行都是相同的。一堆客户去访问一个公网IP，这个IP背后可能是一台ECS服务器，然后ECS服务器中可能部署了一个或多个应用，应用背后对应着阿里云数据库服务或缓存、日志服务等等，这全部组成最小单元。在顶峰时，公司内有多大60个最小单元，涉及到近80台云服务器，进而导致升级、维护问题的出现。最后只能放弃这种方式，因为一旦代码发布之后，需要升级时，只能和客户约定好升级时间，但由于客户都是独立部署的，导致出现今天给这家升级，明天给那家升级的状况出现。
为什么选择阿里云？
南京路特所面临的核心问题
敏捷、成本、可靠是南京路特面临的三大核心问题。敏捷是指敏捷开发、敏捷部署方面；成本是老板和CTO都要关注的问题；可靠性是保障。
容器技术&敏捷开发
容器技术和敏捷开发方面，目前面临的问题有三点：
- 统一开发、测试、业务环境。不同的版本、应用、运行环境的差异导致各类问题的出现，而且通常是无法预料的；同时，新入的员工仍需要重复地搭建各种开发、测试、运行环境，导致效率不高。针对这个问题，我们的解决方案是将所有的基础环境极性统一封装并打包在镜像仓库中，新入职的员工，只需将该镜像下载，并在本地调试和开发时，将自己的代码放到镜像中。尽管进行时只读的，但是镜像是有办法和外面硬盘数据互通的。此外，通过这种方式开发、调试代码不会再出现问题，因为所有的镜像都是一致的，与操作系统无关。
- 不同时期开发应用如何泾渭分明持续开发。这个问题是很多中小型企业开发团队所面临的痛点。新入职的员工不愿去维护之前的旧代码。应对这种问题，可以采用拆分的方式将应用拆的稍微洗一些，一个大应用中其中几项可以拆分出来变成小应用，拆分之后的维护成本会降低很多。当持续开发时，不需要再去重写这些小应用，只做必要的事。
- 亟需解决代码污染问题和手动打包故障。当公司小应用较度时，打包会经常出现这类问题。目前是采用Git自动构建来解决之隔问题，因为它拉的代码是Git里面的代码，而Push分支时，自动创建一个镜像，这种情况下不太可能会出现代码污染或手动打包故障。
容器技术&业务成本
下面看一下容器技术和业务成本之间的联系。目前主要有以下几个方面的成本问题：
- 长时间停机更新成本太高、体验太差。之前，我们的更新只能在凌晨三点进行，一旦出现问题，在早晨八点之前要把问题解决掉。这种情况造成了很高的成本，有时候更新代码会耗费一整个通宵，特别是出现回滚时更加麻烦，这个解决方案，之前的演讲人所讲的蓝绿发布其实很好地解决了这个问题。
- 多机负载场景下很难做到同一时刻集体更新，出错后回滚成本很高。这个问题采用蓝绿发布也可以解决，我们公司内部采用的是阿里云容器服务内可以去开负数的容器，在容器没有更新完之前，用户是不可能访问到新镜像的内容。
- 业务无法精准弹性，仅仅服务器级别的弹性还不够。我们40台服务器里面能占到80%利用率的可能只有三分之一。三分之二的时间，资源都是闲置和浪费的。我们通过容器级别的弹性，例如可以给网站服务或者是API接口的服务开通更多的容器让其提供更好的负载，达到更好的执行效率。这种情况下，一个物理机真正能够提供这种可靠运算资源的这种量会非常大，远比想象中要好。因为正常情况来说，一个机器不可能同时所有的情况都是满载的。
容器技术&可靠性
容器技术和可靠性方面。可靠性其中的一点是在云端整体故障迁移问题暂时很难得到解决，但却是大家都需要的。在云端，大家都忽略了热备这个问题，认为云上不太可能会出现硬件损坏故障的情况，但是事实上是会出现的。阿里的容器服务现在是有参数是可以去配置的，当集群挂掉之后，可以有办法把容器放到另一个集群里面去，可能现在还没有办法很完美的解决域名或者端口的配置的问题，可能还需要手动调节，但这已经很大进步。
对于多机负载场景下数据的同步和共享访问问题。一些老的服务，解耦不好的情况下，它的附件是无法分离出去的，或者存在一些集中读取集中写入的情况，则需要通过共享存储来解决这个问题。目前通过容器服务提供的两种方案解决该问题：一是OSS数据卷；另一个是NAS数据卷。二者都可以支持多个容器访问同一个文件数据源，然后对其实时进行集中写入、读取等操作。
南京路特在Docker实践中所踩过的坑
总结南京路特Docker多年实践所踩过的坑，或许会对大家有所帮助：
- 不解耦容器用不好！这是一个很显然的事情，因为如果容器内有一大堆应用，相关性太高了，一旦容器出了问题，很容易导致应用不可用甚至整个业务体系的瘫痪，仅此要将应用解耦，这是一个很重要的问题。
- 就是微服务。尽管现在微服务很火热，并不是架构拆分成微服务之后就特别厉害。微服务有它的合理之处，但是不是所有的业务都要去做微服务。通用、重复、可复用的应用可拆开做成微服务。
- 就是项目越大越难以使用容器架构。南京路特目前是绝大部分产品在容器服务里，但是不是所有的产品都在容器服务里，有一些比较大的产品是放不进去的。这其中既有自身内部管理的问题，也有产品业务场景的问题和用户的需求问题等问题。项目越大，涉及到面越广，涉及到面越广就难去对它动刀子，把它放到容器集群里去。
- 可靠性。不要指望Docker来解决可靠性的问题。Docker和容器技术，可靠性关联的因素相当之多，上到网络环境和整体架构层，下到开发人员的素质。这是因素不是采用Docker就可以解决的。
最后，容器技术它只是一种架构的选择。单机跑Docker就是一种实验，组成集群运行时，才能够真正地发挥它的力量。
Docker容器的常用场景
第一个场景是高效API集群。有时会遇到这种情况，公司内的API有的是可以供外界使用，有的不可供外界使用，但该API可以给公司的APP使用；公司的APP可能是走官网的途径去访问API，同时这个API也可以被内部服务调用。这种情况带来的问题是：当用域名去访问时，在外网调用时不存在问题，但在内网调用的时要走DNS，甚至还要走官网流量通道去访问这些东西。事实上，内网调用的那台服务器跟API服务器可能相隔很近。这种情况下可以通过一个模型去解决该问题：内部服务器发起调用时，采用内网的负载均衡（阿里的内网负载均衡是不收费地）；外部调用时，采用外网的负载均衡（大概只收取流量费）；这两个分别连接到API的容器集群（容器集群就是阿里的容器服务），容器集群内部做好相关的配置工作。这样做的好处是：当集中使用该服务时，可以自由的选择。云上的调用可以通过内网的SLB完成；外网的调用可以通过外网的SLB去完成，可以得到一个最大化和一个最可靠的访问效率，外网访问时，可能是10毫秒；内网访问时，在1、2毫秒左右。
第二个场景是快速交付应用/服务。因为公司的本身是做SaaS服务和应用软件的。大部分工作是协助开发和客服性质的工作，以及一些部署性质的工作也需要开发去完成。我们采用一个模型去解决问题。研发完成产品镜像之后，将镜像提交到代码仓库中；运维人员进入容器服务，然后创建一个集群，通过编排模板直接创建一个应用，应用创建之后去修改服务的配置。因为容器与原来所熟知的代码的运行方式不太一样，有一些配置文件需要修改等。目前解决方式是把所有的配置都写在容器环境变量里面，这也是主流的一种方法。然后修改服务配置、修改环境变量、重启服务。重启服务之后，容器重新启动之后会读取一个环境变量作为它的配置，这样就可以成功运行了。
关于南京路特软件的更多实践详情：中小企业Docker实战：那些年我们踩过的五个坑
原文发布日期：2016-08-25
云栖社区场景研究小组成员：贾子甲，仲浩。
