想弄懂这个问题，可以看下马丁福乐的论文。论文地址如下https://martinfowler.com/articles/microservices.html
简单归纳，是一种将单个应用程序开发为一组小服务的方法，每个小服务都在自己的进程中运行并与轻量级机制（通常是HTTP资源API）进行通信。这些服务围绕业务功能构建，并且可以由全自动部署机制独立部署。这些服务的集中管理几乎没有，可以用不同的编程语言编写并使用不同的数据存储技术。
这样看还是有点蒙。我们先来看看传统的服务构建模式。
下图是最简单的传统软件建构模式。UI提供用户访问的界面，对web系统来讲，通过浏览器来访问网站界面，js等脚本来通过http来访问后台服务，服务读取数据库数据，并将数据进行各种逻辑处理，返回给UI，展现给用户。
随着业务量的增长，单台服务无法支撑整个业务，我们会对原有的业务进行水平扩展，我们系统可能会变成如下形态。我们水平扩展了服务。这样带来哪些问题呐，我能想到的：
1、服务整体水平扩张，粒度不够精细。比如我们一个服务里面某些业务根本不常用，没必要进行扩张，但是因为整体的架构被迫跟着扩张了。
2、我想更新某个服务的某个功能，导致整体都要进行更新
我们再来看一下微服务的架构。微服务架构模式，将单个服务从原有整体中拆分出来，形成一组单一功能的服务。
从图中也可以看出，每个服务都有牢固的独立的边界，因此他们可以独立部署，甚至使用不同语言进行开发，不同团队进行维护。
这幅图讲的是，UI团 逻辑团队 数据库团队，各自负责各自的模块构建微服务系统，微服务的重点放在了中间的技术团队。这样导致了
协调困难。最微小的改变都需要夸部门或团队。
这幅图将团队人员按照业务进行划分，人员紧密在一起负责独立的一块服务。减少了微服务跨部门协作的困难。
细分的微服务方法不同，分为围绕业务能力组织的服务 。此类服务针对该业务领域采用软件的广泛实施，包括用户界面，持久性存储和任何外部协作。因此，团队是跨职能的，包括开发所需的全部技能：用户体验，数据库和项目管理。
