【PPT分享】源创会年终盛典,基于容器云的微服务架构实践

2015 年 OSC 源创会年终盛典于12月12日在北京国际会议中心圆满结束。这是由开源中国主办的第 42 期源创会,也是第二届的开源技术年终盛典,此次活动吸引了来自超过 7000 名开发人员报名,实际到场超过 2500 人。
‌‌

13.pic_hd

 

灵雀云作为合作伙伴,组织了下午的容器与微服务技术分会场,灵雀云CEO左玥也贡献了自己的第一次主持经历。灵雀云成立于2014年10月,一直致力于为中国的技术社区和开源社区做贡献,给开源中国的用户提供了一个免费的在线演示工具,为微软的开源社提供容器技术支持,也为国内的开发者们提供了免费的镜像存储服务。

12.pic_hd

本次分会场中,讲师来自灵雀云、华为、Netflix、希云和时速云,内容包括 Docker 容器技术以及各种微服务架构,超过 400 人参与了该会场。

14.pic_hd
灵雀云产品总监成然带来了『基于容器云的微服务架构实践』的演讲。以下通过PPT分享成然的演讲内容:

microservice02

成然首先以电商网站为例,回顾了这十几年以来应用架构的演化历程:

microservice04

  • 十几年前的电商网站,逻辑、代码没有明显的区分,代码和代码之间的相互调用也是错综复杂。页面显示、用户管理、支付、配送等功能都在一起,应用的架构没有规律可寻;microservice05
  • 随着高级语言的发展,带来了很多方便的访问数据的机制,代码和数据访问相关的功能逐渐形成一个比较清晰的结构;

microservice07

  • 随着面向对象、设计模式、架构模式这些理念和方法论的不断的发展,逐渐形成了分层架构。

ms08

分层架构虽然在逻辑上有分层,但在物理部署的角度仍然是一个单块,作为一个整体进行编译、测试、部署。

单块架构有以下几个优势:

  • 便于开发:大量常用的集成开发环境(IDE)和编程框架(如Rails,Django)为开发者提供了方便和熟悉的开发、调试体验;
  • 便于测试:由于整个应用包含在一个进程中,在常用工具的配合下应用可以很容易在开发、测试环境中启动;
  • 便于部署:多数编程语言和框架都有特定的应用打包格式,部署只需将单一软件包复制到运行环境。

ms10

在项目的开始阶段,单块架构有非常方便的地方,但随着业务的拓展,单块架构很难适应快速变革的需求,遭遇一些挑战:

ms11

开发效率低:随着应用复杂度的增加,越来越少开发人员对应用能有全局性的深度理解。新功能开发和缺陷修复难度呈几何性增加。代码修改的正确性无法保障。而庞大的代码库需要更庞大的开发团队来维护,无形中又增添了管理、沟通和协调的成本。另外,新加入的团队成员需要花费大量的时间和精力来熟悉一个复杂的代码库;

ms12

交付周期长:在单一进程的单块架构下,任何微小的改动都需要重新编译、集成、测试和部署整个应用。随着应用体积的增大,交付流程和反馈周期都会相应变长,应用发布的代价也随之增加。于是应用交付周期变缓,交付间隙积累的代码变动增加,从而对于下次交付产生更大的压力,形成恶性循环;

ms13
技术转型难:单一进程、单块架构意味着中心化的技术选型。比如,应用的不同逻辑组建通常需要采用相对统一的编程语言、框架和技术栈。这些在项目初始阶段便已定型。之后,即便是应用中全新的逻辑组件,也很难采用不同的技术栈。而当应用达到一定规模后,全局化的技术栈更新会面临很高的风险。所以,单块架构应用一旦定型,就很难再享受行业技术变更、发展所带来的红利。

ms14
微服架构就是在这种情况下诞生的,它能快速响应市场需求,快速迭代、快速交互,是企业在互联网时代保持竞争力。

