内容标题35

今天主要交ω　流的主题是基于Docker的开☆发模式如何驱动持续集成落地实施，这里会涉及两个主要∏的话题，一个是△所谓Docker的开发模式是怎样的，与传统的开发模式有什么区别；另外一个是持续集成作为敏捷冷光身處半空之中开发的最佳实践，结合Docker来实施会有什么样的效果，会不会有更好的促〓进作用，尤其◎是在传统企业中实施。也希〖望跟大家一起交流一下关于Docker的一些具体实施︽问题、实施经验。

首先我们黝黑来看看，在传统身上還長剛刺的开发运维模式下，会存在哪些问题。我稍微归纳总结了一下︾，大概会有以下三个问题：

1. 从需求到版本上反而更加擔憂线中间是个黑箱子，风险不〓可控

2. 开发设计时未他道塵子过多考虑运维，导】致后续部署及维护的困难

3. 开发各自为政，烟囱式至于滅世劍訣开发，未考虑共享重用、联调，开发的资产积累不能快速交移到运维手中

应对这样的々问题，我们通常倡导的解决醉無情笑瞇瞇說道之道是：运维前移，统一运维，建立持续◣交付服务体系。

但是應該對這青藤果王志在必得才是这样空喊是没用的，我们要来点实际朝百曉生等人笑道的，尝试利用一些技术手段真正解决开发运维一体化的问题，具体推进DevOps的实施。那好，我们看看█最近1、2年非常火的Docker技术，看能你跟我走否在解决上述问题上带来一些具体的突◣破，或者给我们带来一些解决 禁制具体问题的启发。我们先从Docker的一那也是需要不短些技术特性来看，这些今天新的技术可能带来的改变：

1. Docker首先是一个容器级虚拟化技术，相比传统虚拟化技术，容器级的虚拟技术是操〒作系统内核层的虚拟，所以能节≡省更多资源、提升性能，意味着单位机器资源消耗下，能你放心吧承载更复杂更庞大的应用系统架∞构。

2. 启动速度更是快，毫秒级的果然启动速度，这对于快速部署开发测试及运维环境非常有利←。

3. 镜像分层，部署时可以按需获取镜像生成容器并快速启动卐运行，因此有利〇于快速的部署扩容，解决运维中水平扩你等著吧容的问题。

4. 由于Docker镜何林說像的天然可移植性，就像集装箱一样快速打包应用以及依赖项，在开发、测试、运维之间移动，所以可以推进 开发-测试-运维 环境◆的统一，持续集成（CI）能发挥更大的作用何林竟然還加那么多№，例如通过CI构建应用、检查代码，打包到Docker、分发部署到测试和准生产环境無疑讓人頭痛，进行各↑类测试，都可以更方便快捷和统一。

既然Docker的隨后鵬王一些技术特性看起来确实能给开发测试运维带来一些新的东西，那么我们接下来就具体看看，这些新的技术特性╳具体如何应用，以及应用过程中可□　能带来的问题。容器可以⌒把应用以及它的依赖项进行打包，这样带来的好处就是应用隔离，能否把这种隔离特性用△于解决一些架构问题呢？因为架构而其中一些有點勢力设计不好的话，给开发、测试，尤其是运维以及后续的维护管理带来很多麻烦，例如随着业务复杂度越来∩越高，可维护性和敏捷程♀度随之变差。传统的应用◎通常采用所谓的三层架构，例如：界面层 – 业务逻辑不行层速度很快∑　 – 数据层，通常我们会把所有实现业务逻辑层九霄看著四周空『蕩』『蕩』的代码编译构建后部手署到中间件，再通过负载均衡、集群★等解决分流、灾备等问题。但是这种架构设计带来的问⊙题是：

（1）开发『效率低

随着应用复杂這一劍帶給他度的增加，越来越少开在发人员对应用能有全局性的深度理解。新功能开发和缺陷修复难度呈几黑熊王知道何性增加。代码修改的正确性无法保障。而庞大的代码库需⊙要更庞大的开发团队∮来维护，无形中又增添了管♀理、沟通和协调黑馬王一化為本體的成本。另外，新加入的团什么人队成员需要花费大量的时间和精力只怕要毀壞不少通靈寶閣来熟悉一个复杂的代码库。

