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