微服务架构(Microservices Architecture)是一种架构风格(ArchitecturalStyle)和设计模式,提倡将应用分割成一系列细小的服务,每个服务专注于单一业务功能,运行于独立的进程中,服务之间边界清晰,采用轻量级通信机制(如HTTP/REST)相互沟通、配合来实现完整的应用,满足业务和用户的需求。

相对单块架构,微服务具备以下优势:

ms17

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

ms16

  • 独立部署:由于微服务具备独立的运行进程,所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程,使得发布更加高效,同时降低对生产环境所造成的风险,最终缩短应用交付周期;
  • 容错:当某一组建发生故障时,在单一进程的传统架构下,故障很有可能在进程内扩散,形成应用全局性的不可用。在微服务架构下,故障会被隔离在单个服务中。若设计良好,其他服务可通过重试、平稳退化等机制实现应用层面的容错;

ms19

  • 技术选型灵活:微服务架构下,技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状,自由选择最适合的技术栈。由于每个微服务相对简单,当需要对技术栈进行升级时所面临的风险较低,甚至完全重构一个微服务也是可行的;

ms18

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

ms21

天下没有免费的午餐,微服架构架构归根到底是一个分布式系统,相对于单块系统,无论开发、运维都是不简单的事情。而Docker的设计初衷之一就是简化分布式系统从创建到发布,到部署、运维的整个流程。

ms22

以Docker为代表的容器技术则为微服务理念提供了匹配的实现机制,基于容器的云平台,则为容器化的微服务在云端的实践提供了很好的基础。成然以灵雀云为例,介绍了基于容器的云平台,如何为容器化微服务在云端的实现提供解决方案。

ms24

上图是灵雀云提供的服务,在左边通过持续集成、镜像构建等一系列服务,帮助用户把代码转化为可以随时随地发布的镜像;右边可以在几秒钟之内,把任意容器化的应用发布到云里面,同时提供一个高可用、高性能的容器托管环境;中间是镜像中心,把两端的服务连接起来,打通了一个容器化的应用,从开发、集成、发布、运维的流程。灵雀云可以优化这个流程,节省开发者的时间,降低创新的门槛。

ms25

灵雀云的镜像构建和持续集成服务帮助用户将独立、可复用的微服务打包,转化为随时可以部署的容器镜像。灵雀云可以和GitHub、Bitbucket、OSChina等国内外常用的代码托管服务对接,采用一些触发式的机制,微服务代码发生变化的时候,自动生成可部署的镜像。

ms26

微服务由于组件数量众多,云端部署成为实践上的一个难点。灵雀云以容器为应用发布的载体,用户不必指定传统部署方式中繁琐的步骤,只需提供容器镜像和简单的容器配置,平台会将整个部署流程自动化。

ms27

灵雀云与docker-compose兼容,实现对于由多个微服务容器组成的完整应用的一键部署。

ms28

微服务提倡多元化存储(Polyglot Persistence),应用内的每个微服务可根据实际需求选择最合适的数据服务。

灵雀云将持久性云存储抽象成数据卷,可以直接挂载在容器上,并在容器重启、迁移中自动重新挂载。可支持任意容器化数据服务,供微服务应用集成。同时,支持对微服务数据的备份,恢复,和下载,可以利用备份随时恢复数据。

ms29

微服务架构下各组件之间的沟通、协调对网络有较高要求,尤其在云端实践中,各个微服务组件的物理位置是动态的,且不受应用控制。灵雀云提供完整的容器网络解决方案,支持负载均衡、服务发现、跨主机关联,以及应用安全内网来确保微服务对内、对外网络的可用性及安全性。

ms30

灵雀云的镜像中心是一个容器化微服务的市场和共享的平台,汇集了大量来自于社区和第三方的镜像。用户可以自由组合、复用数以万计的容器化微服务,像搭积木一样轻松集成应用。

发表评论

91jufan

这个可以有!

Reply
王伟兵

看灵雀云的API文档,发现服务实例上不能用tag或label做标记?这怎么做复杂的路由/调度。

Reply
eeli

OH,GOOD BLOG.

Reply

发表评论

电子邮件地址不会被公开。 必填项已用*标注