UDN-企业互联网技术人气社区

板块导航

浏览  : 1277
回复  : 0

[Docker资讯] AWS 云计算环境中的微服务架构

[复制链接]
白青青的头像 楼主
发表于 2016-5-26 11:08:09 | 显示全部楼层 |阅读模式
  • 微服务不是石头缝里面蹦出来的,是基于类似SOA、Blackboard、C/S等应用架构基础上,并融合敏捷开发、DevOps等理念的基础上发展而来
  • 微服务相比传统应用优点明显(快速部署、去中心、良好的隔离性等),缺点也不少(更复杂、通信损耗、测试成本高)
  • 微服务不仅仅是一种新型的应用设计方法,使用这种架构的企业的组织架构可能也需要作出适当调整
  • AWS针对微服务设计了ECS(基于EC2的容器服务)、Lambda(基于事件驱动的计算平台,开发人员只要编写JavaScript或java逻辑就行,lambda负责执行工作,类似HPC的执行模式)
  • 原来AWS的ElasticBeanstalk就已经在底层使用Docker来进行应用环境交付了,只是限定更加多(需要指定语言平台,如java、php、.net等)而ECS则没有这么多要求。EB好比GAE而ECS更像EC2

  关于微服务(Microservices)

  2.1 为什么需要微服务

  原有3层的应用架构(表现层、逻辑层、持久层–数据层)每个大层面的应用程序都有大量逻辑进行包裹,因此开发、维护和管理起来非常费时费力,且由于开发周期长都存需求落后风险
2.png

  而微服务的开发模式不同,它的思路是将每个大层面的应用,再次分解,将每个相对独立的小模块都变成一个独立的程序(所谓一个小的服务)每个服务都的独立运行在进程中,独立部署,每个服务之间通过轻量级的方式进行交互,例如http API。不同的服务可以不同的开发语言,数据存储保存机制。这样就可以敏捷的开发和维护应用,时间周期也变得非常短
2.png

  2.2 为什么微服务会出现?

  技术发展带来的复杂性,开发时间上的开销,大环境所承担的各种风险,相关理念与开发思想(如敏捷开发)共同推波助澜的结果

  微服务是以历史上存在的、流行过的编程架构为基石的,而非石头缝里蹦出来的,这些架构包括:

  • Blackboard架构:背后的理念是,一系列独立的程序携手合作,致力于处理同一个数据结构
  • Client/Server架构:客户机和服务器结构。它是软件系统体系结构,通过它可以充分利用两端硬件环境的优势,将任务合理分配到Client端和Server端来实现
  • Component Based架构:在组件对象模型的支持下,通过复用已有的构件,软件开发者可以“即插即用”地快速构造应用软件
  • Peer-To-Peer架构:不同于主从式架构,网络上的每个使用端或程式的实体都拥有相同的等级,同时扮演用户端与服务器的角色。
  • Service Oriented 架构:大名鼎鼎的SOA架构,是构造分布式计算的应用程序的方法。它将应用程序功能作为服务发送给最终用户或者其他服务。
  • 另一方面,微服务不仅传承了各种应用架构,而且受到众多软件设计领域的思想的影响,比如:
  • 领域设计驱动(分析模型化的复杂业务)
  • 敏捷方法(提升效率减少浪费)
  • 持续交付(更快、更可靠、更频繁的应用部署)
  • 虚拟化和IaaS(简化基础架构环境)
  • DevOps(让团队更加小巧)

  2.3 微服务的特征

  • 小:每个服务只做一件事情,并且目标是把事情做好、做极致 。例如业内有些人的甚至用代码尺寸衡量(例如100行、1000行以内的代码)。
  • 运行在独立的进程中:不同的服务可以运行在不同的主机之上
  • 轻量级通信机制:指的是服务和服务之间,通过轻量级的通信机制,进行沟通(轻,是指通信跟语言和平台无关,例如json、xml等)。而相反的传统重量级通信机制比如(.net remoting或java rmi)
  • 松耦合:不需要改变依赖,只需要改变当前服务本身,并独立部署。这意味着该服务的部署和运行,和其他服务之间呈现独立的姿态

  2.4 微服务的优缺点

  优点:

  • 良好的隔离性和可用性,场景:某一个服务的故障,并不会影响到其他无关的服务
  • 独立交付速度大大提高,场景:现在强调的持续部署、持续开发对交付速度有很高要求,Microservices可以做到。而传统的Monolithic一体化应用部署的交付速度提升非常难,对基础架构、对环境、对应用测试的要求高,很难做到
  • 去中心化的管理,场景:在管理部署传统应用的时候,都有部署一个打包的应用、有一个关键核心应用,就是是一个中心点。而Microservices并没有一个中心,因此可以在运维过程中各团队可以针对部件独立部署,DevOps ,降低风险

  缺点:

  • 复杂性,Microservice本质上是分布式,而分布式系统本身存在复杂性,需要开发、测试和运维人员等都需要有处理复杂系统的经验
  • 服务的操作开销,Microservice因为有很多服务,相比传统架构有很多服务间通讯的开销,因此在效率上不如传统Monolithic。并且一般都需要遵循DevOps进行管理模式和流程。
  • 服务接口不匹配后的问题?虽然Microservice使用标准化接口,但由于服务多而且不同服务的接口存在版本,一旦某服务版本失去了控制,或与其他服务通讯的匹配,则会出现不可控的风险
  • 测试,相比传统应用架构,每次发布版本,都需要整个生态系统测试,因此整体测试时间更长更复杂
  • 扇形增加的需求数,主要原因是随着服务的增加,数据流量就会大幅度增加

  微服务设计

  3.1 康威定律 Conway’s Law(应用架构对组织架构有要求)