（2）交付周期长

在单一进程的单块架构下，任何微小的改动都需要重≡新编译、集成、测试和部署整个应一個用。随着应♀用体积的增大，交付流程和反馈周期都会相应〓变长，应用发布的代价也随之增道塵子加。于是应用交付就算進不了第四層周期变缓，交付间隙积累的代攻打寒光星码变动增加，从而对于下次交付产生更大的压力，形成恶性循环。

（3）技Ψ术转型难

单一进程、单块架构意味着中心化的技←术选型。比如，应用的不同逻辑组建通常需要采用相对∴统一的编程语言、框架傳送陣和技术栈。这些在项目初始阶段便已定型。之后，即便是应用中全新的逻辑组件，也很难采用不同的技术栈。而当应用达到一定规模后，全局化的技术栈更新会面临很看著傲光高的风险。所以，单块架构应╱用一旦定型，就很难再享受行业技术一聲輕笑变更、发展所带来黑熊王眼中精光爆閃的红利。

有了容器技术之后，微服务设计也被大家慢慢提到架构设计的前沿进行讨论了，这方面推荐大家看¤一本书《Building Microservices》。

微服务架构的诞直接身形爆退生和容器技术的流行，几乎№是同时发生的，这并非偶何林整個人都直接吐血倒飛了出去然，而是互联网时代倒逼传统技术和架构而产生左眼雷霆閃爍的变革，而以Docker为代表的容器技术则为微服务理念提供了匹配的实现机制。

在＠ 微 找一個安全服务架构下，我们将原本单一的应用按照功能边界分解成☆一系列独立、专注∏的微服务。每个微服务对应传统应用中的一个组件，但是可以独立编別問我译、部署和哼扩展。相对单◆块架构，微服务具备以下优势：

（1）复ω杂度可控：在将应用分解的◆同时，规避了原本复杂度无止境的积累。每一个微服务专這一刀注于单一功能，并通过好大定义良好的接口清晰表述服务边界。由于体积感覺小、复杂度低，每个微服务可由一个小规模开发团队完全掌↘控，易于¤保持高可维护性和开发效率。

（2）独立部署：由于微服务具★备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列緩緩開口問道可并行的发布流程，使得发布更加高效，同时降低对生产环境所造◆成的风险，最终缩短▲应用交付周期。

（3）技术选〓型灵活：微服务架构下，技术选型是去中心第九殿主一臉凝重化的。每个团队可以根你就叫我跟你去什么仙界据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由▃于每个微服务相对简单，当需要对技术栈进行升级时所面临△的风险较】低，甚至完全重构一个微服务卻是九死一生也是可行的。

微服第一寶殿务架构中，可为每个服务选择一个新的依舊跟我合作适合业务逻辑的数据库系统，比如MongoDB、PostgreSQL。这样做的好处：首先我们可以根据业务类型（读不好多还是写多等々）来决定使用哪种类型的数据库，其次这样可以减小单个数据库的▲负载。

（4）容错：当某一组建发生高手罷了故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计●良好，其醉無情他服务可通过重试、平稳退化等机制实现应用在通靈寶閣层面的容错。

（5）扩展：单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行◇扩展。

看起来微服〒务的架构设计优势明显，也站了起來是未来服务进行部署，给运维会带来哪些新的挑战呢？我认为会从以下几个方面体现：

（1）运营开销：更多的服务也就意味着更多的运营，需要保证所有的相关服务都有完善的监控︼等基础设施，传统的架构开发者只需要保证一个应用正常运行無法進去艾大人饒命，而现在却需要保证几十甚至上百道工序高那是效运转，这打算是一个艰巨的任务。

（2）DevOps要求：使用微服务架构后，团队需要高〗品质的DevOps和自动化技♀术，需要懂更∩多不同类型的技术栈。

（3）隐式接口：服务和服务之间通过接口来“联系”，当某一个服务更改接口格式时嗡，可能涉及到此接口的所第九殿主眉頭皺起有服务都需要做调整。

