本文部分内容选自我邦「聊聊架构」，作者 Andy Zhang，池建强修改润色并增删部分内容。

以前总有人问我微服务相关的问题，但微服务绝不是一篇文章能说清楚的事，所以我和 Gary 小王子商量了一下，在极客时间上开发了一个全新的白板课程，第一个产品就是微服务，以短视频讲系统内容。结果还是有人问，比如微服务到底有多「微」，什么类型什么规模的系统适合微服务…等等。

今天我就用电子邮件这个人民群众喜闻乐见的工具系统做一个类比。

随着微服务的实践和火热，关于「微」的概念出现了很多不同层面的理解。一个开发者普遍认可的定义是：一个微服务应该小到只做一件事。但是深入追究，你会觉得这并不是一个有意义的解释 —— 「一件事」这个概念本身就有可大可小，规模类型各不相同，它并不能起到有效约束微服务大小的作用。事实上，我同样反对那些认为每个独立的服务应该能且仅能实现单一功能的观点。比如，有个函数是根据三个输入参数来计算输出 —— 你真的认为我们有必要将这个方法单独抽离成一个微服务并独立部署么？

你要真这么做了，估计二爷都不能答应。

类比是跨越鸿沟最好的桥梁，来，我们举一个例子：比如电子邮件系统。为了尽量简单化这个模型，我们假设它是纯粹的电子邮件系统，只有基本功能（如登录、退出、用户设置、写邮件、发送邮件、删除邮件、查看收件箱、创建/修改文件夹、记录通讯录、搜索邮件等）。从单一模式的设计角度出发，我们可以用一个应用来实现所有功能。我们也可以用模块化设计的方式将它的功能拆分成模块，比如用 DDD（领域驱动设计）的方式来拆分。当然，我们需要一些其他的依赖来实现某些功能 —— UI、数据存储、外部搜索系统等。最后，我们可能得到一个六边形或多层结构的单体应用。