1、微服务
微服务架构风格把应用划分成若干个服务,每个服务有自己独立的进程,服务之间通过轻量级传输机制进行交互
2、微服务特征
微服务架构使用服务作为组件化的单元
2.1 、对开发人员来说
- 组件化软件开发中的基本实践
- 在java应用开发中,组件通常以 JAR 文件的形式出现
- Maven 仓库中包含了海量的第三方可可供使用
- java 开发人员都熟悉这种使用组件的方式
2.2、微服务本身
- 在微服务 架构中,组件的单元变成了服务
- 服务运行在独立的进程中,需要使用类似 http 这样的进程间的通信方式
- 每个服务可以独立部署,使用 API 访问规范描述其公开接口
- 一个微服务可以通过 API 访问另外的微服务,并不能访问内部的实现代码
2.3、微服务的分工
- 原有 3 层开发 (前端开发、后端开发、数据库管理)
- 以服务单元进行组织,每个服务与特定的业务需求相对应
- 每个服务可以独立部署,采用不同的技术栈,只要满足 API 的调取规则即可
- 采用去中心化的数据存储,每个服务都有自己专有的数据存储
3、微服务架构问题
- 使用微服务架构后,应用变成了一个分布式系统
- 在分布式系统中,服务通过进程间通讯方式来交互,例如使用REST API 或 gRPC 远程方法调用
- 当需要调用一个微服务时,首先需要通过服务发现机制找到微服务的实际地址,然后再发送调用请求
- 目标微服务有可能处于离线状态,或者因为负载过大而延迟过高,对不同的情况,需要有相应的处理策略
4、微服务架构实现
因素 | 说明 |
---|---|
配置管理 | 把服务配置从代码实现中分离出来 |
服务发现 | 发现其他微服务来完成协作 |
负载均衡 | 微服务可以 扩展成多个实例,多个实例之间通过负载均衡来处理请求 |
API网关 | 微服务可以扩展成多个实例,多个实例之间通过负载均衡来处理请求 |
安全 | 安全相关的需求通常由API网关来实现 |
日志管理 | 收集不同微服务实例的日志,并形成统一的视图,方便错误追踪 |
性能分析 | 收集不同微服务的运行状态和性能指标,可以实时监控系统运行状态,并发现性能瓶颈 |
分布式追踪 | 追踪每个外部请求涉及到的服务之间的调用关系 |
回弹性和错误处理 | 处理服务的失败 |
自动扩展 | 根据负载均衡情况自动进行水平扩展,当服务的实例出现问题时,可以自动重启 |
打包、部署和调度 | 打包指把服务封装成独立可部署的单元,部署是指对微服务采用灵活的部署方式,包括滚动更新,调度是指把服务实例安排到适合的节点上运行 |
任务管理 | 执行定期任务 |
主要微服务技术栈
- Netflix — Netflix OSS栈
- Spring Cloud — 开源项目组成开发套件(配置管理、微服务发现、断路器 等)
- Kubernetes — 管理容器化工作负载和服务的平台,同时也是容器编排平台