微服务最初是由Martin Fowler和James Lewis在2014年共同提出的。 微服务的体系结构样式是一种使用一组小服务开发单个APP应用程序的方法。 每个服务都在自己的进程中运行，并使用轻量级机制进行通信。 通常是HTTP API，这些服务基于业务能力构建，可以通过自动化部署机制独立部署。 这些服务是用不同的编程语言实现的。
二、微服务优势：
1 .各项微服务小，可以聚焦指定的业务功能或业务需求。
2 .微服务可以由由两到五个开发者组成的小团队单独开发。
3 .微服务是松散耦合的、功能性的服务，无论是开发阶段还是部署阶段都是独立的。
4 .微服务可以用不同的语言开发。
5 .微服务容易被开发者理解，便于修改和维护，让团队更多关注自己的工作成果。 不合作就无法表达价值。
6 .微服务允许融合最新技术。
7 .微服务是业务逻辑的代码，不会与HTML、CSS或其他接口组件混合。
三.微服务体系结构的缺点
1 .运维要求高。 在单个体系结构中，只需要维护此项目，而在微服务体系结构中，项目由多个微服务组成，因此每个模块出现问题都会导致整个项目的行为异常，原因是哪个模块因为不能一步一步地用调试程序追踪，所以对承运人有很高的要求。
2 .方差的复杂性。 虽然在单体系结构中可以不使用分布式，但在微服务体系结构中分布式几乎是必须的技术，由于分布式本身的复杂性，微服务体系结构也变得复杂。
3 .接口调整成本高。 例如，用户微服务由订单微服务和电影微服务调用。 当用户微服务的接口发生重大变化时，所有依赖它的微服务都必须进行相应的调整。 由于微服务可能非常多，调整接口所带来的成本将明显上升。
4 .在重复劳动单体体系结构中，如果一个业务在多个模块中共同使用，我们可以抽象为一个工具类，直接从所有模块调用，但微服务却不行。 因为该微服务的工具类不能直接从其他微服务调用，所以必须为每个微服务构建这样的工具类，导致代码重复。