微服务是什么?

作者: 阮一峰

日期: 2022年4月29日

微服务(microservice)是一种软件架构,正得到越来越多的关注。

但是,它到底是什么意思?什么样的架构可以叫做微服务?

网上的文章虽然很多,但是都太复杂,初学者不容易看懂。我认为,这个概念其实非常简单,可以很通俗地说明白。

一、单体软件

要理解微服务,首先需要理解软件架构的演变。

早期的软件,所有功能都写在一起,这称为单体架构(monolithic software)。

整个软件就是单一的整体,彷佛一体化的机器。

可以想到,软件的功能越多,单体架构就会越复杂,很多缺点也随之暴露出来。

(1)所有功能耦合在一起,互相影响,最终难以管理。

(2)哪怕只修改一行代码,整个软件就要重新构建和部署,成本非常高。

(3)因为软件做成了一个整体,不可能每个功能单独开发和测试,只能整体开发和测试,导致必须采用瀑布式开发模型。

以上三个原因的详细分析,可以参考我以前的文章《软件工程的最大难题》

总之,单体架构的大型软件,不仅开发速度慢,而且会形成难以维护和升级的复杂代码,成为程序员的沉重负担。

二、面向服务架构

为了解决上面这些问题,很早就有人提出来,必须打破代码的耦合,拆分单体架构,将软件拆分成一个个独立的功能单元。

大概在20多年前,随着互联网的出现,功能单元可以用远程"服务"的形式提供,就诞生出了"面向服务架构"(service-oriented architecture,简称 SOA)。

所谓服务(service),就是在后台不间断运行、提供某种功能的一个程序。最常见的服务就是 Web 服务,通过80端口向外界提供网页访问。

"面向服务架构"就是把一个大型的单体程序,拆分成一个个独立服务,也就是较小的程序。每个服务都是一个独立的功能单元,承担不同的功能,服务之间通过通信协议连在一起。

这种架构有很多优点。

(1)每种服务功能单一,相当于一个小型软件,便于开发和测试。

(2)各个服务独立运行,简化了架构,提高了可靠性。

(3)鼓励和支持代码重用,同一个服务可以用于多种目的。

(4)不同服务可以单独开发和部署,便于升级。

(5)扩展性好,可以容易地加机器、加功能,承受高负载。

(6)不容易出现单点故障。即使一个服务失败了,不会影响到其他服务。

跟单体架构不一样,面向服务架构是语言不敏感的,不同服务可以使用不同的语言和工具开发,可能需要部署在不同的系统和环境。

这意味着,面向服务架构默认运行在不同服务器上,每台服务器提供一种服务,多台服务器共同组成一个完整的网络应用。

三、微服务

2014年,Docker 出现了,彻底改变了软件开发的面貌。它让程序运行在容器中,每个容器可以分别设定运行环境,并且只占用很少的系统资源。

显而易见,可以用容器来实现"面向服务架构",每个服务不再占用一台服务器,而是占用一个容器。

这样就不需要多台服务器了,最简单的情况下,本机运行多个容器,只用一台服务器就实现了面向服务架构,这在以前是做不到的。这种实现方式就叫做微服务。

简单说,微服务就是采用容器技术的面向服务架构。它依然使用"服务"作为功能单元,但是变成了轻量级实现,不需要新增服务器,只需要新建容器(一个进程),所以才叫做"微服务"。

一个微服务就是一个独立的进程 这个进程可以运行在本机,也可以运行在别的服务器,或者在云端(比如云服务和云函数 FaaS)。

它的特点与面向服务架构是一样的,但因为更轻量级,所以功能的解耦和服务化可以做得更彻底。而且,它可以标准化,同样的容器不管在哪里运行,结果都是一样的,所以市场上有很多 SaaS 产品,提供标准化的微服务。

正是由于微服务这些突出的优点,这几年才会变得如此流行。它和容器技术、云服务一起,一定会在未来的软件开发中,扮演越来越重要的角色。

(完)

留言(57条)

文章讲的很透彻,但是从社会学角度想这个,资本下,微服务里的服务就是螺丝钉,可替代性增加了。
那么程序员职场资本的稀缺和宝贵性,该从哪里获取,值得思考。

今天的日志?

