以前总有人问我微效劳相关的成绩，但微效劳绝不是一篇文章能说清楚的事，所以我和Gary小王子磋商了一下，在极客工夫上 开发 了一个全新的白板课程，第一个产品就是微效劳，以短视频讲零碎内容。后果还是有人问，比方微效劳究竟有多「微」，什么类型什么规模的零碎合适微效劳…等等。

明天我就用电子邮件这团体民群众脍炙人口的工具零碎做一个类比。

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

你要真这么做了，估量二爷都不能容许。

类比是跨越鸿沟最好的桥梁，来，我们举一个例子：比方电子 邮件零碎 。为了尽量复杂化这个模型，我们假定它是地道的电子邮件零碎，只要根本功用（如登录、加入、用户设置、写邮件、发送邮件、删除邮件、检查收件箱、创立/修正文件夹、记载通讯录、搜索邮件等）。从单一形式的设计角度动身，我们可以用一个使用来完成一切功用。我们也可以用模块化设计的方式将它的功用拆分红模块，比方用DDD（范畴驱动设计）的方式来拆分。当然，我们需求一些其他的依赖来完成某些功用——UI、数据存储、内部搜索零碎等。最初，我们能够失掉一个六边形或多层构造的单体使用。

一切与这个邮件零碎相关的团队都必需严密联络在一同，一旦使用有任何改动，（简直）一切人的代码都会遭到影响。现实上这个邮件零碎就是一个大的Package，把零碎功用、代码和工程师都装出来了，这种使用被我们成为All-or-Nothing，要么生活，要么死亡，我们只能选择运转/不运转整个零碎，没法灵敏的开启/封闭某些功用。关于某些规模的团队和零碎，这样的构造也能够很好，现实上很多创业公司都是这么过去的，时机很少有创业公司在一穷二白的时分设计微效劳架构。

随着团队和零碎规模的增长，产品的演进，很多团队开端不满足于这种架构，大家希望将整个使用切分红绝对独立的、有着本人生命周期的子使用/效劳/库，那么就要停止零碎的切分。

如何切分？首先，登录/登出（或许叫受权零碎）和用户材料这两块可以拆分红独自的效劳。并且，基于平安性的考量，它们应该被独自设计和完成。邮件和文件夹两者联络很严密，所以我们可以将它们划分到一个效劳（你也可以尝试拆分它们，虽然我团体并不建议）。接上去，假如呼吁行业者在政府部门出台相关政策标准的之前，从业者一定要规范自己的行为准则健康有序的快速发展。我们有不同的通讯协议，如web interface、POP3、IMAP、SMAP，可以将每个协议的完成局部拆成对应的效劳。异样，信息存储，可以被抽离成独立的效劳。通讯录加上它的UI与它的API可以被抽离成一个独立的效劳。

最初，我们能够将整个邮件零碎拆离成15~20个独立效劳。关于恣意的恳求/操作，我们都可以将它映射到若干微效劳之上——比方，用户在表格里输出数据之后，点击了一个按钮，数据应该被保管在这个表格对应的数据库里。我们会用三到五个效劳组合来处置整个逻辑。

总结一下，将「效劳拆分到尽能够小」并不是我们的目的。假如你这样做了，只能阐明你将拆分效劳当作了你的首要业务，而无视了业务的交互性和为什么要拆分。依照业务逻辑与迭代频率区分，选择更合适本人的模块方式，才是微效劳的最佳理论。

（本文局部内容选自我邦「聊聊架构」，作者Andy Zhang，池建强修正润饰并增删局部内容）。