Dubbo

一文解读微服务架构的服务与发现—Spring Cloud

旧城冷巷雨未停 提交于 2020-03-17 22:55:45
一、为什么需要服务发现 简单来说,服务化的核心就是将传统的一站式应用根据业务拆分成一个一个的服务,而微服务在这个基础上要更彻底地去耦合(不再共享DB、KV,去掉重量级ESB),并且强调DevOps和快速演化。这就要求我们必须采用与一站式时代、泛SOA时代不同的技术栈,而Spring Cloud就是其中的佼佼者。 DevOps是英文Development和Operations的合体,他要求开发、测试、运维进行一体化的合作,进行更小、更频繁、更自动化的应用发布,以及围绕应用架构来构建基础设施的架构。这就要求应用充分的内聚,也方便运维和管理。这个理念与微服务理念不谋而合。 接下来我们从服务化架构演进的角度来看看为什么Spring Cloud更适应微服务架构。 1.1 从使用nginx说起 最初的服务化解决方案是给提供相同服务提供一个统一的域名,然后服务调用者向这个域名发送HTTP请求,由Nginx负责请求的分发和跳转。 这种架构存在很多问题: Nginx作为中间层,在配置文件中耦合了服务调用的逻辑,这削弱了微服务的完整性,也使得Nginx在一定程度上变成了一个重量级的ESB。 服务的信息分散在各个系统,无法统一管理和维护。每一次的服务调用都是一次尝试,服务消费者并不知道有哪些实例在给他们提供服务。这不符合DevOps的理念。 无法直观的看到服务提供者和服务消费者当前的运行状况和通信频率

Dubbo二(安装Zookeeper_Dubbo支持的协议)

末鹿安然 提交于 2020-03-17 21:50:59
安装注册中心Zookeeper Zookeeper使用java开发的, 所以安装Zookeeper的前提是安装JDK. 安装JDK # 解压缩jdk安装包 tar -zxf jdk-x.x.x.tar.gz # 移动到指定目录: /usr/local/jdk mv jdk-x.x.x /usr/local/jdk # vim编辑profile配置环境变量 vim /etc/profile ########################## JAVA_HOME = /usr/local/jdk PATH = $JAVA_HOME /bin: $PATH export JAVA_HOME export PATH ########################## # 使配置生效 source /etc/profile 安装Zookeeper 解压缩 tar -zxf zookeeper-3.4.6.tar.gz 移动位置 mv zookeeper-3.4.6 /usr/local/zookeeper 提供数据保存目录 可以在任意位置创建一个目录,用于保存Zookeeper执行期间的数据. 建议在/usr/local/zookeeper目录中创建目录. mkdir /usr/local/zookeeper/data 修改配置文件 /usr/local/zookeeper/conf

springcloud 微服务

大憨熊 提交于 2020-03-17 12:34:54
某厂面试归来,发现自己落伍了!>>> 微服务 微服务架构:是一种架构模式,将一个应用程序划分为一组小的服务,每个服务运行在自己单独的进程中,服务之间通过HTTP的restful API相互沟通,相互协作、相互配合,为用户提供最终服务。微服务框架案例:www.b123.com. 强调避免集中式、统一的服务管理机制。 微服务·:是一个个微小的服务,强调的是服务的大小,狭义地说就是idea中一个个的model。将一个应用程序拆分后的各个独立模块。 微服务就好比医院中一个个独立的科室,牙科、骨科、外科等。而这些独立的科室就构成了医院,这就是微服务架构。 1 为什么有微服务? 传统的开发,将一个应用程序放在一个项目里面,打成一个war包,所有的模块,例如:订单、商品、交易、库存等,都在一个项目里面,这种服务称为巨石服务。All in one 这种架构一旦某个模块出问题,整个项目就会受到影响,甚至崩溃 分布式: 将一个服务应用,拆分为各个模块/服务,将模块独立出来,单独开发。各自有各自微小的进程,让专业的人,专业的模块做专业的事,让分工更加明确。各个模块独立部署 这种架构,服务之间不会影响,哪个模块出问题,受影响的只有那个模块,其它模块仍然可以工作。 微服务的作用 去耦合,各自的服务模块可以拥有自己的数据库,通过springcloudconfig,进行配置共同协作,各个模块可以单独的启动和销毁

应用Dubbo框架打造仿猫眼项目 理解微服务核心思想

