微服务的提出者
Martin Fowler大师的主页:https://martinfowler.com
什么是微服务
微服务这种架构风格是一种将单个应用程序开发为一组小服务的方法,每个小服务都在自己的进程中运行并采用轻量级机制(通常是HTTP资源API)进行通信。这些服务围绕业务功能构建,并且可以由全自动部署机制独立部署。对这些微 服务我们仅做最低限度的集中管理。它可以用不同的编程语言编写并使用不同的数据存储技术。
微服务架构是一种架构模式,它提倡将单一应用程序划分成一组 小的服务,服务之间互相协调、互相配合,为用户提供最终价值。 每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API) 。每个服务 都围绕着具体业务进行构建,并且能够被独立地部署到生产环境 类生产环境等。另外,应尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语 言、工具对其进行构建。
微服务是一种架构风格, 一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。 在所有情况下,每个任务代表着一个小的业务能力任务。
单体应用与微服务
单体模块在扩展的某一进程时必须的把整个应用进程进行扩展 每台机器扩展的完全一样。
微服务在扩展的时候需要什么复制什么并且可以在项目上进行延伸 每台机器扩展的可以完全不一样。
单体应用的缺点导向了微服务架构风格出现:构建应用程序为服务套件。除了服务是可独立部署、可独立扩展的之外,每个服务都提供一个固定的模块边界。甚至允许不同的服务用不同的的语言开发,由不同的团队管理。
微服务具备的特性
- 每个微服务可独立运行在自己的进程里
- 一系列独立运行的微服务共同构建起了整个系统
- 每个服务为独立的业务开发,一个微服务一般完成某个特定的功 能,比如:订单管理、用户管理等
- 微服务之间通过一些轻量的通信机制进行通信,例如通过REST API或者RPC的方式进行调用
微服务设计原则
- 单一职责原则
- 服务自治原则
- 轻量级通信原则
- 接口明确原则
微服务的优点
- 易于开发和维护
- 启动较快
- 局部修改容易部署
- 技术栈不受限
- 按需伸缩