微服务、微服务架构和微服务框架
- 微服务架构是将复杂的系统使用组件化的形式进行拆分，并使用轻量级通讯方式进行整合的一种设计方法
- 微服务是通过这种架构设计方法拆分出来的一个独立的组件化的应用。
- 微服务框架是通过这种架构设计方法实现的一组软件组件，是一种可复用的体系结构
- 微服务架构定义的精髓：“分而治之，和而用之”
单体(整体)架构的不足
- 复杂性逐渐增高
- 技术债务逐渐上升
- 维护成本大
- 持续交互周期长
- 可扩展性差
微服务架构的特性
- 单一职责（高内聚、低耦合的服务单元）
- 轻量级的通信（语言无关、平台无关的通信方式）
- 独立性（独立开发、测试和部署）
- 进程隔离（每个服务运行在独立的进程中，可跨主机部署）
微服务的不足
- 运维要求较高（需要知道是哪个模块出的问题）
- 分布式的复杂性（分布式本身具有复杂性）
- 接口调整成本高（一旦接口发生变动，所有依赖于它的微服务都要做相应的改变）
- 重复劳动（多个微服务上可能建立相同的工具类）
对比
| 传统单体架构 | 分布式微服务化架构 | |
|---|---|---|
| 新功能开发 | 需要时间 | 容易开发和实现 |
| 部署 | 不经常且容易部署 | 经常发布，部署复杂 |
| 隔离性 | 故障影响范围大 | 故障影响范围小 |
| 架构设计 | 初期设计选型难度大 | 设计逻辑难度大 |
| 系统性能 | 响应时间快，吞吐量小 | 响应时间慢，吞吐量大 |
| 系统运维 | 运维简单 | 运维复杂 |
| 新人上手 | 学习曲线大（应用逻辑） | 学习曲线大（架构逻辑） |
| 技术 | 技术单一而且封闭 | 技术多样而且开放 |
| 测试和差错 | 简单 | 复杂（每个服务都要进行单独测试，还需要集群测试） |
| 系统扩展性 | 扩展性差 | 扩展性好 |
| 系统管理 | 重点在于开发成本 | 重点在于服务治理和调度 |
为什么使用微服务架构
- 开发简单
- 快速响应需求变化（适合敏捷开发）
- 随时随地更新
- 系统更加稳定可靠 （高可用的分布式环境）