深解微服务架构:从过去,到未来|架构(2015-07-15)

随着用户需求个性化、产品生命周期变短,微服务架构是未来软件软件架构朝着灵活性、扩展性、伸缩性以及高可用性发展的必然方向。同时,以Docker为代表的容器虚拟化技术的盛行,将大大降低微服务实施的成本,为微服务落地以及大规模使用提供了坚实的基础和保障。

微服务的诞生

 

微服务架构(Microservice Architect)是一种架构模式,它提倡将单块架构的应用划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通。每个服务都围绕着具体业务进行构建,并且能够被独立的部署到生产环境、类生产环境等。

微服务架构虽然诞生的时间并不长,但其在各种演讲、文章、书籍上所出现的频率已经让很多人意识到它对软件架构领域所带来的影响。

其实,微服务的诞生并非偶然。它是互联网高速发展,敏捷、精益、持续交付方法论的深入人心,虚拟化技术与DevOps文化的快速发展以及传统单块架构无法适应快速变化等多重因素的推动下所诞生的产物:

 

背景1 :互联网行业的快速发展

 

过去的十年中,互联网对我们的生活产生了翻天覆地的变化。购物、打车、订餐、支付,甚至美甲、洗车等,想到的,想不到的活动都可以通过互联网完成,越来越多的传统行业公司也开始依赖互联网技术打造其核心竞争优势。互联网时代的产品通常有两类特点:需求变化快和用户群体庞大。在这种情况下,如何从系统架构的角度出发,构建灵活、易扩展的系统,快速应对需求的变化;同时,随着用户量的增加,如何保证系统的可伸缩性、高可用性,成为系统架构面临的挑战。

背景2 : 敏捷、精益方法论的深入人心

 

纵观IT行业过去的十年,敏捷、精益、持续交付等价值观、方法论的提出以及实践,让很多组织意识到应变市场变化、提高响应力的重要性。精益创业(Lean Startup)帮助组织分析并建立最小可实行产品(Minimum Viable Product),通过迭代持续改进;敏捷方法帮助组织消除浪费,通过反馈不断找到正确的方向;持续交付帮助组织构建更快、更可靠、可频繁发布的交付机制。经过这些方法论以及实践的推行和尝试后,从宏观上而言,大部分组织已经基本上形成了一套可遵循、可参考、可实施的交付体系。这时候,逐渐完善并改进各个细节的需求就会更加强烈。所谓细节,就是类似如何找到灵活性高、扩展性好的架构方式、如何用更有效的技术、工具解决业务问题等。

背景3 : 虚拟化技术与DevOps文化的快速发展

虚拟化技术和基础设施自动化(Infrastructure As Code)的快速发展极大的简化了基础设施的创建、配置以及系统的安装和部署。譬如云平台的成熟以及像Chef、Puppet、Ansible等工具的使用,让更多的基础设施能够通过自动化的方式动态创建。同时,容器化技术的发展以及Docker的出现,更是将虚拟化技术推向了一个史无前例的高潮。另外,DevOps文化的推行打破了传统开发与运维之间的壁垒,帮助组织形成更高效的、开发与运维高度协作的交付团队。这些技术与文化的快速发展,极大程度上解决了传统环境创建难、配置难以及‘最后一公里’的部署难、交付难等问题,成为推动微服务诞生、发展的重要因素之一。

背景4 : 单块架构系统面临的挑战

几年前我们熟悉的传统IT系统,也可以称之为单块架构系统,是以技术分层,譬如逻辑层、数据层等。但随着用户需求个性化、产品生命周期变短、市场需求不稳定等因素的出现,单块架构系统面临着越来越多的挑战。因此,如何找到一种更有效的、更灵活、更适应当前互联网时代需求的系统架构方式,成为大家关注的焦点。

所以说,微服务的诞生决不是偶然,是多重因素推动下的必然产物。

微服务与SOA

 

SOA简述

 

早在1996年,Gartner就提出面向服务架构(SOA)。SOA阐述了“对于复杂的企业IT系统,应按照不同的、可重用的粒度划分,将功能相关的一组功能提供者组织在一起为消费者提供服务”,其目的是为了解决企业内部不同IT资源之间无法互联而导致的信息孤岛问题。

2002年,SOA被称作"现代应用开发领域最重要的课题之一",其正在帮助企业从资源利用的角度出发,将IT资源整合成可操作的、基于标准的服务,使其能被重新组合和应用。

但是,由于SOA本身的广义性以及抽象性,在其诞生的相当长一段时间内,人们对SOA存在着不同的认知和理解。

