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

下载地址：下载完整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

• 购买地址：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进行交互

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是google的IaaS平台）

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调用

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

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