微服务架构简单讲清楚(1.11-1.14)

标签: IT咨询 | 发表时间:2017-01-14 15:36 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
对于微服务架构,我前面也写了一些文章,感觉还是没有将其本质讲解的特别清楚。这几天对微服务架构进行了一些思考,并补充了一些图解,希望能把微服务架构的一些核心内容讲明白。

传统的单体应用

要讲微服务架构,一定涉及到微服务架构和传统单体应用的区别问题,先看下传统单体应用:



很多单体应用有时候也在强调是基于组件化和模块化的开始思路开发的,或者说是基于SOA架构开发,那从运行态和设计态分别来看的话可以看到。

从运行态的视角:

1. DB走HA或RAC集群,但是扩展性是大问题,很多应用后期即使走了RAC也无法解决性能问题。
2. 部署的是一个大WAR包,无法分模块独立分开部署。
3. WAR部署当前可以是物理机,也可以是虚拟机,但是WAR包偏重,很少直接部署到Docker容器的。
4. Application Server层的性能可以通过负载均衡方式进行水平扩展。

从设计态的视角:

1. DB本身是无法拆分的,各个模块的数据库,视图全在一个大的SID或Schema里面。
2. 模块之间的交互除了通过逻辑层外,还有些是直接通过DB层的跨表连接完成的。
3. 逻辑层的模块和模块之间往往是紧耦合的,相互间的调用随意,很多都是内部API或方法调用。

不管是从运行态还是设计态来看,传统的单体应用最大的问题就是各个组件和模块之间紧耦合,而这种耦合带来的问题就是扩展困难,升级和变更困难(模块间相互影响大)。

其次,传统单体应用面临的第二个问题是展现层和逻辑层的紧耦合,而实际在当前应用架构设计和开发中,可以看到需要同时满足电脑,平板,手机APP终端等多种前端展现和访问。而这种访问必须是支持分布式的接口服务访问模式。传统单体应用要做到这点也只有进行改造,比如再单独增加一个服务代理组件来发布服务。

传统单体应用到微服务架构

正是由于传统单体应用存在的一些问题,微服务架构提出了将传统单体应用打散为多个离散,自治的独立组件。这些组件你可以称呼它为微服务模块,这些微服务模块本身需要满足的就是从数据库,到逻辑层,到界面展现层都能够是独立的一套;微服务模块能够从需求,设计,开发,测试,部署上线和运维都相对独立。

这个思想本质仍然是SOA架构思想和组件化思想在业务系统内部应用的体现。基于以上思考,传统单体应用转变为微服务架构后如下图所示:




从运行态的视角:

1. 数据库在部署的时候是可物理拆分的,即不同微服务模块的数据库可以独立部署。
2. 微服务模块的应用组件包是独立部署的。
3. WAR包由于已经按模块拆分为多个,因此每个WAR包相对来说更加轻,而容易部署到类似Docker容器上。
4. 由于WAR包之间有接口交互和协同,需要增加微服务网关实现服务管理和治理。

从设计态的视角:


1. 数据库,逻辑层和界面展现在设计的时候就是完全相对独立的一套。
2. 逻辑层的各个组件之间只能通过Service API接口进行交互,微服务架构下推荐轻量Http Rest接口。
3. 逻辑层各个模块之间彻底实现松耦合。各个模块本身也更加轻量。

微服务架构的核心单元-微服务网关



在引入微服务架构后,最大的一个变化就是原来单个业务系统内部的各个模块之间需要通过分布式的服务接口进行调用和协同了,而不是简单的走内部的API调用。

那么对于复杂的各个模块间的点对点调用,就需要有一个类似ESB总线的中间件将这些接口服务统一管理起来,以实现对服务注册,安全,流控,日志审计,消息,代理和路由的统一管理。而这些转到微服务架构后即是由微服务网关来完成。

在这个意思上来看,微服务网关类似简化了的ESB,没有了ESB总线复杂的适配,协议转换,内容转换,数据映射,服务编排等功能。也可以说微服务网关是传统OSGI网关能力的进一步增强。

 

相关 [微服务 架构] 推荐:

谈微服务架构

- - 人月神话的BLOG
其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性. 从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,但是本质还是紧耦合的,这关键的一个判断标准就是如果要将原有的业务系统按照模块分开部署到不同的进程里面并完成一个完整业务系统是不可能实现的.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