直到2000年左右,ESB(Enterprise Service Bus)、WebService、SOAP等这类技术的出现,才使得SOA渐渐落地。同时,更多的厂商像IBM、Oracle等也分别提出基于SOA的解决方案或者产品。

微服务与SOA

实际上,微服务架构并不是一个全新的概念。仔细分析SOA的概念,就会发现,其和我们今天所谈到的微服务思想几乎一致。那在SOA诞生这么多年后,为什么又提出了微服务架构呢?

鉴于过去十几年互联网行业的高速发展,以及敏捷、持续集成、持续交付、DevOps,云技术等的深入人心,服务架构的开发、测试、部署以及监控等,相比我们提到的传统的SOA实现,已经大相径庭,主要区别如下表所示:

SOA实现 微服务架构实现

企业级,自顶向下开展实施


团队级,自底向上开展实施


服务由多个子系统组成,粒度大


一个系统被拆分成多个服务,粒度细


企业服务总线,集中式的服务架构


无集中式总线,松散的服务架构


集成方式复杂(ESB/WS/SOAP)


集成方式简单(HTTP/REST/JSON)


单块架构系统,相互依赖,部署复杂


服务都能独立部署

相比传统SOA的服务实现方式,微服务更具有灵活性、可实施性以及可扩展性,其强调的是一种独立测试、独立部署、独立运行的软件架构模式。

 

微服务架构的定义

其实,即便了解了上面的介绍,也很难对微服务下一个准确的定义。就像NoSQL,我们谈论了好几年的NoSQL,知道NoSQL代表着什么样的含义,也可以根据不同的应用场景选择不同的NoSQL数据库,但是我们还是很难对它下一个准确的定义。类似的,关于什么是‘函数式编程’,也或多或少存在同样的窘境。我们可以轻松的选择不同的函数式编程语言,可以轻松的写出函数式编程风格的代码,但很难对什么是函数式编程下一个准确的定义。

实际上,从业界的讨论来看,微服务本身并没有一个严格的定义。不过,ThoughtWorks的首席科学家,马丁 -福勒先生对微服务的这段描述,似乎更加具体、贴切,通俗易懂:

微服务架构:

微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP协议的RESTful API)。每个服务都围绕着具体业务进行构建,并且能够被独立的部署到生产环境、类生产环境等。另外,应当尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建。

总结下来,微服务架构中的核心部分包括以下几点:

小, 且专注于做一件事情;

独立的进程中;

轻量级的通信机制;

松耦合、独立部署。

总结

随着市场的快速发展,业务的不断扩大,单块架构应用面临着越来越多的挑战,其改造与重构势在必行。而微服务架构的诞生,是互联网高速发展,虚拟化技术应用以及持续交付、DevOps深入人心的综合产物。随着用户需求个性化、产品生命周期变短,微服务架构是未来软件软件架构朝着灵活性、扩展性、伸缩性以及高可用性发展的必然方向。同时,以Docker为代表的容器虚拟化技术的盛行,将大大降低微服务实施的成本,为微服务落地以及大规模使用提供了坚实的基础和保障。

来源: <http://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=208493117&idx=1&sn=afe5a4165e21f7741997303bb80242de#rd>

时间: 07-20

深解微服务架构:从过去,到未来|架构(2015-07-15)的相关文章

基于微服务API级权限的技术架构

