为了账号安全,请及时绑定邮箱和手机立即绑定

姚半仙:为什么要将应用微服务化?

2019.11.08 17:53 5199浏览

上一篇我们聊了什么是微服务(What),这一篇我们就来聊一聊为何要做微服务化改造(Why)。在开始之前,我们先来聊聊那些年我们曾经采用过的“高可用”架构。

上古时期的高可用架构

其实在十多年前,“架构师”并不是一个需求很大的职业,一来那时还没有“全民App”级别的应用,除了三大门户网站以外,其他的网上应用业务压力并不大;二来也没有现如今这么丰富的技术选型,几乎清一色的PHP(坊间一直流传着PHP是世界上最好的语言这个说法,我08年左右写过一年PHP,那是我人生最黑暗的一年)。因此对所谓“架构师”的需求并不是很大,那些年的高可用架构大体上就是这个样子的:


http://img2.sycdn.imooc.com/5dc53a6600011ecd21941360.jpg


在上面的反向代理集群之下,是众多Web服务器构成的高可用集群,不过这些服务器中部署的应用却是千篇一律,什么意思呢?大家看过火影忍者吧,里面主人公经常用的一招叫“多重影分身之术”,将一个自己的本尊复制为成千上万个本尊。这里的服务器集群是一个道理,将一个巨无霸的单体应用复制成N个单体应用,组成一个分布式的服务集群。

传统架构之殇

随着互联网行业的飞速发展,个人的衣食住行几乎全依赖各种APP来满足。每天早上起来刷刷淘宝,地铁上用视频app看个短句,一天微信不离手,睡前刷个抖音一不小心就刷到了后半夜,这些现象级全民应用层出不穷,所承接的用户访问量远飞上古时期的门户网站所能比拟的。在这种用户量级下还要能够满足不断变化的用户请求,就像给飞行中的飞机换引擎,传统的架构模式已经完全不能满足业务发展的节奏。

我们来举几个“单体应用”中经常被人诟病的几个问题:

数据访问杂乱


http://img4.sycdn.imooc.com/5dc53a890001110623401228.jpg


同一个war包内,在数据访问层面没有划分领域模型,比如说我们有User、Product和Order三张表,对于不同的Service来说,都通过直接访问数据库的方式来获取数据。这种做法有几个显而易见的缺点:

1)数据模型变更

拿Order表来说,如果某一天我的Data Model发生了重大变更,比如说引入了“子订单”的概念,原先的数据模型不能再很好地支持业务,必须重构Order订单表,与此同时,还要兼容老的订单结构。这种情况下你能贸然改动数据模型吗?恐怕不行,原因就是这个Order表被这个系统中的各个服务引用到了,你的改动可能会破坏其他服务的功能。

再举个例子,Product表以前存放的是单个的商品记录,数据模型非常简单,后面引入了SKU的概念,这就要对数据模型做重大改动,同时还可能影响到库存模块(以往库存落在Product级别,现在要落地到SKU级别)。

以上都是我做电商业务中遇到的实际场景,对于传统的应用结构来说,一丁点数据结构的改变都会引起很大的影响。如果数据模型的变动是必须的,那我们如何解决这种情况呢?很简单,通过微服务架构在各个服务之间做好隔离,将Data Model的影响带来的业务复杂度隔离在当前微服务中,划分好领域模型,上下游服务只要对接微服务的接口就可以,领域模型驱动不用依赖底层数据结构的变更。

2)底层组件变更

假如现在我要对Product表的数据访问规则做一个变更,比如引入MyCat分库分表,或者对热点数据的访问加上缓存读写的步骤。那么意味着上下游所有访问Product表的业务,都需要连带着做同样的改动。

再说个更极端的例子,以前我们使用的是Oracle,这家伙老贵了,领导层想要换成MySQL,即便我们没有存储过程的牵绊,那么这个变更也是极其巨大的,可谓牵一发而动全身

理论上来说,我们应该尽可能对业务层屏蔽底层组件的变更,在传统的分布式应用中非常难以办到,但是在微服务架构下却没有那么困难,因为微服务间的访问依赖API接口+业务模型,我们只要在当前微服务中把这种底层组件的变更处理好,对上下游其他服务来讲这个变更其实是无感知的,因为在微服务接口暴露出的业务模型并不会有什么变化。

代码复用带来的维护成本

一整个应用的代码掺杂在一块,少不了各种“借鉴”,咱来细数下这里面的坑:

1) 码农的傲娇 - rewrite code

作为一个骄傲的码农,看别人写的代码都跟屎一样,只有自己出品的才是最好的。路见不平重构一番,重构不了的干脆重新写个功能上一模一样但是代码结构上更“优雅”的接口出来,随着时间的推移,这深藏于码农血液里的“rewrite code”基因,终究会把一个代码库编程一座屎山。

2)小改动没什么大不了

“我就改了个if条件啊,谁知道你们也用了这个方法,这方法我当初就写给自己用的啊!”

码农之间的撕逼没有那么轰轰烈烈,反正最后归根结底就是-改出bug来了。上面那个情景在传统架构的系统里很常见,当你的业务需要添加一个新功能,瞄了几眼发现,咦?我去年写的这个方法改一下正好能用,随手改了个if条件。谁曾料想,隔壁组的程序媛妹子没打招呼也用了这个方法,被你这么一改,把别人的服务搞挂了,又不好意思跟人妹子撕逼,只好自己背了个生产事故的锅。

时不我待!糙快猛才是生产力

不知道大伙有没有经历过互联网公司的业务节奏,拥抱变化不是白叫的,研发团队沉浸在996的福报中不能自拔。就像前面说的,为了支持不断变化的新业务,开发团队对系统的改造就像给飞行中飞机换引擎,既要让飞机飞,又要保证完成任务,还得要快。因此我们提出了“糙快猛”的开发模式,它是继瀑布模型、敏捷模型等等软件工程理论之后的具有中国特色的互联网研发模式。

面对一个屎山一般的单war包应用,产品的发布节奏往往是以月甚至年来计,一个变更从评估到上线,拖个一年半载是很常见的事情,这种节奏对于互联网公司来说,倒闭100次都够了。

小步快跑

互联网产品的迭代依靠小步快跑,尽快上线,尽快验证业务模式,有问题立即调整,一切都是“快字当头”。对于传统应用来说,发布节奏只能划归到一个千年等一回的发布窗口,再小的变更都得耗上很长的时间,可能每次发布都要经历很耗时的全链路回归测试。对微服务架构来说完全不存在这个问题,每个微服务模块由于职责边界足够清晰,规模可控便于快速变更和测试,完全可以让团队自己制定发布窗口,即便是上线前的回归测试也只局限在当前服务模块。

回滚

回滚对于传统的单war包分布式系统来说是个噩梦,好不容易等到了发布窗口,各个团队牟足了劲把所有变更都发布了出去,结果因为其中某个小改动引发的问题,导致全部回滚。又要苦苦等待下一个发布窗口。

在微服务架构中,回滚只局限在某个微服务的范围内,只要把出问题的应用回滚就好了,不会影响上下游其他应用的发布节奏。

小结

这一篇跟大家八卦了这么多传统架构模式的弊端,其实总结起来就一句话 - 微服务大法好!不过微服务架构好不好,还要看各个服务之间拆的好不好,下一篇当中,我跟大家聊聊微服务拆分的几个规范。想了解更多,可以关注下我们的架构师成长直通课程



点击查看更多内容

本文原创发布于慕课网 ,转载请注明出处,谢谢合作

29人点赞

若觉得本文不错,就分享一下吧!

评论

相关文章推荐

正在加载中
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消