mirror of
https://github.com/doocs/advanced-java.git
synced 2025-01-15 05:30:11 +08:00
102 lines
2.4 KiB
Markdown
102 lines
2.4 KiB
Markdown
# 微服务治理策略
|
|
|
|
* Author: [HuiFer](https://github.com/huifer)
|
|
* Description: 该文简单介绍微服务的治理策略以及应用技术
|
|
|
|
## 服务的注册和发现
|
|
|
|
> 解决问题: 集中管理服务
|
|
|
|
> 解决方法: eureka 、zookeeper
|
|
|
|
## 负载均衡
|
|
|
|
> 解决问题: 降低服务器硬件压力
|
|
|
|
> 解决方法: nginx 、 Ribbon
|
|
|
|
## 通讯
|
|
|
|
> 解决问题: 各个服务之间的沟通桥梁
|
|
|
|
> 解决方法 :
|
|
> - 同步消息
|
|
> 1. rest
|
|
> 1. rpc
|
|
> - 异步消息
|
|
> 1. MQ
|
|
|
|
## 配置管理
|
|
|
|
> 解决问题: 随着服务的增加配置也在增加, 如何管理各个服务的配置
|
|
|
|
> 解决方法: nacos 、 spring cloud config 、 Apollo
|
|
|
|
## 容错和服务降级
|
|
|
|
> 解决问题: 在微服务当中，一个请求经常会涉及到调用几个服务，如果其中某个服务不可以，没有做服务容错的话，极有可能会造成一连串的服务不可用，这就是雪崩效应.
|
|
|
|
> 解决方法: hystrix
|
|
|
|
## 服务依赖关系
|
|
|
|
> 解决问题: 多个服务之间来回依赖, 启动关系的不明确
|
|
|
|
> 解决方法:
|
|
|
|
> 1. 应用分层: 数据层, 业务层 数据层不需要依赖业务层, 业务层依赖数据, 规定上下依赖关系避免循环圈
|
|
|
|
## 服务文档
|
|
|
|
> 解决问题: 降低沟通成本
|
|
|
|
> 解决方法: swagger 、 java doc
|
|
|
|
## 服务安全问题
|
|
|
|
> 解决问题: 敏感数据的安全性
|
|
|
|
> 解决方法: oauth 、 shiro 、 spring security
|
|
|
|
## 流量控制
|
|
|
|
> 解决问题: 避免一个服务上的流量过大拖垮整个服务体系
|
|
|
|
> 解决方法: Hystrix
|
|
|
|
## 自动化测试
|
|
|
|
> 解决问题: 提前预知异常, 确定服务是否可用
|
|
|
|
> 解决方法: junit
|
|
|
|
## 服务上线, 下线的流程
|
|
|
|
> 解决问题: 避免服务随意的上线下线
|
|
|
|
> 解决方法: 新服务上线需要经过管理人员审核. 服务下线需要告知各个调用方进行修改, 直到没有调用该服务才可以进行下线.
|
|
|
|
## 兼容性
|
|
|
|
> 解决问题: 服务开发持续进行如何做到兼容
|
|
|
|
> 解决方法: 通过版本号的形式进行管理, 修改完成进行回归测试
|
|
|
|
## 服务编排
|
|
|
|
> 解决问题: 解决服务依赖问题的一种方式
|
|
|
|
> 解决方法: docker & k8s
|
|
|
|
## 资源调度
|
|
|
|
> 解决问题: 每个服务的资源占用量不同, 如何分配
|
|
|
|
> 解决方法: JVM 隔离、classload 隔离 ; 硬件隔离
|
|
|
|
## 容量规划
|
|
|
|
> 解决问题: 随着时间增长, 调用逐步增加, 什么时候追加机器
|
|
|
|
> 解决方法: 统计每日调用量和响应时间, 根据机器情况设置阈值, 超过阈值就可以追加机器
|