为什么要微服务架构服务化?

file

微服务架构,这 5 年左右一直被认可,是软件架构的未来方向。需要大家理解的是,为什么需要服务化。比如微服务架构对企业来说,带来什么价值?有啥弊端?

这里浅谈一下微服务架构,主要还是在理解 Why :为什么需要服务化?

一、对微服务架构的理解

1.1 微服务架构

file

微服务架构,主要是多了个 “微”。亚马逊有个粗粗的定义:一个微服务应用工程的所有开发、测试、运维加起来大约 6 到 8 个人,只需要两个披萨就可以聚餐了。

反例:不是一个 Service 类组成的应用工程,发布成服务就是微服务。这样分的太小,理解微服务就很片面。杭州某金融大厂,曾经分的很细,造成了运维测试成本巨大。开始分了合,折腾...

1.2 为啥需要微服务?

由 SOA 架构 -> 微服务架构的转变,得理解为什么微服务架构被广泛提到并实践。它解决了什么问题,带来了什么价值?

传统企业或者很多企业的软件,大多不止一套系统,都是各个独立大系统的堆砌。整体存在的问题是:

  • 扩展性差
  • 可靠性不高
  • 维护成本还很大
  • 重复轮子很多
file

那么这些问题,可以想到的解决方案就是:

  • 组件化
  • 服务化

微服务架构,将各个组件或者模块分散到各个服务中,对整个系统实现解耦。那微服务架构强调的重中之重就是业务系统需要完善的组件化和服务化。什么是组件化?

组件化,即将一个大系统,按照一定的业务或者技术维度关注形式,拆分成独立的组件。目的是为了分而治之,为了可重用,为了减少耦合度。比如按照技术维度:搜索组件、缓存组件;按照业务维度:用户中心、支付中心等

file

组件化是不是有点中台的意思?阿里巴巴提出 大中台,小前台;就是把组件化、插件化、服务化解决方案到极致。通过产品线公共业务或者技术下沉,形成各种技术或者业务中台

file

(图来自漫画程序员小灰)

二、服务化前的问题

2.1 没有服务化,不代表不是分布式或集群

分布式,就是多个实例提供相同的服务。比如多个地方动车站里面,多个机器提供取票服务。多个地方,北京上海等,就是多机房,多个取票服务一起组成了集群,形成分布式服务。那啥是服务化?

服务化,强调 “化”!核心就是不同服务之间的通信。是一种以服务为中心的解决方案:

  • 服务注册
  • 服务发布
  • 服务调用
  • 服务监控
  • 服务负载均衡
  • 等等
file

2.2 没有服务化的架构问题

没有服务化前,举个例子,会更形象:

假设有个取票服务、买票服务、改座服务都需要验证下用户身份真实性,那么会存在下面的问题:

  • 取票服务 -> 调用用户DB代码 -> 用户DB
  • 买票服务 -> 调用用户DB代码 -> 用户DB
  • 改座服务 -> 调用用户DB代码 -> 用户DB
file

明显的问题是:

  • 代码重复:不同业务相同访问 DB 的 userDAO 代码逻辑。而且每个服务这块代码是不同人维护的。
  • 可维护性低:不同人维护;不同地方维护;每次 DB 字段改变或者迁库,全部业务都有修改
  • DB 访问耦合

自然也有解决方案是:lib。维护一个 user-DAO-lib 1.0.0 release 包,给各个业务方。

解决了问题,引入了新的问题,lib 升级是巨大而又漫长的问题。比如小李是维护 user-DAO-lib 的人,有一次写了隐蔽的 bug 。user-lib 升级到了 1.0.1 release,花了 1 个月左右时间,推几十个业务方升级完毕。然后这个 bug 运行了几天出现了,考虑升级fix或者回滚都是巨大的成本

基于服务化,就可以完美解决问题。

三、服务化后的好处

file

如图 Post 文章服务调用 Video 视频服务,需要通过最上层的 Service 之间相互调用。服务化明显改变:

  • DB 隔离:这样底层细节设计可以屏蔽,后续加上其他存储 Cache 等对业务调用方无感知。
  • 通过 Service 之间通信:具体协议可以 RPC / HTTP 等

服务化后的好处:

  • 调用简单:不用写相同的访问用户服务代码,调用一个服务即可
  • 代码复用:跟 lib 形式的代码复用有所区别在于,服务化通过通信的方式解决
  • 业务隔离
  • 数据库解耦
  • 等等

四、不可否认的微服务架构或者服务化带来新的问题

1、本身不大的系统,业务不复杂的系统也不需要微服务架构。微服务架构会带来一定的复杂性,是一套完整的服务治理方案
2、多个模块数据库,分布式事务是一个挑战
3、开发过程,增加了测试等一定的复杂性

有利必有弊,具体场景具体选择

五、小结

本小结,不是讲how,讲的是 why。只有懂 why ,才能更好地 do。从为啥服务化?到为啥微服务架构这么流行:

  • 微服务扩展性高
  • 微服务可靠性高
  • 微服务 维护成本小
  • 微服务几乎没有重复轮子
  • 微服务直接调用调用简单
  • 微服务业务隔离
  • 微服务数据库解耦
  • 等等

参考资料

本文由博客一文多发平台 OpenWrite 发布!

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

推荐阅读更多精彩内容