【总结】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࿰