假装没事ソ 提交于 2020-03-17 06:43:55
1:传统应用带来的问题 单一业务开发的迭代问题 扩容困难 部署回滚困难 2:微服务概述 微服务是一种将业务系统进一步拆分的架构风格 微服务强调每一个业务都独立运行 每个单一服务都应该使用更轻量级的机制保持通信 服务不强调环境,可以不同语言或数据源 3:微服务种类 Dubbo Spring Cloud Zero ICE 4:微服务基本概念 Provider:服务提供者,提供服务实现 Consumer:服务调用者,调用Provider提供的服务实现 同一个服务可以既是Provider,又是Consumer 5:spring boot 集成dubbo需要引入依赖 <dependency> <groupId>com.alibaba.spring.boot</groupId> <artifactId>dubbo-spring-boot-starter</artifactId> <version>2.0.0</version></dependency> <dependency> <groupId>com.101tec</groupId> <artifactId>zkclient</artifactId> <version>0.10</version></dependency> 6:相关具体代码provider端 @Component@Service(interfaceClass =

【面向服务体系架构】

橙三吉。 提交于 2020-03-17 06:41:12
什么是SOA SOA:面向服务架构(Service Oriented Architecture) 关注点在业务,而不是在对象的变化上 必然性:编程技术的发展 开始,基于过程式编程,使用大量函数 面向对象编程出现,一切皆为对象 面向组件编程出现,对可重用的对象组合成一个组件 面向服务, 也可以看成是一个越来越抽象化的发展 功能浪费:多个系统中,各个系统有不少部分是相同或者类似的;SOA可以通过共用服务,减少这部分的开发 效率低下:因为重复做轮子,所以效率低下 架构复杂:因为各个系统架构都不同,增加复杂度 集成困难:不同系统是独立的,要集成的时候很困难 设计复杂:设计的对象不止是一个系统,而是对一对系统的统筹考虑 缺乏标准:业界缺少SOA的规范 自上而下设计(全局推动):要领导说话,决定,才能这么做 服务治理:很多服务开发出来,如何管理这些服务 提供了以上这些一些规范和原则 有大家都认可的契约,才能共同合作 服务自己管理自己,不应该和其他功能耦合 自己能控制自己的运行环境 2、Protobuf,一个关于数据序列化,数据传输、存储的一个工具,为了在SOA中更高效地处理数据;不完整的RPC组件 3、Thrift,一个RPC组件 4、Dubbo Protobuf和Thrift面向跨语言,对Java支持没有那么好 DubboRPC框架 出现背景: RPC,是客户端可以动态请求不同服务器的服务

谷粒商场篇】第二天 中(Linux篇)

陌路散爱 提交于 2020-03-17 01:48:33
第二天 下(Linux篇) 篇幅较长,请配合目录观看 项目准备 1. Dubbo监控中心的启动 1.1 将dubbo.admin-2.6.0.war存放到usr/local/guli,并解压 1.2 进入tomcat的sever.xml 1.3 启动tomcat并访问dubbo 2. 启动zookeeper 2.1 解压zookeeper-3.4.11.tar.gz 2.2 配置zookeeper 2.3 启动zookeeper 3. dubbo和zookeeper开启自启动 3.1 进入Linux启动就会运行的目录 3.2 编写dubbo自启动脚本 3.3 编写zookeeper自启动脚本 中国加油,武汉加油! 篇幅较长,请配合目录观看 项目准备 一个带有JDK8和tomcat的CentOS7服务器 dubbo.admin-2.6.0.war zookeeper-3.4.11.tar.gz 1. Dubbo监控中心的启动 1.1 将dubbo.admin-2.6.0.war存放到usr/local/guli,并解压 unzip dubbo-admin-2.6.0.war -d dubbo 如果没找到unzip执行下这条命令 yum install -y unzip zip 1.2 进入tomcat的sever.xml <Context path="/dubbo" docBase=

Centos7安装配置Zookeeper

*爱你&永不变心* 提交于 2020-03-17 01:26:38
某厂面试归来,发现自己落伍了!>>> 前言: 在小企业或者一些小项目中,当网站流量很小时,只需一个应用,便能将所有功能都部署在一起,以减少部署节点和成本。但当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率,也就是我们常说的MVC垂直应用架构。可是当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。 此时,用于提高业务复用及整合的分布式服务框架(RPC) 是关键,Dubbo就在这种情况下应运而生。 由于本文不是重点介绍Dubbo和zookeeper的技术文章,如果想深入学习原理,请移步官网。 Dubbo官网:http : / / dubbo . apache . org / Zookeeper官网:http : / / zookeeper . apache . org / Dubbo建议使用Zookeeper作为服务的注册中心,本文作者在公司中也是使用Zookeeper,所以在偏向应用层面给大家介绍如何安装配置Zookeeper,为后续Dubbo的使用实例做铺垫。 废话了这么多,现在来介绍如何在Centos7上安装配置Zookeeper。 1、cd到/usr/local文件夹下,创建 /usr/local/zookeeper 文件夹: mkdir

dubbo 服务降级

情到浓时终转凉″ 提交于 2020-03-16 17:48:19
某厂面试归来,发现自己落伍了!>>> 什么是服务降级? 当服务器压力剧增的情况下,根据实际业务情况及流量,对一些服务和页面有策略的不处理或换种简单的方式处理,从而释放服务器资源以保证核心交易正常运作或高效运作。 可以通过服务降级功能 [1] 临时屏蔽某个出错的非关键服务,并定义降级后的返回策略。 向注册中心写入动态配置覆盖规则: RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory . class ). getAdaptiveExtension () ; Registry registry = registryFactory.getRegistry(URL.valueOf( "zookeeper://10.20.153.10:2181" )); registry.register(URL.valueOf( "override://0.0.0.0/com.foo.BarService?category=configurators&dynamic=false&application=foo&mock=force:return+null" )); 其中: mock=force:return+null 表示消费方对该服务的方法调用都直接返回 null 值,不发起远程调用

