DaoCloud的微服务架构演化实践

Docker的蓬勃发展为我们带来了很多机遇,国内外诸多云服务的提供者皆投身其中。与此同时,这也促使我们要有更深刻地思考,到底如何将Docker落地,才能为用户提供更优质的服务。DaoCloud就是这次大潮中的弄潮儿,他们在提供持续部署、微服务支持的过程中,通过不断演化架构,解决了所遇到的各种难题。DaoCloud联合创始人、研发副总裁郭峰将在8月29日的CNUTCon全球容器技术大会上,分享题为《分布式平台微服务架构演化实践》的演讲,敬请关注。

嘉宾简介

郭峰,CNUTCon讲师,DaoCloud联合创始人兼研发副总裁。他2007年毕业于同济大学获计算机科学硕士,同年夏天作为第一批员工加入EMC中国研发中心。曾担任EMC中国研究院云平台的主任工程师,也是中国最早接触Cloud Foundry、OpenStack及Docker的技术人员,在开源社区拥有很高的声誉。郭峰拥有20多项美国专利申请,专长于云平台及服务构建、分布式系统、虚拟化技术、企业应用及数据平台化,曾参与Spring框架项目开发,是一名业内顶尖的应用架构专家。

InfoQ:持续交付一直是敏捷的终极目标,DaoCloud的官网也提出了这样的口号:『让应用交付更便捷』,你们是如何面对不同的行业和技术栈,实现更便捷的交付的?

郭峰:提高用户的持续交付能力,DaoCloud拥有两大法宝,Docker容器技术和最佳实践的自动化。以Docker为代表的容器技术自2013年起在IT领域迅猛发展,Docker之所以受到巨大的关注一个重要的原因就是Docker不仅仅是一个容器技术,它还提出了应用的统一交付——Docker镜像。

基于Docker镜像交付的应用,可以跨平台、无差别运行,这一点为持续交付奠定了重要基础。之前企业实施CI/CD很难,尤其是在应用微服务化的大背景下,企业应用是由很多个服务组件组成的,由不同开发部门开发的服务组件使用的技术框架都各不相同,对测试部署环境的要求也千差万别,这种差异性使得持续交付流程必须对各个服务组件提供专门的集成,这样不可避免造成实施持续交付非常难,需要企业持续的投入。当我们的应用的交付方式都是容器镜像,运行方式都是容器,那我们就很容易的在多样化的应用组件中找到统一点,持续交付流程中针对不同技术栈的多条羊肠小道,都归结到仅面向Docker容器的康庄大道。

不同行业的应用,虽然它们解决的问题、所处的领域都不一样,但是应用的开发测试发布流程却差别不大。DaoCloud便捷交付的一个关键是在于帮助用户实现“Code to Cloud”全流程自动化,包括代码托管、镜像构建、测试、版本控制、部署到云端等。这样一来,开发者能够把精力集中在核心的代码编写层面,从而实现更快速、便捷地交付应用。InfoQ:相对于传统的GAE式的服务,容器云有什么样的优势?

郭峰:在DaoCloud之前,我在PaaS领域工作了很多年,当时遇到的最头疼的两个问题,一是为了上云,用户的应用实现需要做适配;二是出现问题,帮用户定位问题很困难。第一个问题是因为缺乏统一标准,各个云对应用的要求不一样,在本地可以跑的应用在云上不能跑,在一个云上能跑的应用在另外一个云上不能跑,这无疑会提高用户应用上云的门槛。第二个问题是PaaS平台要承载各种不同语言不同框架编写的应用,一旦用户的应用在你的平台起不来或者出现问题,虽然绝大部分问题都是应用自己的问题导致的,但是你不得不深入应用实现去帮助用户定位问题,这对云应用的管理维护带来了巨大挑战。 基于容器的应用云平台从根本上解决了这两大难题,容器的跨平台无差别运行的特性使得只要用户的应用容器在本地可以跑,调度到云端后肯定可以跑,而且跑出来的应用行为是一致的。这样,应用上云不需要做适配,本地可以跑,无需修改轻松云化,而且PaaS平台不需要在关心应用实现细节,仅需对容器负责,用户和PaaS云平台的接口被统一到了容器上。

InfoQ:你们在自动化运维领域有哪些实践?

