Dubbo

Kitty Cloud(HTTP_RPC)的全局异常处理

三世轮回 提交于 2020-08-08 21:00:54
项目地址 https://github.com/yinjihuan/kitty-cloud 异常处理不用我讲,大家都清楚。单独的异常处理太繁琐,全局异常处理可以在一个应用中统一进行异常的处理,非常方便。目前全局异常处理用的也越来越广泛,今天跟大家来聊一聊 Kitty Cloud 中的全局异常是如何处理的? 为什么要使用全局异常处理呢? 使用全局异常处理后,我们不需要定义固定类型的返回值,当业务代码报错的时候直接通过异常处理方式来返回给前端或者 API 调用方错误信息。 不使用全局异常处理案例 Web 层 比如我们定义了一个 ResponseData 用来返回固定格式的数据,正常情况下不会有问题,给前端返回的格式也是固定的,如下: { "code":200, "data":{ "name":"yinjihuan" }, "message":"success", } 如果业务发生异常,那么这个接口就不会返回上面那样固定格式的数据了,会给我们返回错误页面。除了代码异常还有一种情况就是当访问的 Uri 错误的时候,也会给调用方返回 404 的错误页面,如下: 如果是传统的 Web 项目,里面包含了页面这是没问题的,我们也可以自定义错误页面让用户体验更好一点。但是在这个基本上是前后端分离的开发模式下,后端只提供的数据的 API,不会有页面的内容。所以就算出错了,就算使用者调用的 API

秒杀用“微服务”架构?不注意这些细节就惨了!

*爱你&永不变心* 提交于 2020-08-08 20:45:05
都 2020 年了 还没用过 微服务 吗? 面试的时候高并发回答的总是不能让面试官满意? 一个互联网项目究竟有多少细节? 网上搜了一堆秒杀系统方案,究竟真实的线上电商该怎么做? 那么你缺乏这两个字 实 战 消除痛点、解决面试、积累实战经验 欢迎你参加马士兵教育 微服务与高并发 训练营 本号粉丝: 免 费 两天你将学到 快速 · 上手微服务,了解各个组件的作用 极简 · 从点到面,内容绝不拖泥带水 实战 · 构建微服务项目 架构 · 高并发系统中组件解析与选型 健壮 · 互联网项目常用中间件服务 做到 · 从传统项目转向微服务互联网系统架构 吊打 · 面试官,独家解析淘宝网秒杀系统需求 马士兵是谁? 马士兵 马士兵老师,清华大学, 推动Java生根中国 , 推动大数据生根中国 , 推动AI生根中国 ,视频课程下载次数累计数 27000万次 。 训练营时间: 7月29日-7月30日,20:00 开营前:发放预习的基础资料 长按扫码,领预习资料,入群学习 遇到扫码频繁,请再次识别 福利较大,限前200人 第一天:快速上手SpringCloud微服务系统架构+常用中间件服务 SOA、Webservice、Dubbo、SpringCloud究竟什么是微服务? 单体应用向微服务异构平台架构演变 SpringCloud微服务组件生态体系 从零开始构建微服务项目各组件应用场景及代码实现

Springboot快速上手- 第八篇 Actuator

烂漫一生 提交于 2020-08-08 19:38:14
1 概述 Spring Boot Actuator的关键特性是在应用程序里提供众多Web端点,通过它们了解应用程序运行时的内部状况,比如: Spring应用程序上下文里配置的Bean Bean在Spring应用程序上下文里是如何组装在一 起的 Spring Boot的自动配置做的决策 应用程序取到的环境变量、系统属性、配置属性和命令行参数 应用程序里线程的当前状态 应用程序最近处理过的HTTP请求的追踪情况 各种和内存用量、垃圾回收、Web请求以及数据源用量相关的指标…… Spring Boot Actuator提供的端点,可以查看官方文档: https://docs.spring.io/spring-boot/docs/2.0.0.M4/reference/htmlsingle/#production-ready-endpoints 2 启用Actuator 要启用Actuator的端点,只需在项目中引入Actuator的起步依赖即可 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> 同时在properties里面设置management.security.enabled=false

Springboot快速上手- 第七篇 单元测试

痴心易碎 提交于 2020-08-08 17:59:59
1 概述 SpringBoot对测试提供了一些简化支持,只需要添加起步依赖即可使用: <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> 2 以前的测试方式 SpringJUnit支持,由此引入Spring-Test框架支持,通过这个注解让SpringJUnit4ClassRunner这个类提供Spring测试上下文 @RunWith(SpringJUnit4ClassRunner.class) 指定SpringBoot工程的Application启动类,通过这个注解加载和配置Spring应用上下文 @SpringApplicationConfiguration(classes = App.class) 由于是Web项目,Junit需要模拟ServletContext,因此需要给测试类加上@WebAppConfiguration @WebAppConfiguration 3 常见的第一种方式 @RunWith(SpringRunner.class) @SpringBootTest(classes = App.class)