2.png

  任何设计系统的组织……必然会产生以下设计结果,即其结构就是该组织沟通结构的写照

  —-翻译—–

  有什么样的组织架构,就有什么样的软件产品。用传统的组织架构去开发Microservice就会出问题

  3.2 传统应用组织架构(SILOs)
2.png

  传企业应用架构如下:

  • 产品团队
  • 用户交互体验
  • 开发团队
  • 测试团队
  • 数据库团队
  • 系统管理
  • 网络管理
  • 存储管理等

  传统应用架构采用一体化(Monolithic)应用使用这种模式是比较好的,但是Microservice使用这种架构会有问题(因为每个服务都可能存在需要搭配这样的班子的情况),而这种组织架构下,信息在团队间沟通成本是非常大的

  3.3 针对Microservice,组织需要作出调整(DevOps)
2.png

  调整方法:针对Microservice的各个service建立一个个敏捷小型的高效团队,每个小型团队针对每个服务(贯穿于整个应用的各个服务模块)负责,独立进行相应的开发与管理工作
2.png

  Microservice的架构跟DevOps有密切的关联,Microservice是DevOps思想逐步演化的结果,而DevOps也是实现Microservice最好的工具

  3.4 如何设计 smaller(真正的小) 的服务

  推荐一本书:Building Microservice
2.png


  将服务做小的关键点总结:

  • 每个服务要关注“业务”领域,每个服务解决一个具体问题
  • 结构上呈现“松散、耦合”架构,便于后期部署、测试、调试
  • “有边界”的上下文,并不需要每个服务周边的部分—其他服务、依赖服务等,团队只关注服务本身和服务的API;传统应用的需求分析需要对全局需求有了解并设计后才能开发,而微服务可以更快让团队开始
  • 每个服务都可以独立部署
  • 需要配套思想对应的工具(如DevOps的工具等)
  • 鼓励大家使用新技术(建议:伯斯塔尔法则,做的时候要保守,接受的时候要开放)
  • 自动化的文化
  • 能在两周内重写的东西(衡量Microservice的服务小的标准)
  • 两张披萨团队(亚马逊内部思路,一个灵活敏捷的团队应该控制在10个人左右)
2.png

  3.5 Microservice的实践- Netflix IPC Stack
2.png

  ★Netflix IPC Stack 1.0

  Netflix内部的一个应用,1.0采用传统的SILOs风格的应用,不符合Microservice的设计风格
2.png

  ★Netflix IPC Stack 2.0

  Netflix 在 IPC Stack 2.0开始抽象出了比较粗的服务,并独立部署在彼此隔离的容器中,且通过HTTP API进行交互

  Microservice的相关技术与云服务

  4.1 容器计算技术
2.png

  传统虚拟机(拥有hypervisor)会存在性能损耗,而Docker采用LXC技术取消了hypervisor,直接使用Linux Kernel,提升了性能。而Docker的这种快速部署和管理能力,正好和Microservice的服务快速部署吻合

  4.2 AWS上的Docker运行模式有3种

  • EC2(直接使用EC2服务中内置了Docker能力的AMI启动实例来使用Docker)
  • AWS Elastic BeanStalk(利用Docker技术进行封装,来自动部署弹性web应用和服务架构的托管类应用,可支持php、java、.net等语言环境)
  • EC2 Container Service(提供针对Docker容器的可视化、流水线式的管理能力)

  4.3 EC2 Container Service

  ECS的关键组件

  • 机群(Container Cluster)
  • - 区分区域
  • - 相当于资源池
  • - 相当于容器实例的分组
  • - 启动时为空、动态扩容与调整
  • 容器实例(运行容器的EC2实例)
  • - 包含一个EC2实例
  • - 在实例中存在一个Docker进程
  • - 在实例中存在一个 ECS的代理(Agent是开源的,用goLang开发)