郭峰:随着DaoCloud平台规模的扩大以及提供服务的多样化,我们的部署规模已经由初期的几台服务器发展到了横跨4个数据中心的大规模混合云部署,这对IT运维管理,实施质量和响应速度都提出了很高的要求,传统的人工运维方式不仅运维质量不能保证,而且响应时间也不能满足平台动态弹性需求。
尤其是作为一个初创企业,人少事多不可避免,这也倒逼我们仅有的半个运维人员(一半时间是开发)摸索了一套标准化,自动化运维流程。首先,DaoCloud平台是有超过40 个微服务组成的,各个服务所使用的编程语言和技术框架各有不同,为了从各个语言的差异性中解脱出来,我们要求所有的DaoCloud平台组件都是Docker化部署的,组件的开发人员的职责延伸到组件整个生命周期,开发人员不仅要对代码负责,还要提供一整套支撑组件运行的配置,包括容器镜像,Docker Compose 描述文件等,这样运维能力仅需要围绕容器生命周期管理进行。其次,平台弹性扩展过程完全自动化,对于一个云平台,平台的弹性扩展是平台运维的最常见的任务之一,扩展自动化不仅能够更快响应弹性需求而且还减少了人为操作失误的可能性,当然这个也对云平台的实现提出了挑战,支持弹性的组件以及其他相关组件,要支持服务注册和自发现。

InfoQ:对于部署在DaoCloud上的应用,是如何得到安全保障的,DaoCloud提供了哪些监控手段?

郭峰:首先,容器技术本身就会对现有应用的安全性起到一定的增强,在容器中运行的应用拥有完全独立的进程树,文件系统以及命名空间,再加上容器使用资源的限制,使得应用容器间互相影响的可能性降到最低。其次,在网络层面我们还采用了白名单安全策略,仅平台允许的访问请求才会被分发到应用容器中,同时容器间的访问也是被严格限制的。最后,为了应对公有云上的各种恶意应用,平台会实时监控容器的运行状态,一旦发现可疑应用容器,就会触发自动化应对策略,谨防恶意应用影响其他用户应用容器。

InfoQ:分布式的应用,如何在DaoCloud上得到统一的日志服务?

郭峰:应用日志是检查应用状态,排查问题的重要依据,提供应用日志是应用云平台必须要提供的一个功能,同时也是一个很大的挑战,尤其是面对一个分布式应用,应用由多个容器组成,容器分布在不同的部署节点上,我们不仅要保持log的实时性还要高效准确的归集属于相同应用不同容器产生的日志。我们的做法是所有容器的日志通过标准化的 syslog 协议发送至一个专门的日志收集组件,这个组件能够高效分析处理日志元信息,根据应用对日志做归集并添加必要元信息,再存放在支持高速查询的日志存储系统中。当用户查看应用日志时,通过日志存储系统查询应用日志,从而实现高效统一的日志服务。

InfoQ:对于部署在DaoCloud上的应用,是如何得到伸缩性支持的,是否有良好的容错机制?相比Mesos,DaoCloud有哪些实践?

郭峰: DaoCloud的开发团队中有不少成员,包括我个人,都有丰富的云平台架构设计相关经验,DaoCloud平台从设计的第一天就考虑了对应用伸缩性的支持,不仅能做到便捷的不终止服务前提下的应用弹性伸缩,还在应用容器放置策略上考虑了很周详的容错机制,把应用当机的可能性降到最低。首先,容器放置策略上,我们尽量把应用的不同容器放置在不同的可用区中,相同可用区中的容器也尽量分布在不同的部署节点上,这样当某个意外发生时,把应用受影响的容器控制在一定范围内,保证了应用不当机。同时,我们还实时监控应用的容器状态,当发现容器状态和期望的不一致,自动触发应对策略,保证应用容器按照计划运行。

InfoQ:你们是如何解决Docker在网络资源隔离和安全上的不足的?

郭峰:我们在平台层,对Docker做了不少补充,一方面,在网络层面我们采用了白名单安全策略,仅平台允许的访问请求才会被分发到应用容器中,同时容器间的访问也是被严格限制的;另外一方面,我们对容器使用资源进行了更全面的实时监控,尤其是对目前Docker本身不能限制的部分资源,做到发现异常自动应对。

时间: 2024-11-03 10:16:21

DaoCloud的微服务架构演化实践的相关文章

从 Spring Cloud 开始,聊聊微服务架构实践之路

本文讲的是从 Spring Cloud 开始,聊聊微服务架构实践之路[编者的话]随着公司业务量的飞速发展,平台面临的挑战已经远远大于业务,需求量不断增加,技术人员数量增加,面临的复杂度也大大增加.在这个背景下,平台的技术架构也完成了从传统的单体应用到微服务化的演进. 系统架构的演进过程 单一应用架构(第一代架构) 这是平台最开始的情况,当时流量小,为了节约成本,并将所有应用都打包放到一个应用里面,采用的架构为 .NET SQL Server: 表示层:位于最外层(最上层),最接近用户.用于显示数

Martin Fowler竟然不是第一个提出微服务架构概念的?