金融风控系统设计

风流意气都作罢 提交于 2020-08-08 16:39:14
2019-02-05:金融风控系统设计 - 外汇管理风控系统 胖子钓鱼 https://www.jianshu.com/p/e0609b5ba0d4 2019.02.05 14:06:01 字数 3,227阅读 1,576 无际致力于金融科技对银行、融担、互联网金融行业的基于供应链金融为核心的互联网化金融风控技术的输出。涵盖了互联网信贷核心的系统建设,基于Spark[Spark ML, Spark Streaming(Flink 替换中),Spark Graphx]技术体系的信贷风控系统建设,以及长期为合作伙伴提供有效的低风险资产的流量业务。在经历了从银行到互联网金融公司到科技输出行金融科技公司的历程后,笔者希望能够将对行业及系统设计的理解做以分享。 本文共分为三部分(外资银行的外汇交易系统风险建设,互联网金融个人风控系统建设,供应链金融中小企业风控系统建设) 外资银行的风险系统建设 该部分更多介绍一下外汇交易系统风险控制的业务层面,技术上的确无创新之处,加上大量使用三方厂商的系统,在此感谢IBM MQ、Webmethod跟Oracle为该行提供大量的便利,在这家银行里,我们看不到Tomcat, Jetty, 看不到Spring Cloud,Dubbo,ZooKeeper,没有人理会微服务,大家连Yarn跟Hadoop啥关系都不知道。从技术角度到也单纯,能买的就不做

JAVA SPI机制

霸气de小男生 提交于 2020-08-08 13:31:58
SPI机制 @Author:zxw @school:吉首大学 参考资料: http://dubbo.apache.org/zh-cn/docs/source_code_guide/dubbo-spi.html 1. 前言 2. JAVA SPI ServiceLoader<Robot> loader = ServiceLoader.load(Robot.class); System.out.println("JAVA SPI"); loader.forEach(Robot::sayHello); 创建一个Iteraotor.iterator方法(),并创建一个接口 public S next() { if (knownProviders.hasNext()) return knownProviders.next().getValue(); return lookupIterator.next(); } 首先通过next()方法获取下一元素 public S next() { if (acc == null) { // 进入这 return nextService(); } else { PrivilegedAction<S> action = new PrivilegedAction<S>() { public S run() { return nextService(); } }

监控系统设计

夙愿已清 提交于 2020-08-08 13:01:32
每日优鲜监控系统早期情况 系统覆盖不全 每日优鲜早期只有交易平台存在一套内部的业务监控系统,没有推广到全公司级别。大数据团队与自己的业务监控,运维团队有自己的基础监控。除了交易系统其他业务线的业务监控几乎为零,很多时候都是用户告知我们出问题了,而不是我们主动发现出问题了,导致问题发现的时候已经过去很久了。 监控类型不完善 监控内容主要是涉及日志中出现的数据统计,所以对PV、UV、JVM相关监控都没有,尤其对自身业务的监控几乎为零,我们无法实时的知道当前接口的访问量,错误率等信息;除此之外我们依赖的zookeeper、mq、redis、数据库等中间件的监控也基本没有,所以很难做到深入的排查。不过好在有一套pinpoint可以帮助故障和性能定位。但是这并不能代替业务监控。 监控系统选型和实现 选型 要实现一套监控系统,必须要保证数据的收集、存储和可视化,然后在基于此实现一套告警系统,最终实现数据的可视化与问题的触达。 可视化选型 在做监控系统选型的时候,最优先定下来的是可视化,即Grafana这套开源产品,因为其支持多数据源,同时也支持告警规则,除此之外其提供了一套完备的API,我们通过程序调用其API实现了监控数据可视化的自动化流程。 存储选型 第二个定下来的是存储系统,监控的数据基本都带有时序性,所以我们自然而然的朝着时序数据库(TSDB)方向进行选型。最终定下来的存储有两种

你在群里提的技术问题没人回答!是为什么?因为没注意这 4 点!

