如何设计一个完善可用的服务框架

上一篇博客整理了一些关于服务框架基础知识的内容,这篇博客,从实际的生产需要出发,谈谈一个完善可用的服务框架,需要包含哪些功能。。。

PS:部分内容参考自《京东基础架构建设之路》

一个完善可用的RPC服务框架,需要包含以下几点:

框架组成 具体功能说明
服务注册中心 服务框架基础知识
管理端 接口管理+配置中心
统一的RPC框架 监控中心+分布式追踪+服务治理+网关

管理端

1、接口管理

提供统一的接口管理和查询入口,比如公共wiki或者类似swagger之类的系统。

功能:定义接口,包括接口描述、方法定义、字段定义甚至接口支持的最大并发数等信息。

2、配置中心

提供统一的配置管理,这里主要指服务端的一些相关配置。

功能:分组配置、路由策略、黑白名单、降级限流开关、timeout、重试次数可动态变化的参数。

优点:服务提供者和调用者不需重启服务即可进行配置的变更。

例子:携程开源的Apollo配置管理中心,或阿里开源的Nacos,目前在业内被多家互联网及银行金融类企业采用。

RPC框架

一、监控中心

1、监控服务主要关注接口维度和工程实例维度的数据,比如:JVM、内存、CPU、I/O等;

2、通过定时任务,上报不同接口的调用次数、耗时、异常信息以及相关服务的新建连接数、最大连接数、吞吐量等信息;

3、通过可视化等方式,实时展示相关服务的状态,健康检查、监控预警等;

二、分布式追踪

与监控中心有所区别的是,全链路追踪主要是以调用链的模式对服务进行调用关系的跟踪和分析,一般通过埋点、agent探针等方式进行追踪的数据输出;

例子:全链路工具Skywalking,就是一个开源的调用链模式的追踪分析工具,UI图如下:

更多参考:Skywalking分布式追踪系统

三、服务治理

1、服务路由

权重:机器配置高的权重高,配置低的权重低;还有根据服务的重要程度分配权重等;

IP路由:比如某些特定地址的机器只能访问配置的几台特定机器;

参数路由:比如根据方法名进行读写分类,或根据参数不同访问不同的节点;

2、调用授权

应用授权:只有授权后的应用才可以调用某一组服务;

token:只有token校验通过才可以调用对应的服务;

黑白名单:黑名单用户无法访问某些服务,白名单用户可以不用鉴权既可访问服务;

3、调用限流

服务端限流:服务端根据漏斗模型或者服务的最大处理能力进行限流措施,设置初始值以及根据访问流量变化,同等步长递增,最大访问量为某个安全阈值即可;

客户端限流:根据客户端身份标识,比如不同会员等级,进行调用次数及是否优先提供服务的限流;

4、上线发布

灰度发布:一种平滑的上线发布方式,再次基础上可以进行A/B测试。

蓝绿发布:V1 版本称为蓝组,V2 版本称为绿组,发布时通过 LB 一次性将流量从蓝组直接切换到绿组。特点是全量切换,升级切换和回退速度快。

更多关于发布上线模式的内容,可参考这里:灰度发布、滚动发布、蓝绿发布到底有什么区别?

5、限流降级

Mock:当服务不可用、异常等情况下返回配置好的数据,一般在测试场景使用率较高。

限流:通过在网关入口设定最大访问阈值等方式,控制流入系统服务的请求,保证服务的正常可用。

降级:根据分配的服务权重,在系统压力超过一定阈值时降低权重较低的服务权重,保证核心重要服务的可用性。

熔断:设定timeout参数,当流入数据超过设定阈值,使其超时,重置连接,保证服务的可用性。

四、网关

网关为业务的接入层,RPC框架大部分情况下是内部调用,而网关可以提供以下功能:

统一的鉴权服务;

限流服务;

协议转换:将外部访问的请求协议转换为内部统一的可处理的协议;

Mock:为测试提供服务、降级处理等;

其他:比如请求内容解析、请求封装;

以为即为完善可用的服务框架相关知识,具体实践请自行探索或参考其他资料。。。

原文地址:https://www.cnblogs.com/imyalost/p/10343203.html

时间: 2024-10-26 18:28:00

如何设计一个完善可用的服务框架的相关文章

如何设计一个易用的MVC框架

导言 把一件简单的事情做复杂很容易,把一件复杂的事情做简单却不易.在计算机的世界里, 冯.诺依曼把复杂的电脑简化为:存储器,控制器,运算器和I/O设备; 丹尼斯·里奇把晦涩的汇编语言简化为258页的<C程序设计语言>; 詹姆斯高斯林把繁琐的跨平台编码简化为256条字节码指令: 对我们大部分人而言,把简单的事情做简单就足够了. 关于框架 框架是对某一类共通业务的封装,框架设计应该遵循几个基本的原则:1 易用性 2 稳定性3 扩展性,框架从来都是给别人用 的,框架的学习成本与他的复杂度成正比,如果

8.如何自己设计一个类似 Dubbo 的 RPC 框架?

