微服务1:系统架构演变--为何使用微服务

1、前言

  • 随着互联网的发展,网站应用的规模也在不断的扩大,进而导致系统架构也在不断的进行变化。

  • 从互联网早起到现在,系统架构大体经历了下面几个过程: 单体应用架构—>垂直应用架构—>分布式架构—>SOA架构—>微服务架构,当然还有悄然兴起的Service Mesh(服务网格化)。如图:


    image.png
  • 接下来我们就来了解一下每种系统架构是什么样子的, 以及各有什么优缺点、为什么使用微服务架构。
    关键词: 用户访问量(并发访问)&代码重复量、容错率、可维护性、水平扩展

1.1 单体应用架构

image.png

互联网早期,一般的网站应用流量较小,只需一个应用,将所有功能代码都部署在一起就可以,这样可以减少开发、部署和维护的成本。
比如说一个电商系统,里面会包含很多用户管理,商品管理,订单管理,物流管理等等很多模块,我们会把它们做成一个web项目,然后部署到一台tomcat服务器上。

  • 优点:
    项目架构简单,小型项目的话, 开发成本低
    项目部署在一个节点上, 维护方便
  • 缺点:
    全部功能集成在一个工程中,对于大型项目来讲不易开发和维护
    项目模块之间紧密耦合,单点容错率低
    无法针对不同模块进行针对性优化和水平扩展

1.2 垂直应用架构

image.png

随着访问量的逐渐增大,单一应用只能依靠增加节点来应对(加机器),但是这时候会发现并不是所有的模块都会有比较大的访问量.

还是以上面的电商为例子, 用户访问量的增加可能影响的只是用户和订单模块, 但是对消息模块的影响就比较小. 那么此时我们希望只多增加几个订单模块, 而不增加消息模块. 此时单体应用就做不到了, 垂直应用就应运而生了.

所谓的垂直应用架构,就是将原来的一个应用拆成互不相干的几个应用,以提升效率。比如我们可以将上面电商的单体应用拆分成:

电商系统(用户管理 商品管理 订单管理)
后台系统(用户管理 订单管理 客户管理)
CMS系统(广告管理 营销管理)

这样拆分完毕之后,一旦用户访问量变大,只需要增加电商系统的节点就可以了,而无需增加后台和CMS的节点。

  • 优点:
    系统拆分实现了流量分担,解决了并发问题,而且可以针对不同模块进行优化和水扩展,一个系统的问题不会影响到其他系统,提高容错率
  • 缺点:
    系统之间相互独立, 无法进行相互调用
    系统之间相互独立, 会有重复的开发任务

1. 3 分布式架构

当垂直应用越来越多,重复的业务代码就会越来越多。这时候,我们就思考可不可以将重复的代码抽取出来,做成统一的业务层作为独立的服务,然后由前端控制层调用不同的业务层服务呢?

这就产生了新的分布式系统架构。它将把工程拆分成表现层和服务层两个部分,服务层中包含业务逻辑。表现层只需要处理和页面的交互,业务逻辑都是调用服务层的服务来实现。

  • 优点:
    抽取公共的功能为服务层,提高代码复用性
  • 缺点:
    系统间耦合度变高,调用关系错综复杂,难以维护

1.4 SOA架构

image.png

在分布式架构下,当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需增加一个调度中心对集群进行实时管理。此时,用于资源调度和治理中心(SOA Service OrientedArchitecture)是关键。

  • 优点:
    使用治理中心(ESB\dubbo)解决了服务间调用关系的自动调节
  • 缺点:
    服务间会有依赖关系,一旦某个环节出错会影响较大( 服务雪崩 )
    服务关系复杂,运维、测试部署困难

1.5 微服务架构

image.png

微服务理念图:


image.png

image.png

微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步,它更加强调服务的"彻底拆分"。
微服务架构与SOA架构的不同:

  • 微服务架构比 SOA架构粒度会更加精细,让专业的人去做专业的事情(专注),目的提高效率,每个服务于服务之间互不影响(一个微服务一个进程),微服务架构中,每个服务必须独立部署,微服务架构更加轻巧,轻量级。
  • SOA 架构中可能数据库存储会发生共享,微服务强调独每个服务都是单独数据库,保证每个服务于服务之间互不影响。
  • 项目体现特征微服务架构比 SOA 架构更加适合与互联网公司敏捷开发、快速迭代版本,因为粒度非常精细。
  • 优点:
    服务原子化拆分,独立打包、部署和升级,保证每个微服务清晰的任务划分,利于扩展
    微服务之间采用Restful等轻量级http协议相互调用
  • 缺点:
    分布式系统开发的技术成本高(容错、分布式事务等)
    复杂性更高。各个微服务进行分布式独立部署,当进行模块调用的时候,分布式将会变得更加麻烦。

2、总结

  1. 单体架构存在高并发瓶颈,不适合大型平台,多用户、高并发访问量场景。
  2. 垂直架构将平台拆分多个子平台,通过加机器加节点方式有效缓解高并发问题,但多个子平台存在代码重复量(开发任务重复)问题,比如公司多产品下,每个产品/平台都需要登录功能。
  3. 分布式架构将重复代码独立抽取,分别部署,但存在调用关系错综复杂问题。
  4. SOA架构提供了服务治理协调方案(注册中心Dubbo、ESB总线等),存在数据库共享、服务雪崩的问题。
  5. 微服务架构提供了服务治理、服务容错、链路追踪等一整套方案,彻底拆分,业务功能服务化,更精细化,独立进程,但还是比较依赖网络,技术成本高。
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,193评论 6 498
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,306评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 162,130评论 0 353
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,110评论 1 292
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,118评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,085评论 1 295
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,007评论 3 417
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,844评论 0 273
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,283评论 1 310
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,508评论 2 332
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,667评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,395评论 5 343
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,985评论 3 325
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,630评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,797评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,653评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,553评论 2 352

推荐阅读更多精彩内容