让人想犯罪 __ 提交于 2020-08-08 11:19:15
「有大佬在吗?我有一个问题想问一下」 你是不是经常在QQ群或者微信群里碰到这样的提问者,或者难道你就是!由于我建了几个技术群,经常会碰到这样的同学,前面几次我会直接@对方,然后告诉他有问题直接问就好了,有人看到就会回答了,不然,谁会跳出来承认自己是大佬呢? 后来,我干脆就写了这样的一篇文章,让更多的同学,尤其是新入行的同学学会更好的提问!这样,你的问题才会更有机会得到别人的回答。。 提问的艺术 作为一个程序员,把代码写好是本分,但仅仅是写好代码是不够的,工作的过程中总免不了要与别人打交道。几乎隔一段时间,我就会发现有些人身上出现下面的这两个问题。第一个就是不知道怎么提问,第二个就是有工作对接的时候,有用的信息不实时收集,多次对同样的问题进行提问。 今天来说一说如何提问的话题。说到这里,有点同学肯定在想,扯什么扯,提问谁不会呢,十万个为什么从小就听,回答问题不一定会,提问谁还不会呢。 可现实真的不是这样的,其实关于如何提问,这个问题由来已久,而且很多人都对此有过总结,甚至有一本书就叫做《提问的艺术》。这里所说的提问当然不是平时生活中所说的“你吃了没有?”、“吃的什么?”这么简单的问题。指的是专业方面的问题,作为程序员来讲,那就是关于开发、部署等方面的问题了。 我先来举几个糟糕的提问的例子: 有的同学在群里提问,上来就是: 接口返回404错误,是什么原因? dubbo 服务启动不了

微服务技术栈:常见注册中心组件,对比分析

偶尔善良 提交于 2020-08-08 09:41:27
本文源码: GitHub·点这里 || GitEE·点这里 一、注册中心简介 1、基础概念 在分布式架构的系统中注册中心这个概念就已经被提出了,最经典的就是Zookeeper中间件。 微服务架构中,注册中心是最核心的基础服务之一,注册中心可以看做是微服务架构中的通信中心,当一个服务去请求另一个服务时,通过注册中心可以获取该服务的状态,地址等核心信息。 服务注册主要关系到三大角色:服务提供者、服务消费者、注册中心。 2、流程和原理 基础流程 服务启动时,将自身的网络地址等信息注册到注册中心,注册中心记录服务注册数据。 服务消费者从注册中心获取服务提供者的地址,并通过地址和基于特定的方式调用服务提供者的接口。 各个服务与注册中心使用一定机制通信。如果注册中心与服务长时间无法通信,就会注销该实例,这也称为服务下线,当服务重新连接之后,会基于一定的策略在线上线。 服务地址相关信息发生变化时,会重新注册到注册中心。这样,服务消费者就无需手工维护提供者的相关配置。 核心功能 通过上面的基本流程,不难发现一个注册中心需要具备哪些核心功能: 服务发现 服务发现是指服务在启动后,注册到注册中心,服务方提供自身的元数据,比如IP地址、端口、运行状况指标的Uri 、主页地址等信息。 服务记录 记录注册中心的服务的信息,例如服务名称、IP地址、端口等。服务消费方基于查询获取可用的服务实例列表。

浅谈目前最火的架构风格:微服务

痴心易碎 提交于 2020-08-08 07:48:52
微服务 微服务的由来 微服务的使用场景 微服务相较于单体架构的优点 微服务的本质 微服务的应用 微服务开发框架 微服务的由来 微服务最早由 Martin Fowler与James Lewis于2014年 共同提出,微服务架构风格是一种使用 一套小服务来开发单个应用 的方式途径, 每个服务运行在自己的进程中 ,并使用轻量级机制通信,通常是HTTP API,这些服务基于业务能力构建,并能够通过自动化部署机制来独立部署,这些服务使用不同的编程语言实现,以及不同数据存储技术,并保持最低限度的集中式管理。 微服务的使用场景 在传统的IT行业软件大多都是各种独立系统,他们的缺点就 是扩展性差,可靠性不高,维护成本高 。所以目前大部分公司都使用微服务进行开发。 微服务相较于单体架构的优点 (1) 单体架构所有的模块全都耦合在一块,代码量大,维护困难。 微服务每个模块就相当于一个单独的项目, 代码量明显减少,遇到问题也相对来说比较好解决。 (2) 单体架构所有的模块都共用一个数据库,存储方式比较单一。 微服务每个模块都 可以使用不同的存储方式 (比如有的用redis,有的用mysql等),数据库也是单个模块对应自己的数据库。 (3) 单体架构所有的模块开发所使用的技术一样。 (比如用的开发语言是Java,就得整篇是Java,但是微服务不同,他可以多个服务使用不同的语言) 微服务每个模块都可以使用