广州睿东网络科技有限公司是国内最专业的香港空间,云主机,香港VPS,香港服务器租用提供商,专注为国内站长提供高速且稳定的香港空间,云主机,香港VPS,香港服务器租用,欢迎您的选购!
当前位置:首页 -> 云主机 -> 域名优惠

AWS 云计算环境中的微服务架构

云服务器 34℃ 1886评论


邱洋总结

  • 微服务不是石头缝里面蹦出来的,是基于类似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层的应用架构(表现层、逻辑层、持久层–数据层)每个大层面的应用程序都有大量逻辑进行包裹,因此开发、维护和管理起来非常费时费力,且由于开发周期长都存需求落后风险


而微服务的开发模式不同,它的思路是将每个大层面的应用,再次分解,将每个相对独立的小模块都变成一个独立的程序(所谓一个小的服务)每个服务都的独立运行在进程中,独立部署,每个服务之间通过轻量级的方式进行交互,例如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.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


  • 购买地址:AMAZON的图书

  • 书评地址:https://book.douban.com/subject/25881698/

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

  • 每个服务要关注“业务”领域,每个服务解决一个具体问题

  • 结构上呈现“松散、耦合”架构,便于后期部署、测试、调试

  • “有边界”的上下文,并不需要每个服务周边的部分—其他服务、依赖服务等,团队只关注服务本身和服务的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进行交互

Microservice的相关技术与云服务

4.1 容器计算技术


传统虚拟机(拥有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开发) 


  • 任务(就是一个个docker 容器) 

- 每个实例可以设置多个任务 

- 任务是作业的单位 

- 允许任务分组和设置关联 

- 任务运行在EC2实例中

  • 任务 定义 

- 通过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 

  • 自己的现有技术 

- 尝试过,但是不可靠 

- 操作困难

  • 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数据库)


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

特点:

  • 零管理:是一个计算平台而不是一个windows或linux,因此不需要过多的管理环境相关的东西(例如多少cpu、内存、带宽等)

  • 事件驱动:基于事件产生对代码块的自动调用

  • 计算平台:对于开发人员来讲,就是一个计算平台,提交代码然后等待结果即可

  • 用户可以专注业务逻辑而不是基础架构:用户针对业务进行服务开发(可以使用javascript、java等)并设定好触发机制上传代码,而AWS Lambda负责后续的工作,如容量、扩展、部署、容错、监控、日志等

  • 自动化扩展:用户仅仅负担所使用的费用,不会超过/低于资源调配

  • 细粒度的定价:价格计量单位是毫秒(单位是100ms)对于短时间任务非常有价值,没有最低消费,可以免费试用

  • 事件以不同的形态和尺寸发生:S3事件通知、DynamoDB Streams事件、Kinesis(事件流)事件、定制化事件

  • 同步异步都可调用:针对不同的业务场景可以选择同步异步模式调用,如某些应用日志产生问题后异步响应触发lambda调用。或定制实践发生后同步触发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图

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


进阶阅读

Stack Overflow 2016最新架构探秘

Tumblr:150亿月浏览量背后的架构挑战

在线支付之风控系统架构选型


    投诉
    喜欢 (1886)

    评论

    帐  号: 密码: (新用户注册)
    验 证 码:
    表  情:
    内  容: