微服务到底有多微？How big is a microservice?

关于这个问题，有人说用代码行数来衡量微服务到底有多微，我们都知道不同语言写的微服务行数肯定都不统一，这个显然行不通；还有人说用重写时间来衡量，什么意思呢？就是说一个微服务如果拉倒重来得多长时间，这个显然不是一个衡量标准。既然有的书籍提到了，我们在这里就提一下。

那么究竟用什么来划分微服务的边界呢？

我们认为应该从 具体的业务来考虑。其实还是和我们传统的一体化架构思维角度是一样的。总是先从业务功能去考虑一定不会出错的。

我们划分微服务首先应该要保证微服务的业务对立性。 那么这个独立性怎么去保证呢？也有很多的做法。

1、领域模型角度：

其中一种就是从领域模型角度考虑，就是将一个个领域模型作为独立的模块（或者叫单元）。比如产品、订单、客户。

2、业务行为角度：

还有一种角度是从业务行为考虑，比如 单点登录，生成全局唯一序列号，发送邮件等等。就是从业务使用场景来考虑。

关于这个从业务独立性划分，

Sam Newman强调说我们划分微服务应该基于Domain-Driven Design里的Bounded Context的概念。

那么我们的每个微服务对应的人力是多少呢？

关于这个，martin folwer说了这些话：

根据我们和一些微服务的从业者的交谈后得出，我们看到了很多不同size的微服务。根据Amazon的概念，微服务的最大尺寸遵循两个比萨团队（即整个团队可以用两个比萨饼喂食），意思是不超过12人。比较小的微服务size的规模是，我们看到有公司是这样的配置：一个6人团队支持6个服务。