写了个啥?周五就微服务科普?就完了?

这周没有周刊吗?

阮老师今天有点短啊

我以前一直也对SOA和微服务的关系感到迷糊。现在悟了,SOA服务占用一个物理机器,而微服务占用一个“Docker”。一个物理机器可以有多个Docker,所以“微”服务了。

引用神乐的发言:

写了个啥?周五就微服务科普?就完了?

明天五一假期,周刊暂停一次,望谅解。

我以为今天周五了,一看今天果然周五了。

引用神乐的发言:

写了个啥?周五就微服务科普?就完了?

这一期是开发者手册内容,不是周刊

引用神乐的发言:

写了个啥?周五就微服务科普?就完了?

人家在上一期周刊开头就说了,临近五一假期,周刊暂停一次。

引用神乐的发言:

写了个啥?周五就微服务科普?就完了?

你这语气好像别人就该写给你看一样

引用神乐的发言:

写了个啥?周五就微服务科普?就完了?

阮老师五一假期停一次周刊,不用这么大惊小怪。

这样解释绩效可拿不到75啊!

哈哈,阮大没写周报,但是还是给我们写了点东西看,点赞

单体应用应该没有限制只能使用瀑布模型吧,虽然增量模型和演化的螺旋模型也依赖瀑布模型。另外我的理解是微服务和是否运行容器并不是充分必要关系吧。

意犹未尽

Spring Cloud 是一个微服务的开发框架,但完全可以脱离 docker 运行,所以容器并不是微服务所必需的,不过 Java 的 Jvm 本身就具有容器性质,从这点上看说微服务建立在容器技术的基础上好像也没错。

微服务跟容器有关吗?这个第一次听说呀?

老师上周的周刊都说了,本周没有周刊。你们这些人啊,还在这问,你们写代码从来都不看文档吗?

结束的有些猝不及防啊????

答案就是:协议和虚拟机。

引用神乐的发言:

写了个啥?周五就微服务科普?就完了?

好家伙,开始道德绑架了。合着就应该给你写似的

谢谢分享

一直都没时间去了解。今天看了你的文章。原来是这么简单。讲的通俗易懂。

(1)所有功能耦合在一起,互相影响,最终难以管理。

(2)哪怕只修改一行代码,整个软件就要重新构建和部署,成本非常高。

(3)因为软件做成了一个整体,不可能每个功能单独开发和测试,只能整体开发和测试,导致必须采用瀑布式开发模型。

这三点哪怕一点成立,我就不挺单体了。单体不代表不能模块化,模块话好的单体比微服务优秀多了。这里的单体是以进程为区分单位的。很多时候我们再说微服务的时候没有先说微服务的缺点。就说一点:微服务必然涉及通信,通信必然涉及时序,单单这一点带来的复杂度都是指数级的。这个很像算法,当n不超过一个点的时候,低级算法比高级算法快多了。没有先计算,测量,评估这个n,就别直接上高级算法。同样的,没有评估微服务带来的问题跟解决问题之间的ROI,就别直接上微服务。

虽然能理解, 周五没看到周刊有些失落. 也许这就叫习惯吧

之前看到过一个说法是,SOA 缺少标准,需要 ESB 产品来中转;而微服务则有标准,因而不需要 ESB 产品。

是不是偷懒了呀!

引用KevinBlandy的发言:

我以前一直也对SOA和微服务的关系感到迷糊。现在悟了,SOA服务占用一个物理机器,而微服务占用一个“Docker”。一个物理机器可以有多个Docker,所以“微”服务了。

是这么理解的吗???微服务只是通过Docker使服务更轻量化,更灵活部署,没有你说的那层意思吧,SOA也可以在一台服务器上部署多个,Docker也可以独占一台机器。

上周就说了这周放假不发了,真就这么多免费拿来主义吗

引用billy的发言:

微服务跟容器有关吗?这个第一次听说呀?

有了容器才使微服务成为现实,否则没办法管理,或者说管理成本太高

引用xxx的发言:

单体应用应该没有限制只能使用瀑布模型吧,虽然增量模型和演化的螺旋模型也依赖瀑布模型。另外我的理解是微服务和是否运行容器并不是充分必要关系吧。

