微服务,真的适合你么?

1、什么是微服务?

微服务是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。微服务架构模式(Microservices Architecture Pattern)的目的是将大型的、复杂的、长期运行的应用程序构建为一组相互配合的服务,每个服务都可以很容易做局部修改。微服务架构带来可独立部署、高扩展与伸缩、自由选择开发语言、高效利用资源、故障隔离等优点,同时也因为服务多带来分布式事务、服务之间通信、监控、部署等新的问题。

2、为什么要用微服务?

整体式架构应用图(以华为软件开发云为假设-其实他应该属于微服务架构):

整体式架构的不足

使用传统的整体式架构(Monolithic Architecture)应用开发系统易于开发,易于调试,也易于部署。在早期这类应用运行的很好,不幸的是,这种简单方法却有很大的局限性。

1)一个简单的应用会随着时间推移逐渐变大。在每次的sprint中,开发团队都会面对新story,新的task,然后开发许多新代码。几年后,这个小而简单的应用会逐渐变大。

2)一旦你的应用变成一个又大又复杂的怪物,开发团队肯定很痛苦。由于应用太大太复杂,以至于任何单个开发者都不可能搞懂它。因此,修正bug和正确的添加新功能变的非常困难,并且很耗时。

3)整体式架构应用也会降低开发速度。应用越大,启动时间会越长。如果开发者需要经常重启应用,那么大部分时间就要在等待中渡过,生产效率受到极大影响。

4)复杂而巨大的整体式架构应用不利于持续性开发。今天,SaaS应用常态就是每天会改变很多次,而这对于整体式架构模式非常困难。

5)整体式架构应用另外一个问题是可靠性。因为所有模块都运行在一个进程中,任何一个模块中的一个bug,比如内存泄露,将会有可能弄垮整个进程。

6)整体式架构应用使得采用新架构和语言非常困难。比如你的代码使用A框架写的,如果想改成B框架,无论是时间还是成本都是非常昂贵的。因此,这是一个无法逾越的鸿沟。

微服务架构图(以华为软件开发云为例):

微服务架构的好处

第一,通过分解巨大单体式应用为多个服务的方法解决了复杂性问题。在功能不变的情况下,应用被分解为多个可管理的分支或服务。每个服务都有一个用RPC-或者消息驱动API定义清楚的边界。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案,由此,单个服务很容易开发、理解和维护。

第二,这种架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术,提供API服务。这种自由意味着开发者不需要被迫使用某项目开始时采用的过时技术,他们可以选择现在的技术。甚至于,因为服务都是相对简单,即使用现在技术重写以前代码也不是很困难的事情。

第三,微服务架构模式是每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度。团队可以采用AB测试,快速的部署变化。微服务架构模式使得持续化部署成为可能。

最后,微服务架构模式使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的规模。甚至于,你可以使用更适合于服务资源需求的云服务。比如,你可以为计算密集型服务选择高配置的云主机,而在为存储密集型的服务选择高带宽高存储的云主机。

3、微服务,真的适合你么?

提到微服务架构时,我们常常会与整体式架构进行比较,整体式架构存在如下缺点:代码维护难度大,臃肿的部署,局限的弹性与扩展能力,阻碍团队与技术革新等等;微服务架构存在如下优点:代码维护简化,可独立部署,高扩展与伸缩,自由选择开发语言等优点。那么整体式架构真的这么差吗?显然不是。

在复杂度较小时采用整体式架构的生产率更高,复杂度到了一定规模时,单体应用的生产率开始急剧下降,这时对其进行微服务化的拆分才是合理的。所以说脱离业务场景,空谈架构绝对是耍流氓。

再牛逼的架构设计,如果无法在业务场景中落地实施,也只是空谈。因此架构需要服务于业务,针对不同的业务场景架构设计也会不同,架构设计不必追求高大上,只要能满足业务发展需求,便是好架构。

此外,好的架构不完全是设计出来的,随着业务量、请求量的增长,好的架构是演化而来的。微服务架构之所以得到广泛认可,源于对于业务多变性的不可预测,微服务架构能够不断的自演化,进而快速适应业务变化。此外,微服务也有他的不足之处:

第一,微服务应用是分布式系统,由此会带来固有的复杂性。

第二,分区的数据库架构在微服务架构应用中,需要更新不同服务所使用的不同的数据库,这对开发者提出了更高的要求和挑战。

第三,测试一个基于微服务架构的应用也是很复杂的任务。

第四,微服务架构模式应用的改变将会波及多个服务。

第五,部署一个微服务应用也很复杂。一个微服务应用一般由大批服务构成。成功部署一个微服务应用需要开发者有足够的控制部署方法,并高度自动化。

鉴于上述原因,如果公司的长期业务规划不需要微服务架构或者公司的实际情况不具备实施微服务一些基本的条件,不建议各位盲目迈向微服务这一新兴架构领域。如果准备早点进行技术积累,也可以从试点开始,逐步在团队中推行微服务架构。

4、微服务,如果真的适合你,应该怎么做?

1)买书学习。

2)上网查资料学习。

3)用华为软件开发云,让华为专家指导你。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,921评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,635评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,393评论 0 338
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,836评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,833评论 5 368
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,685评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,043评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,694评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 42,671评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,670评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,779评论 1 332
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,424评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,027评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,984评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,214评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,108评论 2 351
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,517评论 2 343

推荐阅读更多精彩内容