dubbo 协议

℡╲_俬逩灬. 提交于 2020-03-16 17:28:11
某厂面试归来,发现自己落伍了!>>> dubbo:// Dubbo 缺省协议采用单一长连接和 NIO 异步通讯,适合于小数据量大并发的服务调用,以及服务消费者机器数远大于服务提供者机器数的情况。 反之,Dubbo 缺省协议不适合传送大数据量的服务,比如传文件,传视频等,除非请求量很低。 Transporter: mina, netty, grizzy (传输层) Serialization: dubbo, hessian2, java, json (序列化) Dispatcher: all, direct, message, execution, connection ThreadPool: fixed, cached (线程池) 特性 缺省协议,使用基于 mina 1.1.7 和 hessian 3.2.1 的 tbremoting 交互。 连接个数:单连接 连接方式:长连接 传输协议:TCP 传输方式:NIO 异步传输 序列化:Hessian 二进制序列化 适用范围:传入传出参数数据包较小(建议小于100K),消费者比提供者个数多,单一消费者无法压满提供者,尽量不要用 dubbo 协议传输大文件或超大字符串。 适用场景:常规远程服务方法调用 约束 参数及返回值需实现 Serializable 接口 参数及返回值不能自定义实现 List , Map , Number , Date

某厂面试归来,发现自己落伍了!

一曲冷凌霜 提交于 2020-03-16 11:46:45
某厂面试归来,发现自己落伍了!>>> 不少单位已经开始复工了,跳槽季已经开始。虽说大多数互联网企业,像腾讯、字节跳动等,都已经开通远程面试环节,而且薪资有走高的趋势。但据目前看,面试难度大了许多,甚至有朋友面试后怀疑:自己真的落伍了? 比如,面试高级开发岗位时,面试官不仅考察基础能力 , 更会重点考察高并发、分布式等架构相关的技术背后的思考逻辑,比如: 微服务,负载均衡,Redis,RPC 等。 (今年 Java 面试到底聚焦在知识点?文末扫码获取) 但这些技术包含了 N 多优化、N 多细节,对于一些 coding 的朋友,由于接触不到一线实战架构设计,想必并不是很了解。 刚好,趁着这段时间,整理了一套 “微服务+分布式” 的视频干货,讲解很透彻。今天分享给大家。这份资料 尤其适合 以下人群: 1. 没有用过微服务技术,只会用传统的 SSM 框架 2. 用过 Spring Cloud、Dubbo等技术,但是只限于使用,遇到问题基本无法解决 3. 从来没有系统学习微服务、分布式架构,觉得架构设计是遥不可及的 4. 对于微服务、分布式技术有所了解,但尚没有设计高可用高并发的实践经历 学完这份视频你将获得哪些收获? 理解当下最火热的微服务架构原理及其开源框架; 触及一线大厂所配备的微服务核心技术内幕知识; 对照自己掌握知识点进行查漏补缺,帮助扫除知识盲区、重构知识体系。 视频围绕“