现象 | 问题 | 解决方案 |
---|---|---|
服务越来越多 | URL配置管理, F5硬件单点压力大 | 注册中心, 服务动态发现 |
服务间依赖关系复杂 | 自动绘制服务依赖 | |
调用量变大 | 容量评估 | 调用统计, 自动调整容量 |
服务分层 | 架构腐化, 循环依赖 | 服务暴露或引用,声明层次 |
服务接口文档, 约定,责任人 | 沟通成本太高 | 建立文档库 |
敏感信息泄露 | 服务安全, 授权 | 动态生成令牌,服务注册中心鉴权 |
服务被压垮 | 流量控制 | 流量控制 |
服务之间互相影响 | 服务如何隔离 | 服务路由 |
线上验证麻烦 | 线上隔离导致不好验证 | 自动验证 |
服务依赖web容器 | 其实不需要依赖 | |
服务开发人数多, 效率低 | IDE集成 | |
服务出现重复 | 重复开发, 线上上线混乱 | 上线审批 |
服务接口兼容性出现问题 | Technology Compatibility Kit, 保证兼容升级验证 | |
故障多, 上线就人心惶惶 | 没有区分优先级 | 功能降级?或者资源劣化?定义强弱依赖, 关键路径上服务的优化和容错 |
很多小服务的服务整合, 工作量太大 | 增加一个中间层,暴露一个新服务 | 服务编排引擎,内置简单的流程引擎 |
机器资源浪费 | 某些服务流量低,但是机器机房互备 | 容器技术, 服务隔离JVM,classloader |
单机上不小心停掉别人应用 | 服务部署交叉 | 自动化部署 |
机器利用率低 | 每个业务互备份,压力不均 | 容器技术, 自动扩容,自动部署 |
- 服务注册与发现
- 软负载均衡与容错
- 服务监控与统计
- 服务容量评估
- 服务上线审批
- 服务下线通知
- 服务负责人
- 服务文档
- 服务路由
- 服务编排
- 服务黑白名单
- 服务权限控制
- 服务依赖关系
- 服务分层架构
- 服务调用链跟踪
- 故障传导分析
- 服务降级
- 服务等级协定
- 服务自动测试
- 服务伪装容错
- 服务兼容性检测
- 服务使用情况报告
- 服务权重动态调整
- 服务负载均衡调整
- 服务映射
- 服务模板工程
- 服务开发IDE
- 服务健康检测
- 服务容器
- 服务自动部署
- 服务资源调度