作者:中华石杉 面试题 如何自己设计一个类似 Dubbo 的 RPC 框架? 面试官心理分析 说实话,就这问题,其实就跟问你如何自己设计一个 MQ 一样的道理,就考两个: 你有没有对某个 rpc 框架原理有非常深入的理解. 你能不能从整体上来思考一下,如何设计一个 rpc 框架,考考你的系统设计能力. 面试题剖析 其实问到你这问题,你起码不能认怂,因为是知识的扫盲,那我不可能给你深入讲解什么 kafka 源码剖析,dubbo 源码剖析,何况我就算讲了,你要真的消化理解和吸收,起码个把月以后了.

微服务配置内容—&gt;如何创建一个高可用的服务注册中心

前言:首先要知道什么是一个高可用的服务注册中心,基于spring boot建成的服务注册中心是一个单节点的服务注册中心,这样一旦发生了故障,那么整个服务就会瘫痪,所以我们需要一个高可用的服务注册中心,那么在Eureka中,我们通过集群来解决这个问题.啥叫集群呢?就是多配几个,一个服务注册中心挂了,还有另一个. 另外要注意jdk的版本需要1.8或1.8以上,否则无法执行. 1 但这里我遇到了一个奇怪的问题:本来我的jdk版本是1.6的,我需要更换.但是怎么配置环境 2 变量,在命令行输入java

一个简单的通讯服务框架(大家发表意见一起研究)JAVA版本

最近研究下java语言,根据一般使用的情况,写了个连接通讯服务的框架: 框架结构 C-Manager-S; 把所有通讯内容抽取成三个方法接口:GetData,SetData,带返还的Get; 所有数据都处理为byte[];客户端与服务端和管理器以及服务端有多重处理模式 管理信息: 1.不需要中心管理器:服务端启动时向客户端广播自己绑定的地址:接收数据:客户端使用时广播一次请求,向所有服务端获取服务信息: 2.管理中心:客户端向管理器请求服务信息:服务端向管理器注册地址:根据需要,可以把客户端传递

如何设计一个高可用系统?要考虑哪些地方?

本文已经收录自笔者开源的 JavaGuide: https://github.com/Snailclimb (69k+Star[Java学习+面试指南] 一份涵盖大部分Java程序员所需要掌握的核心知识)如果觉得不错的还,不妨去点个Star,鼓励一下! 一篇短小的文章,面试经常遇到的这个问题.本文主要包括下面这些内容: 高可用的定义 哪些情况可能会导致系统不可用? 有些提高系统可用性的方法?只是简单的提一嘴,更具体内容在后续的文章中介绍,就拿限流来说,你需要搞懂:何为限流?如何限流?为什么要限流

设计高可用Web服务

高可用的设计可以说是web服务架构的目标,如果服务达不到高可用,万一出现故障将会对产品带来重大的负面影响.高可用的架构就是能够让服务在任何情况下都能正常响应,比如双十一的淘宝,面对激增的洪峰照样正常工作:而聚美三周年时服务器的宕机恰好是高可用的反例. 什么是高可用 可用性:在应用工作周期中可用时间的百分比 不可用:应用无法访问,服务中断应用访问非常缓慢 高可用:服务一直正常可用,快速响应 Tags SPoF:单点故障 Failover:故障转移 Disaster Recovery:灾难恢复 Lo

从 Spring Cloud 看一个微服务框架的「五脏六腑」

原文:https://webfe.kujiale.com/spring-could-heart/ Spring Cloud 是一个基于 Spring Boot 实现的微服务框架,它包含了实现微服务架构所需的各种组件. 注:Spring Boot 简单理解就是简化 Spring 项目的搭建.配置.组合的框架.因为与构建微服务本身没有直接关系,所以本文不对 Spring Boot 进行展开.另外本文有一些例子涉及到 Spring 和 Spring Boot,建议先了解一下 Spring 和 Spri

Dubbo分布式服务框架

Dubbo (开源分布式服务框架) 编辑 本词条缺少信息栏,补充相关内容使词条更完整,还能快速升级,赶紧来编辑吧! Dubbo是 [1]  阿里巴巴公司开源的一个高性能优秀的服务框架,使得应用可通过高性能的 RPC 实现服务的输出和输入功能,可以和 [2]  Spring框架无缝集成. Dubbo是一款高性能.轻量级的开源Java RPC框架,它提供了三大核心能力:面向接口的远程方法调用,智能容错和负载均衡,以及服务自动注册和发现. 目录 1 主要核心部件 2 工作原理 3 特性 主要核心部件

微服务框架Dubbo与Springcloud的区别

微服务框架Dubbo与Springcloud的区别 微服务主要的优势如下: 1.降低复杂度 将原来偶合在一起的复杂业务拆分为单个服务,规避了原本复杂度无止境的积累.每一个微服务专注于单一功能,并通过定义良好的接口清晰表述服务边界. 每个服务开发者只专注服务本身,通过使用缓存.DAL等各种技术手段来提升系统的性能,而对于消费方来说完全透明. 2.可独立部署 由于微服务具备独立的运行进程,所以每个微服务可以独立部署.当业务迭代时只需要发布相关服务的迭代即可,降低了测试的工作量同时也降低了服务发布的风