微服务（microservice）是一种软件架构，正得到越来越多的关注。
但是，它到底是什么意思？什么样的架构可以叫做微服务？
网上的文章虽然很多，但是都太复杂，初学者不容易看懂。我认为，这个概念其实非常简单，可以很通俗地说明白。
一、单体软件
要理解微服务，首先需要理解软件架构的演变。
早期的软件，所有功能都写在一起，这称为单体架构（monolithic software）。
整个软件就是单一的整体，彷佛一体化的机器。
可以想到，软件的功能越多，单体架构就会越复杂，很多缺点也随之暴露出来。
（1）所有功能耦合在一起，互相影响，最终难以管理。
（2）哪怕只修改一行代码，整个软件就要重新构建和部署，成本非常高。
（3）因为软件做成了一个整体，不可能每个功能单独开发和测试，只能整体开发和测试，导致必须采用瀑布式开发模型。
以上三个原因的详细分析，可以参考我以前的文章《软件工程的最大难题》。
总之，单体架构的大型软件，不仅开发速度慢，而且会形成难以维护和升级的复杂代码，成为程序员的沉重负担。
二、面向服务架构
为了解决上面这些问题，很早就有人提出来，必须打破代码的耦合，拆分单体架构，将软件拆分成一个个独立的功能单元。
大概在20多年前，随着互联网的出现，功能单元可以用远程"服务"的形式提供，就诞生出了"面向服务架构"（service-oriented architecture，简称 SOA）。
所谓服务（service），就是在后台不间断运行、提供某种功能的一个程序。最常见的服务就是 Web 服务，通过80端口向外界提供网页访问。
"面向服务架构"就是把一个大型的单体程序，拆分成一个个独立服务，也就是较小的程序。每个服务都是一个独立的功能单元，承担不同的功能，服务之间通过通信协议连在一起。
这种架构有很多优点。
（1）每种服务功能单一，相当于一个小型软件，便于开发和测试。
（2）各个服务独立运行，简化了架构，提高了可靠性。
（3）鼓励和支持代码重用，同一个服务可以用于多种目的。
（4）不同服务可以单独开发和部署，便于升级。
（5）扩展性好，可以容易地加机器、加功能，承受高负载。
（6）不容易出现单点故障。即使一个服务失败了，不会影响到其他服务。
跟单体架构不一样，面向服务架构是语言不敏感的，不同服务可以使用不同的语言和工具开发，可能需要部署在不同的系统和环境。
这意味着，面向服务架构默认运行在不同服务器上，每台服务器提供一种服务，多台服务器共同组成一个完整的网络应用。
三、微服务
2014年，Docker 出现了，彻底改变了软件开发的面貌。它让程序运行在容器中，每个容器可以分别设定运行环境，并且只占用很少的系统资源。
显而易见，可以用容器来实现"面向服务架构"，每个服务不再占用一台服务器，而是占用一个容器。
这样就不需要多台服务器了，最简单的情况下，本机运行多个容器，只用一台服务器就实现了面向服务架构，这在以前是做不到的。这种实现方式就叫做微服务。
简单说，微服务就是采用容器技术的面向服务架构。它依然使用"服务"作为功能单元，但是变成了轻量级实现，不需要新增服务器，只需要新建容器（一个进程），所以才叫做"微服务"。
一个微服务就是一个独立的进程。 这个进程可以运行在本机，也可以运行在别的服务器，或者在云端（比如云服务和云函数 FaaS）。
它的特点与面向服务架构是一样的，但因为更轻量级，所以功能的解耦和服务化可以做得更彻底。而且，它可以标准化，同样的容器不管在哪里运行，结果都是一样的，所以市场上有很多 SaaS 产品，提供标准化的微服务。
正是由于微服务这些突出的优点，这几年才会变得如此流行。它和容器技术、云服务一起，一定会在未来的软件开发中，扮演越来越重要的角色。
（完）
ZZJ 说：
文章讲的很透彻，但是从社会学角度想这个，资本下，微服务里的服务就是螺丝钉，可替代性增加了。
那么程序员职场资本的稀缺和宝贵性，该从哪里获取，值得思考。
2022年4月29日 08:56 | # | 引用
Benson 说：
今天的日志？
2022年4月29日 08:57 | # | 引用
神乐 说：
写了个啥？周五就微服务科普？就完了？
2022年4月29日 08:58 | # | 引用
xioacd99 说：
这周没有周刊吗？
2022年4月29日 09:09 | # | 引用
MarsOnly 说：
阮老师今天有点短啊
2022年4月29日 09:11 | # | 引用
KevinBlandy 说：
我以前一直也对SOA和微服务的关系感到迷糊。现在悟了，SOA服务占用一个物理机器，而微服务占用一个“Docker”。一个物理机器可以有多个Docker，所以“微”服务了。
2022年4月29日 09:12 | # | 引用
sukey 说：
明天五一假期，周刊暂停一次，望谅解。
2022年4月29日 09:12 | # | 引用
Erick 说：
我以为今天周五了，一看今天果然周五了。
2022年4月29日 09:13 | # | 引用
梦凡星西 说：
这一期是开发者手册内容，不是周刊
2022年4月29日 09:15 | # | 引用
喻九敏 说：
人家在上一期周刊开头就说了，临近五一假期，周刊暂停一次。
2022年4月29日 09:18 | # | 引用
hh 说：
你这语气好像别人就该写给你看一样
2022年4月29日 09:27 | # | 引用
Jaya 说：
阮老师五一假期停一次周刊，不用这么大惊小怪。
2022年4月29日 09:32 | # | 引用
r 说：
这样解释绩效可拿不到75啊！
2022年4月29日 09:35 | # | 引用
fedkwan 说：
哈哈，阮大没写周报，但是还是给我们写了点东西看，点赞
2022年4月29日 09:36 | # | 引用
xxx 说：
单体应用应该没有限制只能使用瀑布模型吧，虽然增量模型和演化的螺旋模型也依赖瀑布模型。另外我的理解是微服务和是否运行容器并不是充分必要关系吧。
2022年4月29日 09:44 | # | 引用
大宝 说：
意犹未尽
2022年4月29日 09:54 | # | 引用
Pan 说：
Spring Cloud 是一个微服务的开发框架，但完全可以脱离 docker 运行，所以容器并不是微服务所必需的，不过 Java 的 Jvm 本身就具有容器性质，从这点上看说微服务建立在容器技术的基础上好像也没错。
2022年4月29日 10:07 | # | 引用
billy 说：
微服务跟容器有关吗？这个第一次听说呀？
2022年4月29日 10:09 | # | 引用
像我这样迷茫的人 说：
老师上周的周刊都说了，本周没有周刊。你们这些人啊，还在这问，你们写代码从来都不看文档吗？
2022年4月29日 10:10 | # | 引用
我为双鱼狂 说：
结束的有些猝不及防啊????
2022年4月29日 10:19 | # | 引用
樵夫 说：
答案就是：协议和虚拟机。
2022年4月29日 10:26 | # | 引用
Cikayo 说：
好家伙，开始道德绑架了。合着就应该给你写似的
2022年4月29日 10:42 | # | 引用
shinlooker 说：
谢谢分享
2022年4月29日 10:47 | # | 引用
小飞页 说：
一直都没时间去了解。今天看了你的文章。原来是这么简单。讲的通俗易懂。
2022年4月29日 13:03 | # | 引用
zjy 说：
（1）所有功能耦合在一起，互相影响，最终难以管理。
（2）哪怕只修改一行代码，整个软件就要重新构建和部署，成本非常高。
（3）因为软件做成了一个整体，不可能每个功能单独开发和测试，只能整体开发和测试，导致必须采用瀑布式开发模型。
这三点哪怕一点成立，我就不挺单体了。单体不代表不能模块化，模块话好的单体比微服务优秀多了。这里的单体是以进程为区分单位的。很多时候我们再说微服务的时候没有先说微服务的缺点。就说一点：微服务必然涉及通信，通信必然涉及时序，单单这一点带来的复杂度都是指数级的。这个很像算法，当n不超过一个点的时候，低级算法比高级算法快多了。没有先计算，测量，评估这个n，就别直接上高级算法。同样的，没有评估微服务带来的问题跟解决问题之间的ROI，就别直接上微服务。
2022年4月29日 14:57 | # | 引用
我的大名 说：
虽然能理解, 周五没看到周刊有些失落. 也许这就叫习惯吧
2022年4月29日 15:38 | # | 引用
mine 说：
之前看到过一个说法是，SOA 缺少标准，需要 ESB 产品来中转；而微服务则有标准，因而不需要 ESB 产品。
2022年4月29日 15:47 | # | 引用
牛奶盒子 说：
是不是偷懒了呀！
2022年4月29日 15:52 | # | 引用
this li 说：
是这么理解的吗？？？微服务只是通过Docker使服务更轻量化，更灵活部署，没有你说的那层意思吧，SOA也可以在一台服务器上部署多个，Docker也可以独占一台机器。
2022年4月29日 16:18 | # | 引用
Donne 说：
上周就说了这周放假不发了，真就这么多免费拿来主义吗
2022年4月29日 16:19 | # | 引用
tiger 说：
有了容器才使微服务成为现实，否则没办法管理，或者说管理成本太高
2022年4月29日 16:23 | # | 引用
this li 说：
确实微服务和容器不是同一性质的东西，但容器技术的产生确实是微服务发展的关键
2022年4月29日 16:32 | # | 引用
Kenny 说：
（3）因为软件做成了一个整体，不可能每个功能单独开发和测试，只能整体开发和测试，导致必须采用瀑布式开发模型。 ——这一条不太认同。开发模型是业务逻辑层面的，单一体的软件一样可以敏捷开发，不必瀑布
2022年4月30日 12:36 | # | 引用
ss 说：
五一快乐，阮老师一定注重劳逸结合，才能免费为我们提供精彩的知识。
2022年4月30日 21:23 | # | 引用
phdbbs 说：
啥时候阮大也把评论区的IP地址开放出来，或者下一期讨论一下这个IP开放的技术问题????
2022年5月 1日 21:22 | # | 引用
Ben 说：
一个物理机器通常只需要一个docker
一个docker挂载无数的软件/服务的运行时镜像images
按需要，为多个软件/服务在容器container中开启/运行实例
每个container拥有不同的监听端口，结合内部外部ip提供运算和服务????
2022年5月 2日 20:18 | # | 引用
watson 说：
SOA和分布式多进程的主要区别是什么呢？
2022年5月 3日 21:45 | # | 引用
ning 说：
容器让服务部署更加简便（基于标准化之上的自动化）和安全（隔离），
让服务化更加可行和更流行，
这种流行促使了服务能够更微更快，
所以叫微服务?
2022年5月 5日 09:51 | # | 引用
Andrei 说：
微服务就是采用容器技术的面向服务架构，虽然是简单的说，也不太准确吧。微服务不一定就采用容器技术，只能说目前比较多。
2022年5月 5日 20:37 | # | 引用
玛蒂蒂 说：
看了一遍之后有些明朗，微服务就是采用容器技术的面向服务架构，每个小模块运行在容器中，不必使用多个物理环境部署，但是看了评论区后又觉得理解的有些不对劲，。。谁能再给我概括性的解答一下微服务到底是什么啊？
2022年5月 6日 10:06 | # | 引用
dodo 说：
庆余年男主为啥带着一个强力机器人呢？时代不同，程序员能够掌控的资源也不可同日而语了
2022年5月16日 10:38 | # | 引用
蝉沐风 说：
短小精悍
2022年5月16日 10:53 | # | 引用
睡神 说：
SOA和微服务的本质区别，不是有没有用容器技术，而是内部服务之间是如何调用的。举例来说，一个进销存服务，通过接口与外部系统交互，但进销存之间通过数据库直接相互操作数据，这属于SOA。如果进销存之间也是通过接口，而不是数据库操作，来交换数据，这就属于微服务了。微服务的一个特点是，每个微服务都有自己的data store，服务之间只能通过接口，而不是数据库操作，来交换数据。
2022年5月18日 09:46 | # | 引用
居家大哥 说：
我觉得微服务其实是一个概念，怎么实现都可以。最核心的是能很方便的为已有的系统提供新的服务
2022年5月20日 10:03 | # | 引用
万万不可 说：
没看到更深入的个人理解
2022年5月23日 09:02 | # | 引用
Q3Feng 说：
目前为止，个人认为还是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
2022年5月29日 15:29 | # | 引用
yuanpu 说：
开发和docker没有任何关系.
2022年6月13日 12:41 | # | 引用
龚国玮 说：
Docker（或者说 Moby？）的出现是一个领导者伟大的决策
2022年6月29日 16:37 | # | 引用
NADOOO 说：
现在做的5G就是SBA架构，每个NF之间低耦合，自己完成自己的功能，通过比进程更小的单位协程交流MSG.
2022年7月 7日 11:43 | # | 引用
阮师傅 说：
可以再来一篇微应用
2022年7月30日 14:01 | # | 引用