确实微服务和容器不是同一性质的东西,但容器技术的产生确实是微服务发展的关键

(3)因为软件做成了一个整体,不可能每个功能单独开发和测试,只能整体开发和测试,导致必须采用瀑布式开发模型。 ——这一条不太认同。开发模型是业务逻辑层面的,单一体的软件一样可以敏捷开发,不必瀑布

五一快乐,阮老师一定注重劳逸结合,才能免费为我们提供精彩的知识。

啥时候阮大也把评论区的IP地址开放出来,或者下一期讨论一下这个IP开放的技术问题????

引用KevinBlandy的发言:

我以前一直也对SOA和微服务的关系感到迷糊。现在悟了,SOA服务占用一个物理机器,而微服务占用一个“Docker”。一个物理机器可以有多个Docker,所以“微”服务了。

一个物理机器通常只需要一个docker
一个docker挂载无数的软件/服务的运行时镜像images
按需要,为多个软件/服务在容器container中开启/运行实例
每个container拥有不同的监听端口,结合内部外部ip提供运算和服务????

SOA和分布式多进程的主要区别是什么呢?

容器让服务部署更加简便(基于标准化之上的自动化)和安全(隔离),
让服务化更加可行和更流行,
这种流行促使了服务能够更微更快,
所以叫微服务?

微服务就是采用容器技术的面向服务架构,虽然是简单的说,也不太准确吧。微服务不一定就采用容器技术,只能说目前比较多。

看了一遍之后有些明朗,微服务就是采用容器技术的面向服务架构,每个小模块运行在容器中,不必使用多个物理环境部署,但是看了评论区后又觉得理解的有些不对劲,。。谁能再给我概括性的解答一下微服务到底是什么啊?

引用ZZJ的发言:

文章讲的很透彻,但是从社会学角度想这个,资本下,微服务里的服务就是螺丝钉,可替代性增加了。
那么程序员职场资本的稀缺和宝贵性,该从哪里获取,值得思考。

庆余年男主为啥带着一个强力机器人呢?时代不同,程序员能够掌控的资源也不可同日而语了

短小精悍

SOA和微服务的本质区别,不是有没有用容器技术,而是内部服务之间是如何调用的。举例来说,一个进销存服务,通过接口与外部系统交互,但进销存之间通过数据库直接相互操作数据,这属于SOA。如果进销存之间也是通过接口,而不是数据库操作,来交换数据,这就属于微服务了。微服务的一个特点是,每个微服务都有自己的data store,服务之间只能通过接口,而不是数据库操作,来交换数据。

我觉得微服务其实是一个概念,怎么实现都可以。最核心的是能很方便的为已有的系统提供新的服务

没看到更深入的个人理解

引用billy的发言:

微服务跟容器有关吗?这个第一次听说呀?

目前为止,个人认为还是Martin Fowler解释的最为准确:In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery

开发和docker没有任何关系.

Docker(或者说 Moby?)的出现是一个领导者伟大的决策

现在做的5G就是SBA架构,每个NF之间低耦合,自己完成自己的功能,通过比进程更小的单位协程交流MSG.

可以再来一篇微应用

建议读一下 Martin Fowler 的博客,理解了再来科普,免得误人子弟。

有点迷惑,和容器一定相关吗

引用none的发言:

建议读一下 Martin Fowler 的博客,理解了再来科普,免得误人子弟。


MF的博客您读过?
请详细说说这篇文章哪写的不对,只有结论没有论据,没有任何价值。。。

寫得太忽悠了啊。微服務採用分布式功能模塊和分布式數據庫°各功能模塊完全獨立且各有自己的數據庫!而數據一致性問題通過Saga解決。所以不使用ESB,也沒有像 SOA的统一數據庫操作。

以前的soa是调用服务的处理程序的
现在的微服务可以调用服务里面的具体的方法,基于RPC的

寫得很好的,簡單易懂,讓初學者一下了解了三者的定義和關係

大佬,可以用这么通俗易懂的表达出来。可见对微服务有很深的见解。
正所谓“圣者渡人 强者渡己”。对技术的感悟,一定是有深厚的积累,才能悟出独到的感悟。

我要发表看法

«-必填

«-必填,不公开

«-我信任你,不会填写广告链接