社区微信群开通啦，扫一扫抢先加入社区官方微信群
社区微信群
2015年8月28-29日，首届CNUTCon全球容器技术大会在北京举行。大会吸引了近千名对容器技术感兴趣的中高端技术人员，灵雀云（www.alauda.cn）CTO陈恺带来的演讲“Docker与微服务架构的最佳实践”，引起了大量参会者的关注。
关注公众号（AlaudaCloud），回复“CNUTCon”，可下载演讲PPT。
微服务作为架构模式的变革，其诞生绝非偶然。它是当传统服务架构在互联网时代遭遇挑战时，人们对于架构模式，开发和运维方法论的一种反思。陈恺首先以电商网站为例，回顾了这十几年以来应用架构的演化历程：
十几年前的电商网站，逻辑、代码没有明显的区分，代码和代码之间的相互调用也是错综复杂。页面显示、用户管理、支付、配送等功能都在一起，应用的架构没有规律可寻；
随着高级语言的发展，带来了很多方便的访问数据的机制，代码和数据访问相关的功能逐渐形成一个比较清晰的结构；
随着面向对象、设计模式、架构模式这些理念和方法论的不断的发展，逐渐形成了分层架构。
分层架构虽然在逻辑上有分层，但在物理部署的角度仍然是一个单块，作为一个整体进行编译、测试、部署。单块架构有以下几个优势：
便于开发：大量常用的集成开发环境（IDE）和编程框架（如Rails，Django）为开发者提供了方便和熟悉的开发、调试体验；
便于测试：由于整个应用包含在一个进程中，在常用工具的配合下应用可以很容易在开发、测试环境中启动；
便于部署：多数编程语言和框架都有特定的应用打包格式，部署只需将单一软件包复制到运行环境。
在项目的开始阶段，单块架构有非常方便的地方，但随着业务的拓展，单块架构很难适应快速变革的需求，遭遇一些挑战：
开发效率低：随着应用复杂度的增加，越来越少开发人员对应用能有全局性的深度理解。新功能开发和缺陷修复难度呈几何性增加。代码修改的正确性无法保障。而庞大的代码库需要更庞大的开发团队来维护，无形中又增添了管理、沟通和协调的成本。另外，新加入的团队成员需要花费大量的时间和精力来熟悉一个复杂的代码库；
交付周期长：在单一进程的单块架构下，任何微小的改动都需要重新编译、集成、测试和部署整个应用。随着应用体积的增大，交付流程和反馈周期都会相应变长，应用发布的代价也随之增加。于是应用交付周期变缓，交付间隙积累的代码变动增加，从而对于下次交付产生更大的压力，形成恶性循环；
技术转型难：单一进程、单块架构意味着中心化的技术选型。比如，应用的不同逻辑组建通常需要采用相对统一的编程语言、框架和技术栈。这些在项目初始阶段便已定型。之后，即便是应用中全新的逻辑组件，也很难采用不同的技术栈。而当应用达到一定规模后，全局化的技术栈更新会面临很高的风险。所以，单块架构应用一旦定型，就很难再享受行业技术变更、发展所带来的红利。
陈恺在CNUTCon全球容器大会发表演讲
微服架构就是在这种情况下诞生的，它能快速响应市场需求，快速迭代、快速交互，是企业在互联网时代保持竞争力。
微服务架构（Microservices Architecture）是一种架构风格（ArchitecturalStyle）和设计模式，提倡将应用分割成一系列细小的服务，每个服务专注于单一业务功能，运行于独立的进程中，服务之间边界清晰，采用轻量级通信机制（如HTTP/REST）相互沟通、配合来实现完整的应用，满足业务和用户的需求。
相对单块架构，微服务具备以下优势：
复杂度可控：在将应用分解的同时，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率；
独立部署：由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期；
技术选型灵活：微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，当需要对技术栈进行升级时所面临的风险较低，甚至完全重构一个微服务也是可行的；
容错：当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错；
扩展：单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。
天下没有免费的午餐，微服架构架构归根到底是一个分布式系统，相对于单块系统，无论开发、运维都是不简单的事情。而Docker的设计初衷之一就是简化分布式系统从创建到发布，到部署、运维的整个流程。
以Docker为代表的容器技术则为微服务理念提供了匹配的实现机制，基于容器的云平台，则为容器化的微服务在云端的实践提供了很好的基础。陈恺以灵雀云为例，介绍了基于容器的云平台，如何为容器化微服务在云端的实现提供解决方案。
灵雀云服务
上图是灵雀云提供的服务，在左边通过持续集成、镜像构建等一系列服务，帮助用户把代码转化为可以随时随地发布的镜像；右边可以在几秒钟之内，把任意容器化的应用发布到云里面，同时提供一个高可用、高性能的容器托管环境；中间是镜像中心，把两端的服务连接起来，打通了一个容器化的应用，从开发、集成、发布、运维的流程。灵雀云可以优化这个流程，节省开发者的时间，降低创新的门槛。
开发
灵雀云的镜像构建和持续集成服务帮助用户将独立、可复用的微服务打包，转化为随时可以部署的容器镜像。灵雀云可以和GitHub、Bitbucket、OSChina等国内外常用的代码托管服务对接，采用一些触发式的机制，微服务代码发生变化的时候，自动生成可部署的镜像。
部署
微服务由于组件数量众多，云端部署成为实践上的一个难点。灵雀云以容器为应用发布的载体，用户不必指定传统部署方式中繁琐的步骤，只需提供容器镜像和简单的容器配置，平台会将整个部署流程自动化。灵雀云与docker-compose兼容，实现对于由多个微服务容器组成的完整应用的一键部署。
运维
微服务由于独立进程众多，部署后的运维、管理成为实践上的另一个难点。灵雀云完全屏蔽底层云主机和基础架构运维，让用户专注于应用。同时，灵雀云通过容器编排、自动修复、自动扩展、监控日志等高级应用生命周期服务，实现容器化微服务的智能托管，进一步帮助用户降低运维成本和难度。
网络
微服务架构下各组件之间的沟通、协调对网络有较高要求，尤其在云端实践中，各个微服务组件的物理位置是动态的，且不受应用控制。灵雀云提供完整的容器网络解决方案，支持负载均衡、服务发现、跨主机关联，以及应用安全内网来确保微服务对内、对外网络的可用性及安全性。
存储
微服务提倡多元化存储（Polyglot Persistence），应用内的每个微服务可根据实际需求选择最合适的数据服务。灵雀云将持久性云存储抽象成数据卷，可以直接挂载在容器上，并在容器重启、迁移中自动重新挂载。可支持任意容器化数据服务，供微服务应用集成。同时，支持对微服务数据的备份，恢复，和下载，可以利用备份随时恢复数据。
镜像中心
灵雀云的镜像中心是一个容器化微服务的市场和共享的平台，汇集了大量来自于社区和第三方的镜像。用户可以自由组合、复用数以万计的容器化微服务，像搭积木一样轻松集成应用。
演讲人简介：陈恺，华盛顿大学计算机科学专业硕士。2004年加入微软从事Windows操作系统内核（Kernel）研发。 2010年加入微软当时全新的云平台（WindowsAzure），出任首席架构师/软件开发经理，此后专注于云计算/分布式系统的研发。作为微软云计算技术骨干及核心管理人员，陈恺组建、带领团队开发Azure最核心的中控系统（Fabric Controller），管理并支撑整个云平台后端，承载千万级规模应用。2015年陈恺正式加盟灵雀云创业团队，任首席技术官。
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