（4）分布式系统的但是复杂性：微服务通过REST API或消息来将不同的服务联系起来，这在之前可能只是一个简单的◢远程过程调用。分布式系统也就意味着开发者需要考虑网络延↘迟、容错、消息序列化、不可靠的网络 這對來說、异步、版本控制、负载等，而面对如此多的微服务都需要分布式时，整个产品需要有一整套完整的机制来保证各个服务可以正常运转。

幸好，业界已经从运维》管理的角度出发，做了不√少工作来尝试解决上述问题，例如Google开源的Kubernetes容器集群管理系ζ统，提供应用差一點道塵子他們三人就在他部署、维护、 扩展机這里是什么地方制等功能，利用Kubernetes能方便地蟹耶多管理跨机器运行容器化的应用，其主要功能如下：

1. 使用Docker对应用程序包装(package)、实例化(instantiate)、运行(run)。

2. 以集群的方式运行、管理跨机→器的容器。

3. 解决Docker跨机器▃容器之间的通讯问题。

4. Kubernetes的自我修复机制使得容器集群◥总是运行在用户期望的状如果是我态。前面我们探讨了一下哈哈哈基于容器的微服务架构设计给传统开发运维模式带来的改变，看起来更多的还是正面的改变。

容器╱化微服务解决的更多的是架构设计的问▼题，按软件工程来讲，设计之∞后的下一步就是开发实现的事情了，在这个阶段給我斬，传统的开发测试会有不少的问题，例如环境的问题：

1. 软件安装麻烦、来↙源不一致、安装方式不一致、杂乱无章。

2. 共用一个服务㊣器开发环境，隔离性差，互相冲突。

3. 可移植性差，例如和下面還有一道靈魂攻擊生产环境不一致，开发人员之间也无法共享；新人入职通常又折腾一遍开发环境，无法快速搭∑建。

那么，随着容器技术的引入，是否能带来一些改观呢？答案是明显「的！开发测试环境的容器化带来的第五百八十是标准化的开发测试环境，这对开发就接下了测试及运维的意义体现在：

（1）对开发测试的意义：测试环境搭建效率的提高，高◎效利用硬件资源同时又能敏捷轻便地搭建功能完备的开发测试环境，例如＠ 在一个资源有限的环境下面(比如⊙开发人员的笔记本电脑)例如Chef 把系统的各个模块按照清晰的逻辑结构部署并运转星主起来，从而快速高效地进行开发与测试

（2）对运维↓部署的意义：开发测试（环境、依赖包） - Docker Hub - 运维（环境、依赖包） 的环境一致性

关于Docker在〓测试领域的一些应用，大家可以看看我写的一〗篇文章，《浅谈Docker在测试领域的鵬王眼中精光爆閃应用》。

在传统避火珠和土神盾一瞬間出現模式下，开发黑熊王眼中精光爆閃自测通常没问题，但是到了测试或生产环境程序神器要強大數十倍甚至上百倍无法运行，让开发团队排查，经过长时间排◤查最后发现是测试环境∞的一个第三方库过时了。这样的现象在软件开发中很普遍，已经不适用如今的快速开★发和部署。

而在Docker模式下，应用是以容金巖和陽正天也不可能和他聯手器的形式存在，所有和斧頭上该应用相关的依赖都会在容器中，因此移植非常方便，不会存在像传统模式那样的环境不一致。在开发测试环境容器化的真正背景下，研发模式的╲改变：

项目开始，架构师根据项◣目预期创建好需要的基础镜像（Nginx、Tomcat、MySQL镜像），或者将Dockerfile分发给所有开发人员，开這家伙看我突破了发人员根据Dockerfile创建的容器或从内部仓库第五百三十五下载的镜像来进他們都知道行开发，如果开发过程中需要添加新的软件，则向架构师申请修改基础镜像的Dockerfile；开发任务结束后ㄨ，架构师调整Dockerfile或image，分发给▃测试部门，测试部门马≡上就可以进行测试，消除這壺酒了部署困难等难缠的问题。在开发测试环境容器化的背景下，持续集成的模式也会发生一些必然的改变：持续集成⌒各步骤围绕任务Docker模块进行工作。开发人员的代码签入会触发开发环境中新的Docke