2.png

  • 任务(就是一个个Docker 容器)
  • - 每个实例可以设置多个任务
  • - 任务是作业的单位
  • - 允许任务分组和设置关联
  • - 任务运行在EC2实例中
  • 任务 定义
  • - 通过json来定义任务
  • - 包括:Docker hub模板、cpu数量、内存等

2.png

  • 任务 调度(实现计算资源的管理)
  • - 长期运行的服务(Long-running services)
  • - 批量执行任务(RunTask for bach jobs)
  • - 集成第三方调度器schedulers

  4.4 Microservice的实践- Coursera(使用了ECS)

  4.4.1 一个mooc网站
2.png

  4.4.2 Coursera的需求

  之前Coursera开发了一套传统的互联网应用架构,有很多程序单元,而每一个单元里面有很多服务(粒度很粗),主要的需求是

  • 可靠性:因为服务的人员比较多,所以如果应用宕机则对公司声誉2.影响大
  • 更容易开发:互联网公司生存压力,需要快速上线更多应用满足客户需求,另一方面,小并且公式化的开发模式是必须的
  • 更快部署
  • 成本的考虑:希望投入产出比更高
  • 更高效的运维:只有1个运维人员,现有环境维护太复杂

2.png

  4.4.3 Coursera的选择之路

  Coursera尝试了很多方法,最后不希望自己运维和折腾了,所以选择了ECS

  • 自己的现有技术
  • - 尝试过,但是不可靠
  • - 操作困难
  • MESOS
  • - 非常强大,实际操作过程中易用性差
  • - 需要一直与之匹配的DevOps团队
  • Kubernetes
  • - 在GCE上表现的很好,其他地方就不行了(而GCE是google的IaaS平台)
  • 使用ECS
  • - 维护成本几乎为0
  • - Coursera已经使用了AWS的服务,如IAM等希望继续沿用
  • - 开发人员更好理解和操作(Docker本身还是主机不用改变语言开发方式),学习成本低

  4.4.4 最终Coursera改造后的Microservice架构

  • 大量的使用ECS的work部署Microservice中的service
  • 前端+调度器 设计
  • 生成的请求(通过API调用 或 内部通信都通过scheduler来分配)
  • 新请求保存在 SQS 队列中
  • 根据来自其他服务的状态 而 处理请求
  • 后端设计
  • 试图通过ECS 的API 来运行task(不是通过界面操作,更快更及时)
  • 如果任务失败,则任务自动回滚到队列中,之后重试
  • 保持任务状态的跟踪,并更新 Cassandra数据库(一种NoSQL数据库)

2.png

  4.5 AWS的Lambda(托管的、事件驱动架构的计算平台服务)

  特点:

  • 零管理:是一个计算平台而不是一个windows或linux,因此不需要过多的管理环境相关的东西(例如多少cpu、内存、带宽等)
  • 事件驱动:基于事件产生对代码块的自动调用
  • 计算平台:对于开发人员来讲,就是一个计算平台,提交代码然后等待结果即可
  • 用户可以专注业务逻辑而不是基础架构:用户针对业务进行服务开发(可以使用JavaScript、java等)并设定好触发机制上传代码,而AWS Lambda负责后续的工作,如容量、扩展、部署、容错、监控、日志等
  • 自动化扩展:用户仅仅负担所使用的费用,不会超过/低于资源调配
  • 细粒度的定价:价格计量单位是毫秒(单位是100ms)对于短时间任务非常有价值,没有最低消费,可以免费试用
  • 事件以不同的形态和尺寸发生:S3事件通知、DynamoDB Streams事件、Kinesis(事件流)事件、定制化事件
  • 同步异步都可调用:针对不同的业务场景可以选择同步异步模式调用,如某些应用日志产生问题后异步响应触发lambda调用。或定制实践发生后同步触发lambda调用

2.png

  基础架构的扩展性、利用率情况
2.png

  4.6 Microservice的实践-AWS Lambda使用方法示例

  4.6.1 一个内容管理系统(CMS)

  具体需求包括:

  - 允许用户上传头像

  - 需要将图片保存

  - 需要为头像制作缩略图,在不同的web位置使用

  4.6.2 传统情况

  一个CMS应用搞定所有工作,涉及的流程包括:上传头像→保存图片→将图片生成缩略图

  传统情况下修改任意环节(如保存图片)则需要将CMS系统重新打包然后更新

  4.6.2 Lambda改造情况

  用户上传图片到S3中,一个新的S3对象将触发lambda函数来转换成缩略图,将缩略图保存到S3的另外一个bucket

  另一方面将元数据保存到DynamoDB中,当一个新的保存条目后触发一个创建ECS的task的事件去执行其他操作(如生成GIF图)
2.png


原文作者:邱洋 来源:架构师联盟

相关帖子

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部