面向服务与微服务架构

- - CSDN博客推荐文章
最近阅读了 Martin Fowler 和 James Lewis 合著的一篇文章  Microservices, 文中主要描述和探讨了最近流行起来的一种服务架构模式——微服务,和我最近几年工作的实践比较相关感觉深受启发. 本文吸收了部分原文观点,结合自身实践经验来探讨下服务架构模式的演化. 面向服务架构 SOA 思想概念的提出已不是什么新鲜事,大概在10年前就有不少相关书籍介绍过.

微服务架构实践感悟

- - mindwind
从去年初开始接触微服务架构的一些理念,然后到今年开始实施系统第四个大版本的架构升级决定采用这套架构理念. 最近关于微服务架构的讨论还是多起来,因为国外一些著名互联网公司(如:Amazon、Netflix 等)从实践中摸索出了一套新的大型系统架构方法论,并取得了成功,树立了很好的示范,然后这套方法论渐渐就被一些技术理论派 人士命名为微服务架构(Microservices).

微服务架构成功之路

- - CSDN博客推荐文章
本文来源于我在InfoQ中文站翻译的文章,原文地址是:http://www.infoq.com/cn/news/2015/07/success-of-microservices. 近年来,在软件开发领域关于微服务的讨论呈现出火爆的局面,有人倾向于在系统设计与开发中采用微服务方式实现软件系统的松耦合、跨部门开发;同时,反对之声也很强烈,持反对观点的人表示微服务增加了系统维护、部署的难度,导致一些功能模块或代码无法复用,同时微服务允许使用不同的语言和框架来开发各个系统模块,这又会增加系统集成与测试的难度,而且随着系统规模的日渐增长,微服务在一定程度上也会导致系统变得越来越复杂.

微服务架构-模块迁移

- - 人月神话的BLOG
对于遗留的单体应用,要进行微服务架构的改造往往比一个全新应用基于微服务架构实现更加困难. 对于单体应用的微服务架构改造,最常见的方式仍然是将低耦合的模块逐步迁出. 下面以一个采购系统中招投标模块迁出为例进一步思考单体应用的微服务架构改造步骤. 在整个模型中我们将模型进行简化,当迁出一个功能模块进行微服务化的时候,首先要考虑的就是对该模块进行集成架构分析,考虑该模块和外围的集成情况,其次才是考虑该模块内部的私有数据.

SOA和微服务架构沟通(2.8)

- - 人月神话的BLOG
今天在广州交流SOA和微服务架构,特对关键内容做简单记录. 对于SOA和微服务架构的区别,在知乎一个回答里面我已经进行了详细的说明,即微服务架构强调的第一个重点就是 业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用. 这些小应用之间通过服务完成交互和集成.

微服务下的数据架构

- - IT瘾-dev
微服务是一个软件架构模式,对微服务的讨论大多集中在容器或其他技术是否能很好的实施微服务,而本文将从以下几个角度来和大家分享在微服务架构下进行数据设计需要关注的地方,旨在帮助大家在构建微服务架构时,提供一个从数据方面的视角:. 按照 Martin Fowler 的定义,微服务是一个软件架构模式,通过开发一系列的小型服务的方式来实现一个应用.

微服务架构之事件驱动架构 - 简书

- -
为了解决传统的单体应用(Monolithic Application)在可扩展性、可靠性、适应性、高部署成本等方面的问题,许多公司(比如Amazon、eBay和NetFlix等)开始使用微服务架构(Microservice Architecture)构建自己的应用. 微服务(Microservices) 是一种软件架构风格 (Software Architecture Style),它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础,利用模组化的方式组合出复杂的大型应用程序,各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通讯.

微服务实战(一):微服务架构的优势与不足 - DockOne.io

- -
【编者的话】本文来自Nginx官方博客,是微服务系列文章的第一篇,主要探讨了传统的单体式应用的不足,以及微服务架构的优势与挑战. 正如作者所说,微服务架构更适合用于构建复杂的应用,尽管它也有自己的不足. 如果你想和我或者更多微服务专家交流,可以加我微信liyingjiese,备注『加群』. 群里每周都有全球各大公司的最佳微服务实践以及行业最新动态.