网站建设黑客篡改深圳注册公司新政策

当前位置： 首页 > news >正文

网站建设黑客篡改,深圳注册公司新政策,中国空间站天宫课堂,seo方案书案例是什么#xff1f; Dubbo是阿里巴巴开源的基于Java的高性能RPC#xff08;一种远程调用#xff09;分布式服务框架#xff0c;致力于提供高性能和透明化的RPC远程服务调用方案#xff0c;以及SOA服务治理方案#xff0c;它提供了三大核心能力#xff1a;面向接口的远程…是什么 Dubbo是阿里巴巴开源的基于Java的高性能RPC一种远程调用分布式服务框架致力于提供高性能和透明化的RPC远程服务调用方案以及SOA服务治理方案它提供了三大核心能力面向接口的远程方法调用智能容错和负载均衡以及服务自动注册和发现。 每天为2千多个服务提供大于30亿次访问量支持并被广泛应用于阿里巴巴集团的各成员站点以及别的公司的业务中 简单的来说Dubbo就是个服务框架如果没有分布式的需求其实是不需要用的只是在分布式的时候才有Dubbo这样的分布式服务框架的需求 并且本质上是个远程服务调用的分布式框架告别Web Service模式中的Wsdl以服务者与消费者的方式在Dubbo上注册 Dubbo官网Apache Dubbo 核心组件 Remoting: 网络通信框架实现了 sync-over-async 和 request-response 消息机制. RPC: 一个远程过程调用的抽象支持负载均衡、容灾和集群功能 Registry: 服务目录框架用于服务的注册和服务事件发布和订阅
工作原理 生产者启动Dubbo容器生产服务对象 生产者把生成的服务发布到注册中心 消费者向注册中心订阅服务把发布的服务下载到本地缓存订阅服务后本地缓存会自动更新生产者发布的服务 当消费者需要调用服务时按照RPC协议要求向生产者发起服务的调用 生产者把返回的对象交给Dubbo容器进行序列化处理后返回给消费者 消费者接收到返回的数据后对其反序列化得到Java对象 监视器对服务性能做监控统计
注意注册中心和监视器都不是必须的可以缺少。如缺少注册中心后消费者就不能自动更新生产者发布的服务信息当生产者信息发生改变时消费者很可能调用服务失败。比较出名的注册中心有zookeepereruka 我们的生产者服务在注册中心注册并被消费者拉取到之后该生产者会在本地做一个缓存因此即使后续注册中心挂掉了只要之前消费者是调用过该服务的那么消费者依旧可以在本地缓存中拉取到生产者服务 为什么 系统架构的演变史 B/S软件架构的出现标志着web开发时代的到来当初应用都是比较简单功能单一访问量少。这些因素就决定了当年的应用结构是比较简单的 随着家用电脑的普及互联网的兴起上网的人越来越多逐渐显得简单的架构无法支撑应用程序的正常运行软件科学家们就开始探讨如何去设计软件的架构最初比较突出的两大问题在于1台服务器无法保证应用程序和数据库程序两个老虎的性能科学家就提出把应用程序和数据库程序分别安装在2台服务器中通过网络来进行数据传输再通过应用程序中加本地缓存的方式来解决不常变动数据的查询性能问题此时出现了最早期的分布式系统架构 伴随着大数据时代的到来这种简单是分布式系统架构也开始扛不住了服务器宕机成了常见的事情科学家又开始探索如何提高系统的稳定性和可用性于是提出了应用服务集群和数据库服务器集群通过负载均衡的方式来维持系统的高可用和稳定性以应对这个时代的高并发 在某些业务中关系型数据库明显不适合如点赞评论全文检索等。这些业务场景使用关系型数据库来完成会严重的影响数据库的性能科学家们又拓展出非关系型数据库NoSQL用于项目中的某个特殊的业务场景去弥补关系型数据的短板此时这样的系统架构基本满足当前时代下的需求 微服务应用演变史 JavaEE应用三层架构取得巨大成功后在很长的一段时间内都没有出现过问题直到大数据时代的到来某些数据量巨大的公司开始遇到了新的挑战。某些业务方法频繁调用需要配置大量的资源某些业务方法很少调用只需配置少量资源如商城应用中的服务 在商城的应用中订单服务积分服务商品服务的使用频率远远大于其他服务如果仅仅通过布置多台服务器的方式来缓解压力的造成的问题此时会造成服务器成本的大量提升并且资源得不到充分的利用造成浪费遇到某个关系型数据库不好处理的业务场景在技术选择的时候也要充分去考虑系统稳定和冲突问题于是科学家们又探索出基于服务的分布式应用架构服务拆分越细数量就越多这种应用架构就是当下最热门的微服务应用架构。目前比较成熟社区活跃的微服务框架有DubboSpringCloud 生产者提供业务逻辑实现的角色对外提供服务 消费者调用生产者提供的服务使用其业务功能
如订单服务器和商品服务分别对外提供了操作订单和商品的业务功能此时它们都属于生产者但是订单服务在查询订单的时候需要去获取当前订单有哪些商品因此订单服务就要调用商品服务提供的功能所以订单服务又是商品服务的消费者表现层相关组件直接生产者提供的服务因此它们都是消费者。服务间的调用都是使用RPC远程调用协议 微服务应用的优势 降低系统的耦合度 服务器之间都是相互独立互补干扰此时每个服务都能更好的选择符合业务场景的技术 充分使用服务器的硬件资源避免造成不必要的浪费 降低维护成本和难度 提高应用系统的稳定性
分布式和微服务的区别 分布式服务顾名思义服务是分散部署在不同的机器上的一个服务可能负责几个功能是一种面向SOA架构的服务之间也是通过rpc来交互或者是webservice来交互的。逻辑架构设计完后就该做物理架构设计系统应用部署在超过一台服务器或虚拟机上且各分开部署的部分彼此通过各种通讯协议交互信息就可算作分布式部署生产环境下的微服务肯定是分布式部署的分布式部署的应用不一定是微服务架构的比如集群部署它是把相同应用复制到不同服务器上但是逻辑功能上还是单体应用 简单来说微服务就是很小的服务小到一个服务只对应一个单一的功能只做一件事。这个服务可以单独部署运行服务之间可以通过RPC来相互交互每个微服务都是由独立的小团队开发测试部署上线负责它的整个生命周期。 RPC协议调用原理 序列化和反序列化 序列化把Java对象转变为二进制数据需要在本地磁盘存储或者需要在网络中进行传输 反序列化把二进制数据转变为Java对象 流程 RPC远程调用底层的核心技术就是序列化和反序列化 1.生产者发布服务 2.消费者按照RPC协议要求生产者发布的服务 3.生产者执行方法得到返回的对象 4.生产者把对象序列化后返回给消费者 5.消费者接收到数据后对其反序列化得到Java对象 Dubbo项目拆分 项目结构 从以上图中我们不难看出我们至少需要创建5个项目 product-api定义商品相关的业务方法 member-api定义会员相关的业务方法 product-sever商品服务的提供者同时也是会员服务的消费者底层会去调用会员服务的相关功能 member-sever会员服务的提供者提供会员业务方法的实现 website商品服务的消费者使用商品服务提供的业务功能 Zookeeper zookeeper的功能非常多是大数据技术领域的核心组件之一但是我们这里用不到那么多的功能仅仅只是作为注册中心来使用一下 注意没有注册中心的情况下Dubbo也是可以正常的运行的