一般而言,企业内部一套成熟的权限系统,都是基于角色(Role)的 访问控制方法(RBAC – Role Based Access Control),即权限 (Permission)与角色相关联,用户(User)通过成为适当角色的成员而得到这 些角色的权限,权限包含资源(或者与操作组合方式相结合),最终实现权限控制 的目的. 背景 权限系统是根据系统设置的安全规则或者安全策略,用户可以访问而且只能访问自己被授权的资源. 一般而言,企业内部一套成熟的权限系统,都是基于角色(Role)的访问控制方法(

京东、宅急送的微服务实践分享(下)| 架构师小组交流会

架构师小组交流会是由国内知名公司技术专家参与的技术交流会,每期选择一个时下最热门的技术话题进行实践经验分享. 第一期:来自沪江.滴滴.蘑菇街.扇贝架构师的 Docker 实践分享 第二期:来自滴滴.微博.唯品会.魅族.点评关于高可用架构的实践分享 第三期:京东.宅急送的微服务实践分享(上)第三期小组交流会邀请到了国内电商领头羊京东.宅急送技术负责人,在上篇京东.宅急送的微服务实践分享(上)中他们介绍了各自产品的微服务实践,本次他们就 API 网关的设计.服务的 Docker 化.服务测试.持续集

从单体架构迁移到微服务,8个关键的思考、实践和经验

转载本文需注明出处:EAII企业架构创新研究院(微信号:eaworld),违者必究.如需加入微信群参与微课堂.架构设计与讨论直播请直接回复此公众号:“加群 姓名 公司 职位 微信号”.   随着微服务架构的持续火热,网络上针对微服务和单体架构的讨论也是越来越多.去年的时候,社区更多的关注点是在二者的区别以及优缺点辨析上,而今年,越来越多的人开始关注如何从单体架构迁移到微服务上.毋庸置疑,微服务的理念正在席卷整个开发者社区,像Netflix.Uber这样的公司都是非常成功的应用案例. 但需要注意的

【读书笔记】微服务架构与实践

一:概述 微服务实在互联网大浪潮下顺势而起的 微服务降低了单个问题的复杂性,但是提高了整体上运维和部署的难度 二:基础篇 提出以下4个问题 神马是微服务 微服务到底怎么发展起来的? 微服务的优势在哪儿里?为什么现在大家都在谈微服务 微服务有不什么不足,或者对使用微服务说有什么挑战? 作为从业者的我们到底要怎么看待微服务,并且如何在实际的工作项目中使用它? 分别针对上面的四个问题,做出解答 什么是微服务? 微服务更像是一种架构模式,不是某种具体的技术.提倡将单一的应用划分为一组小的服务,服务之间相

微服务架构学习(1)

Gartner认为,未来企业都将是IT企业 分而治之的哲学是微服务的理论基础 把大问题分解为容易解决的小问题. 凡事都有利弊,细分为微服务后,势必带来部署,测试,信息集成难度的提高. 微服务和微应用的关系,为服务是一个技术概念,做好微服务要先做好微应用,是一个业务逻辑的问题. 站在SOA(面向服务架构 service oriented architecture )的肩膀上践行微服务 微服务不是一个全新的架构,更不是一个包治百病的架构. SOA注重系统之间通过服务互联互通的规范,对服务如何实现并不

NET实现的DDD、CQRS与微服务架构

WeText项目:一个基于.NET实现的DDD.CQRS与微服务架构的演示案例 最近出于工作需要,了解了一下微服务架构(Microservice Architecture,MSA).我经过两周业余时间的努力,凭着自己对微服务架构的理解,从无到有,基于.NET打造了一个演示微服务架构的应用程序案例,并结合领域驱动设计(DDD)以及命令查询职责分离(CQRS)体系结构模式,对事件驱动的微服务系统架构进行了一些实战性的探索.现将自己的思考和收获整理成文,分享给大家. 微服务架构 在介绍源代码之前,我还

微服务架构(Microservices)

说在前面 好久没写博文了,心里痒痒(也许是换工作后,有点时间了吧).最近好像谈论微服务的人比较多,也开始学习一下,但是都有E文,看起来半懂不懂的. Martinfowler的<微服务>,也算是入门必读了.有人翻译过,但是只有一半.还是自己练练手吧. 微服务 "微服务架构"一词在过去几年里广泛的传播,它用于描述一种独立部署的软件应用设计方式.这种架构方式并没有非常准确的定义,但是在业务能力.自动部署.端对端的整合.对语言及数据的分散控制上,却有着显著特征. "微服务

单体架构还是微服务架构,这是个问题?

(此文章同时发表在本人微信公众号"dotNET每日精华文章",欢迎右边二维码来关注.) 微服务架构现在越来越流行,那么是不是就意味着单体架构不再成为我们的选择了呢?个人认为这个要依情况而定. 现在谈及微服务架构的文章.演讲随处可见,似乎所有系统的架构都开始尽情拥抱微服务架构,包括笔者前久为一个异构电商平台系统设计的架构也选用了这种风格.然而,我们在选择微服务架构之前,一定要问一句"你现在面对的系统,微服务架构是一个好的选择吗?".当然,这个问题也是我这几天在思考的.

MicroService 微服务架构模式简述

原文是 Martin Flower 于 2014 年 3 月 25 日写的<Microservices>. 本文内容 微服务 微服务风格的特性 组件化(Componentization )与服务(Services) 围绕业务功能的组织 产品不是项目 强化终端及弱化通道 分散治理 分散数据管理 基础设施自动化 容错性设计 设计改进 微服务是未来吗 其它 微服务系统多大 微服务与SOA 多语言多选择 实践标准和强制标准 让做对事更容易 断路器circuit breaker和产品中现有的代码 同步是