建设银行网站安全分析,手机网站显示建设中,网站建设与网页设计课,如何设计好的网页一、HTTP 和 RPC
首先#xff0c;http 与 rpc 有什么区别这个问题不太严谨#xff0c;因为这俩就不是一个层级的东西。
HTTP
这个大家太熟悉了吧#xff1f;日常接触最多的恐怕就是各种http协议的接口了。
没错#xff0c;http它是一个协议。
其他在这里就不打算铺开了…一、HTTP 和 RPC
首先http 与 rpc 有什么区别这个问题不太严谨因为这俩就不是一个层级的东西。
HTTP
这个大家太熟悉了吧日常接触最多的恐怕就是各种http协议的接口了。
没错http它是一个协议。
其他在这里就不打算铺开了以前整理过一些内容有需要的可以跳转翻翻看
一、http介绍、TCP/IP 协议族二、IPTCP 和 DNS、三次握手三、HTTP 协议基础、四次挥手四、HTTP 缺点五、HTTPS 中的加密、证书介绍不一直使用 HTTPS 的原因
RPC
RPC 是一种技术的代名词全称是远程过程调用。
远程那是不是也有本地过程调用
没错举个例子说明一下
本地过程调用你的电脑上启动了一个服务A运行程序的时候服务A里的各种方法的互相调用就是本地了。远程过程调用而隔壁小王也启动了一个服务B他还说他里面提供了一个功能非常劲爆的方法你也想去调用这就是远程了。
而至于你怎么调用到小王服务器里的方法那就是个实现方式的问题了。你为了简单直接走http协议也行。如果觉得http满足不了需求那么也可以基于tcp自定义一个协议。
远程调用过程
远程调用过程大概就是下图所示 二、DSF
在工作中我发现公司有不少应用的名字是 DSF 打头的DSFDistributed Service Framework其实就是指分布式服务框架。
简单介绍 2 个点为什么要用到分布式、这套DSF的包含的内容。
为什么要用到分布式
为什么要用到分布式服务换个方式问那就是分布式解决了什么问题。
首先分布式架构是由单体架构演进而来我司的业务系统也不例外。业务早期为了降低开发成本实现快速上线通常使用单体架构所有的业务模块都在同一个应用里。
随着业务规模的扩张单体应用的缺点就暴露出来比如
系统耦合性高当后面增加的功能越来越多代码量巨增的时候之前某个主程脑海中划分好的模块边界可能越来越模糊导致调用关系混乱。改一赠二出现越来越多经常存在开发修改了某个功能而导致其他的功能有问题。某个功能有问题整个一起回滚。语言单一不能根据场景选择更合适的语言。比如其中有个模块系统主要是大数据分析用 python 自然更加合适因为它有丰富的类库。系统不易于拓展部署比如系统中有一个功能流量很大顶不住了就要加机器那么在新机器上还是部署整个应用不能单独的部署这个大流量的服务会造成一定的资源浪费。 。。。
为了解决这些问题于是把之前的业务进行垂直拆分成多个系统。系统与系统之间通过网络交互来完成各项业务处理每个系统互相独立可以单独部署。这种多个组件合作对外提供服务的形式就是分布式了。
但是分布式同样也有它的缺点
从之前的单应用调用现在变成了多个应用直接的交互调用链路变长带来了网络开销同时也给定位问题增加了难度。为了让你的应用更可靠还有考虑其他的异常情况比如调用失败、因某些问题导致的高频调用对此还得做些 限流、熔断之类的措施。出现问题可能会涉及多个服务的回滚互相之间会有影响。环境变复杂了增加了测试的复杂度。 。。。
简单来说分布式帮我们克服了单体带来的瓶颈但是为了分布式服务的稳定性我们需要考虑更多的东西。
DSF包含的内容
那么一套分布式服务平台都有哪些内容这里简单列举一下以我司自研为例
服务注册服务提供方上传契约信息契约中包含服务组信息、服务信息、API信息等。服务发现服务消费方寻址基于某种粒度可以找到需要。服务调用自定义超时时间、失败重试次数等支持同步、异步调用等。负载均衡比如支持轮询策略。网关还可以通过网关对外提供一些rest api调用。健康检查对服务提供方实例进行健康检查。服务拓扑应用调用的上下游链路拓扑图。服务监控展示服务运行状态、调用指标等。报警当某个服务的实例异常数超过阈值触发报警。限流用于保护系统。web前台方便查看各种信息各种常用功能的入口。 ...
三、Dubbo
对于分布式服务框架如果有自研能力的话可以结合公司业务实际情况进行高度定制化。如果初期不具备这样的条件很多公司会选择成熟的开源框架直接使用dubbo 就是这样的框架。
Dubbo 是阿里巴巴 2011年开源的一个基于 Java 的 RPC 框架它实现了面向接口的代理 RPC 调用并且可以配合 ZooKeeper 等组件实现服务注册和发现功能并且拥有负载均衡、容错机制等。
dubbo 架构
这是官方文档的架构图描述了 Dubbo 微服务组件与各个中心的交互过程。 Registry 注册中心协调 Consumer 与 Provider 之间的地址注册与发现。ConfigCenter 配置中心存储 Dubbo 启动阶段的全局配置保证配置的跨环境共享与全局一致性负责服务治理规则路由规则、动态配置等的存储与推送。Metadata 元数据中心接收 Provider 上报的服务接口元数据为 Admin 等控制台提供运维能力如服务测试、接口文档等作为服务发现机制的补充提供额外的接口/方法级别配置信息的同步能力相当于注册中心的额外扩展。
以上三个中心并不是运行 Dubbo 的必要条件用户完全可以根据自身业务情况决定只启用其中一个或多个以达到简化部署的目的。通常情况下所有用户都会以独立的注册中心 开始 Dubbo 服务开发而配置中心、元数据中心则会在微服务演进的过程中逐步的按需被引入进来。
所以如果想快速实现一个分布式服务框架就可以基于dubbo的方案来进行开发既可以拿来就用后续也可以进行二次开发。
