码迷,mamicode.com
首页 > 其他好文 > 详细

【总结】AWS 云计算环境中的Microservices(微服务)架构

时间:2016-05-05 02:08:12      阅读:387      评论:0      收藏:0      [点我收藏+]

标签:

下载地址:下载完整MP4文件

1.邱洋总结

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

2.关于微服务(Microservices)

2.1为什么需要微服务

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

技术分享

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

技术分享

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.微服务设计

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

技术分享

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

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

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

技术分享
传企业应用架构如下:
- 产品团队
- 用户交互体验
- 开发团队
- 测试团队
- 数据库团队
- 系统管理
- 网络管理
- 存储管理等

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

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

技术分享

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

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

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

推荐一本书:Building Microservice

技术分享

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

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

技术分享

3.5 Microservice的实践- Netflix IPC Stack

技术分享
★Netflix IPC Stack 1.0
Netflix内部的一个应用,1.0采用传统的SILOs风格的应用,不符合Microservice的设计风格

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

4. Microservice的相关技术与云服务

4.1 容器计算技术

技术分享

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

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

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

4.3 EC2 Container Service

ECS的关键组件

1、机群(Container Cluster)
- 区分区域
- 相当于资源池
- 相当于容器实例的分组
- 启动时为空、动态扩容与调整

2、容器实例(运行容器的EC2实例)
- 包含一个EC2实例
- 在实例中存在一个Docker进程
- 在实例中存在一个 ECS的代理(Agent是开源的,用goLang开发)
技术分享

3、任务(就是一个个docker 容器)
- 每个实例可以设置多个任务
- 任务是作业的单位
- 允许任务分组和设置关联
- 任务运行在EC2实例中

4、任务 定义
- 通过json来定义任务
- 包括:docker hub模板、cpu数量、内存等
技术分享

技术分享

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

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

4.4.1 一个mooc网站

技术分享

4.4.2 Coursera的需求

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

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

4.4.3 Coursera的选择之路

Coursera尝试了很多方法,最后不希望自己运维和折腾了,所以选择了ECS
1.自己的现有技术
- 尝试过,但是不可靠
- 操作困难

2.MESOS
- 非常强大,实际操作过程中易用性差
- 需要一直与之匹配的DevOps团队

3.Kubernetes
- 在GCE上表现的很好,其他地方就不行了(而GCE是一个需要调整用户应用的PaaS ,有学习成本)

4.使用ECS
- 维护成本几乎为0
- Coursera已经使用了AWS的服务,如IAM等希望继续沿用
- 开发人员更好理解和操作(docker本身还是主机不用改变语言开发方式),学习成本低

4.4.4 最终Coursera改造后的Microservice架构

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

技术分享

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

特点:

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

技术分享

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

资源种类 扩展性 利用率
企业自有IDC 周级
Amazon EC2 分钟级
Container 较高
AWS Lambda 毫秒 最高

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图)

技术分享

【总结】AWS 云计算环境中的Microservices(微服务)架构

标签:

原文地址:http://blog.csdn.net/qxk2001/article/details/51319210

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!