微服务   即微小的服务，较小且独立的功能

微服务最早由Martin Fowler（马丁·福勒）与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。

服务拆分

拆分的颗粒度没有标准答案，只能根据经验，实际，方法论等，合理的进行拆分。

纵向拆分：从业务纬度进行拆分。标准是按照业务的关联程度来决定，关系比较密切的业务适合拆分为一个微服务，而功能相对比较独立的业务适合单独拆分为一个微服务。

横向拆分：从公共且独立功能纬度拆分。标准是按照是否有公共的被多个其他服务调用，且依赖的资源独立不予其他业务耦合。

容易出现的问题：

1. 服务划分过细，服务间关系复杂
2. 服务数量太多，团队效率急剧下降
3. 没有自动化部署支撑，无法快速交付
4. 没有服务治理，微服务达到一定数量，后台管理混乱

三个火枪手原则

如果你的团队只有9个人，那么分为3个是合理的，如果有18个人。那么6个服务是合理的。

为什么呢，这就是三个火枪手原则。三个火枪手原则就是一个微服务由三个人负责开发。一般来说，在进行微服务架构时，根据团队规模来划分微服务数量是合理的。

从系统规模来讲，3 个人负责开发一个系统，系统的复杂度刚好达到每个人都能全面理解整个系统，又能够进行分工的粒度；如果2个人开发一个系统，系统复杂度不够；如果4个人甚至更多人开发一个系统，系统复杂度又会无法让研发人员对系统的细节都了解很深。

从团队管理来说，3个人可以形成一个稳定的备份，即使1个人有事不在，2个人也可以支撑；如果2个人的话，少了一个人剩余的1个人压力就很大；如果是1个人就更惨了

从技术角度，3个人的技术小组能够形成有效的讨论，能快速达成一致意见；如果是2个人，可能会有意见无法统一问题；如果4个人或更多，就会出现有的成员不认真讨论，开会划水。

AKF原则
AKF 把系统扩展分为以下三个维度：

X 轴：直接水平复制应用进程来扩展系统，将系统复制多份，即加机器得方式，大大提高系统的总体容量、解决单点问题等（A+A+A+A）
Y 轴：将功能拆分出来扩展系统。微服务经常采用的按照业务逻辑拆分（B+C=A）
Z 轴：基于用户信息扩展系统。 将数据做分片拆分