王磊:前ThoughtWorks首席咨询师,<微服务架构与实践>作者,翻译有<DevOps Handbook>,国内较早倡导和实践微服务的先行者,有丰富的微服务/DevOps/持续交付实战经验 微服务架构那点事 相信很多朋友了解微服务架构都是从Martin Fowler的那篇文章开始.而实际上,Martin却并不是最早谈及微服务架构的,本篇文章就和你聊聊微服务架构定义的那点事. 最易懂的版本 Martin Fowler的这篇文章<Microservices>通俗易懂的讲

成小胖学习微服务架构·基础篇

看到最近"微服务架构"这个概念这么火,作为一个积极上进的程序猿,成小胖忍不住想要学习学习.而架构师老王(不是隔壁老王)最近刚好在做公司基础服务的微服务化研究和落地,对此深有研究. 于是成小胖马上屁颠屁颠的跑过去向老王请教:"王哥,我看微服务架构这么火,我也想学,您给我讲讲啥是微服务架构呗?" 老王笑了笑说:"要想知道什么是微服务架构,你得先知道什么系统架构设计." 成小胖的理想是成为一名架构师,平时积累了不少知识,因此对"系统架构设计&

InfoQ采访PWorld2015讲师:解读“微服务”架构

经历过去的十几年的发展,SOA(Service-Oriented Architecture)已经获得了广泛肯定与应用.现在,随着云计算.开源.Docker等为技术界带来革命性的影响,同时,用户使用方式与生活方式都在移动化浪潮的裹挟下发生了巨变,"微服务"架构(MSA:Micro Service Architecture)这一全新的企业架构模式越来越受到关注,也有越来越多的企业和平台服务商开始将"微服务"的概念转化为实践,掌握到第一手的实战经验.应该如何理解"

七牛容器SDN技术与微服务架构实践

     Docker的横空出世很大程度上推动了容器技术的热度和发展.容器技术和传统的虚拟化技术有很大的不同,具体包括:首先是相对于传统的虚拟机,以前一个虚拟机里做的事情,要打散成很多个容器去做,它们各自的职能会更少:第二点是会造成以前一个虚机的IP会变成很多个容器的多个IP,容器之间的关系会变得更加复杂:第三点是整个网络中的网络端点数量呈现一个上升的趋势:第四点是容器的生命周期其实会更短.此外,容器由于其轻量级的优势,可能会被不停地调度,从一台机器调度到另外一台机器,根据资源的负载均衡,容器的

视觉中国:基于容器云的同城双活微服务架构上云实践

本文正在参加"最佳上云实践"评选,来给我们投票吧:https://yq.aliyun.com/activity/158(编号7) 视觉中国集团(Visual China Group)创立于2000年6月,是中国领先的视觉影像产品和服务提供商.视觉中国集团是以"视觉创造价值,视觉服务中国"为愿景的A股唯一互联网文化创意上市公司(股票代号000681,股票简称:视觉中国).视觉中国集团以"视觉内容与服务"."视觉社区"和"

微服务实践(七):从单体式架构迁移到微服务架构

本文讲的是微服务实践(七):从单体式架构迁移到微服务架构,[编者的话]这是用微服务开发应用系列博客的第七篇也是最后一篇.第一篇中介绍了微服务架构模式,并且讨论了微服架构的优缺点:接续文章讨论了微服务架构不同方面:使用API网关,进程间通信,服务发现,事件驱动数据管理以及部署微服务.本篇,我们将探讨将应用从单体式架构迁移到微服务架构需要考虑的策略. 希望读者通过本系列文章对微服务优缺点有一个比较好的理解,以及何时使用这种架构.也许微服务架构比较适合你的应用.也许你正在开发一个大型.复杂单体式应用,

品高公开课 | 基于Docker容器的微服务架构实践

小编的话 "品高公开课"系列文章意在分享技术牛人的知识干货,每期主题都不一样哟!期待各位读者在文后发表留言,来一场技术上的交流和思想上的碰撞! 微服务以一种全新的架构设计模式,牵动了互联网应用从设计到运维整个流程方法论的变革. 而以Docker为代表的容器技术则为微服务理念提供了匹配的实现机制.本周五,将由品高软件工程师陈洪杰带讲述微服务架构的故事. 分享嘉宾 陈洪杰,目前就任品高广州云架构产品部--BingoCloud平台的软件开发工程师,拥有Docker,LXC等多个容器平台的项目

微服务架构的理论基础 - 康威定律

概述 关于微服务的介绍,可以参考微服务那点事. 微服务是最近非常火热的新概念,大家都在追,也都觉得很对,但是似乎没有很充足的理论基础说明这是正确的,给人的感觉是 不明觉厉 .前段时间看了Mike Amundsen <远距离条件下的康威定律--分布式世界中实现团队构建>(是Design RESTful API的作者)在InfoQ上的一个分享,觉得很有帮助,结合自己的一些思考,整理了该演讲的内容. 可能出乎很多人意料之外的一个事实是,微服务很多核心理念其实在半个世纪前的一篇文章中就被阐述过了,而且