微服务

微服务是一种软件架构风格

软件系统架构演进历史：单体架构 -> 面向服务架构（SOA）-> 微服务

单体架构

单体架构是一种将所有功能打包在一个容器中运行的设计风格，一个实例中集成了一个系统的所有功能，通过负载均衡软件/设备实现多实例调用。

优点：易开发、易调试、易部署

缺点：可靠性差（某个bug可能会导致整个模块的崩溃）、不易协同（协作开发时，版本冲突频繁）、升级困难（牵一发而动全身）

面向服务的架构（SOA）

面向服务的架构（SOA）：是一种分布式服务架构的常见方式，它将应用程序的不同功能单元（成为服务）进行拆分，并通过这些服务之间定义明确的接口和协议联系起来，进而实现跨服务单元/系统交互的能力。

优点：松耦合（SOA定义了良好的对外接口，通过网络协议对外提供服务，服务之间表现为松耦合性）、独立性（某个服务的内部接口和实现发生改变时，只要接口保持不变，不影响整个流程对外提供服务）、可重用（SOA通过标准地定义接口，可以让多个使用方同时使用，增加服务的可重复使用性）

挑战：随着大型互联网公司和组织机构对大规模弹性部署和敏捷开发的需求，面向服务的架构（SOA）逐渐难以应付。 同时，伴随着虚拟化技术、容器技术的不断发照，持续交付方法论的深入人心，微服务应运而生。

微服务

微服务（Microservices）是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块（即服务）为基础，服务之间互相协调，相互配合，为用户提供最中价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通。每个服务都围绕具体业务进行构建，并且能够被独立部署。

是一套架构方法和体系

由很多体量小实现特定功能或业务的服务构成

服务松耦合，独立开发，独立部署

服务可以用不同语言开发

#微服务比SOA的优势：复用率更高、快速响应、弹性扩展、支持异构

微服务要解决的问题

服务划分

服务注册与调用

延迟队列

服务熔断处理

缓存设计

分布式事务实现

服务的划分原则

业务边界清晰： 各服务有清晰的责任和边界，一个服务对应一块业务，服务间多为单向依赖

最小化地变更：新增或变更业务上有很明确的服务对应，某一业务需求地变更受影响的服务应该尽可能地少

更大化地复用：服务设定要考虑复用的场景，应该尽可能最大化地实现服务复用