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