微服务属于什么?
一种架构风格。
软件架构大体经历了:
单体架构 → 面向服务的架构(SOA) → 微服务
1. 单体架构
特征:
单体架构是一种将所有功能打包在一个容器中运行的设计风格
一个实例中继承了一个系统的所有功能
通过负载均衡 软件 / 设备 实现多实例调用。
优点:
易开发、易调试、易部署
缺点:
- 可靠性差:某个模块bug可能导致会导致整个应用的崩溃。
- 不易协同:协同开发时,版本冲突频繁。
- 升级困难:牵一发而动全身。
2. 面向服务的架构(SOA)
特征:
是一种分布式服务架构,将应用程序的不同功能单元(服务)进行拆分,通过服务之间定义明确的接口和协议联系起来,进而实现跨 服务单元 / 系统 交互的能力。
优点:
- 松耦合:SOA 定义了良好的对外接口,通过网络协议提供对外服务,服务之间表现为松耦合性。
- 独立性:某个服务的内部结构和实现发生改变时,只要接口不变,不影响整个流程对外提供服务。
- 可重用:SOA 通过定义标准的对外接口,可以让多个适用方同时使用,增加服务的复用性。
挑战:
对着大型互联网公司和组织机构对大规模弹性部署和敏捷开发的虚修,SOA 之间难以应付。
同时,伴随着虚拟化技术、容器技术的不断发展,持续交付方法论的深入人心,微服务应运而生。
3. 微服务
特征:
以 “专注于单一责任与功能的小型功能区块(服务)” 为基础,服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通。每个服务都围绕具体的业务进行构建,并且能够被独立部署。
- 是一条架构方法和体系
- 由很多体量小、实现特定功能或业务的服务构成
- 服务松耦合,独立开发,独立部署
- 服务可以用不同语言开发
口语化描述:
微前端就是将不同的功能按照不同的维度,拆分成多个子应用,通过主应用来加载这些子应用。核心在于拆,拆完再合。
为什么需要微前端?
- 不同的团队开发同一个应用技术栈不同
- 每个团队都独立开发
- 项目中还需要老的应用
将一个应用划分成若干个子应用,将子应用打包成一个个的lib,当路径切换时,加载不同的子应用。这样每个子应用都是独立的,技术栈也不用做限制,解决前端协同开发的问题。
总结:子应用可以独立构建,运行时动态加载,主、子应用完全结构,技术栈无关,靠的是协议接入(子应用必须导出bootstrap、mount、unmount方法)