Category: Java Architecture

0

[转]Redis高可用技术解决方案总结

本文主要针对 Redis 常见的几种使用方式及其优缺点展开分析。 1. 一、常见使用方式 Redis 的几种常见使用方式包括: Redis 单副本; Redis 多副本(主从); Redis Sentinel(哨兵); Redis Cluster; Redis 自研。

0

[转]业务出海过程中,你有遇到过跨域RPC调用的问题吗?

在微服务架构中,一般都是通过 API 网关统一向外部系统提供 API 服务。熟悉 Spring Cloud 的同学知道,Zuul 在 Spring Cloud 中就起到了 API 网关的作用。同理,在菜鸟微服务架构中,菜鸟 API 网关作为对外暴露服务的网关。 菜鸟在面向全球 CP(Cainiao Partner)提供服务的时候,遇到了传统 API 网关在跨国网络上传输数据的瓶颈,如下图,Partner C(国外的 CP)调用 API Gateway 走了跨国的公网,该段网络的质量非常不稳定,严重影响了 Partner C 的服务体验。我们把这种由于网络延迟高、抖动严重而引起的网络质量问题称为 网络桎梏。

0

[转]一个支付服务的最终一致性实践案例(含伪代码)

“功夫贷”是一款线上贷款 APP,主要是给信用卡优质用户提供纯线上的信用贷款,以期限长、额度高、利息低为主要优势(类似的业务模式主要有宜人贷)。 和任何一种分期贷款一样,符合资质的用户,在功夫贷成功贷款之后,需要在约定还款日还款。目前还款主要有以下这几种方式: 用户在 APP 上主动还款; 系统定时通过后台任务扣款; 催收人员通过内部作业系统,手动发起扣款;

0

[转]批处理ETL已死,Kafka才是数据处理的未来

在 QCon 旧金山 2016 会议上,Neha Narkhede 做了“ETL 已死,而实时流长存”的演讲,并讨论了企业级数据处理领域所面临的挑战。该演讲的核心前提是开源的 Apache Kafka 流处理平台能够提供灵活且统一的框架,支持数据转换和处理的现代需求。 Narkhede 是 Confluent 的联合创始人和 CTO,在演讲中,他首先阐述了在过去的十年间,数据和数据系统的重要变化。该领域的传统功能包括提供联机事务处理(online transaction processing,OLTP)的操作性数据库以及提供在线分析处理(online analytical processing,OLAP)的关系型数据仓库。来自各种操作性数据库的数据会以批处理的方式加载到数据仓库的主模式中,批处理运行的周期可能是每天一次或两次。这种数据集成过程通常称为抽取 – 转换 – 加载(extract-transform-load,ETL)。

0

[转]分布式系统架构经典资料

前段时间,我写了一系列分布式系统架构方面的文章(拉到文末看目录),有很多读者纷纷留言讨论相关的话题,还有读者留言表示对分布式系统架构这个主题感兴趣,希望我能推荐一些学习资料。 就像我在前面的文章中多次提到的,分布式系统的技术栈巨大无比,所以我要推荐的学习资料也比较多,会在后面的文章中陆续发出。在今天这篇文章中,我将推荐一些分布式系统的基础理论和一些不错的图书和资料。

0

[转]阿里巴巴微服务与配置中心技术实践之道

在面向分布式的微服务系统中,如何通过更高效的配置管理方式,帮助微服务系统架构持续“无痛”的演进,动态调整和控制系统的运行时飞行姿态,值得我们好好的在配置管理上重新思考和设计。别让您的微服务被配置管理“绊”了一跤! 本文是阿里巴巴高级技术专家 @坤宇在 2017 年 QCon 微服务专题演讲中关于微服务与配置中心的演讲实录的文字版,演讲视频可以参见: http://www.infoq.com/cn/presentations/micro-service-and-configuration-center?spm=a2c4e.11153940.blogcont332358.36.30772099lWiw8H 阿里巴巴集团早在 2007 年进行从 IOE 集中式应用架构升级为互联网分布式服务化架构的时候,就意识到在分布式环境中,传统的分散式的、基于配置文件的、应用自包含的配置管理方式将面临重大挑战,亟需设计匹配新架构的新的配置管理解决方案,解决诸如分布式服务治理,数据源容灾切换,异地多活,预案,限流规则等场景下的配置变更以及热生效问题,这直接诞生了今天阿里集团内部被广泛使用的配置中心 ACM(Diamond),而这也是目前世界上最大的配置中心,存储了超过百万的生产配置,在集团内部支持了包括淘宝、天猫、菜鸟、阿里云、高德等全网几乎阿里所有的应用,每天产生近 10 亿次的配置变更推送。

0

[转]一个针对所有RPC框架的性能测试

几乎所有的 RPC 框架都宣称自己是“高性能”的,那么实际结果到底如何呢, 让我们来做一个性能测试吧。 项目地址: https://github.com/hank-whu/rpc-benchmark 测试说明 仅限于 Java; 客户端使用 JMH 进行压测, 32 线程, 10 次预热, 3 次运行; 每次运行前都会执行 killall java, 但没有在每轮测试时重启操作系统; 所有类库版本在发布时都是最新的, 除非存在 bug; 所有框架都尽量参考该项目自带的 Benchmark 实现; 将会一直持续, 不定期发布测试结果; 测试用例 boolean existUser(String email),...

0

[转]微服务架构技术栈选型手册

1. 一、前言 2014 年可以认为是微服务 1.0 的元年,当年有几个标志性事件,一是 Martin Fowler 在其博客上发表了”Microservices”一文,正式提出微服务架构风格;二是 Netflix 微服务架构经过多年大规模生产验证,最终抽象落地形成一整套开源的微服务基础组件,统称 NetflixOSS,Netflix 的成功经验开始被业界认可并推崇;三是 Pivotal 将 NetflixOSS 开源微服务组件集成到其 Spring 体系,推出 Spring Cloud 微服务开发技术栈。 一晃三年过去,微服务技术生态又发生了巨大变化,容器,PaaS,Cloud Native,gRPC,ServiceMesh,Serverless 等新技术新理念你方唱罢我登场,不知不觉我们又来到了微服务 2.0 时代。 基于近年在微服务基础架构方面的实战经验和平时的学习积累,我想总结并提出一些构建微服务 2.0 技术栈的选型思路,供各位在一线实战的架构师、工程师参考借鉴。对于一些暂时还没有成熟开源产品的微服务支撑模块,我也会给出一些定制自研的设计思路。 2. 二、选型准则 对于技术选型,我个人有很多标准,其中下面三项是最重要的: 2-1....

0

[转]API网关性能比较:NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd

1. 前几天拜读了 OpsGenie 公司(一家致力于 Dev & Ops 的公司)的资深工程师 Turgay Çelik 博士写的一篇文章(链接在文末),文中介绍了他们最初也是采用 Nginx 作为单体应用的网关,后来接触到微服务架构后开始逐渐采用了其他组件。 我对于所做的工作或者感兴趣的技术,喜欢刨根问底,所以当读一篇文章时发现没有看到我想要看到的设计思想,我就会四处搜集资料,此外这篇文章涉及了我正在捣鼓的 Spring Cloud,所以我就决定写一篇文章,争取能从设计思路上解释为什么会有这样的性能差异。

0

[转]运维能力是微服务架构的先决条件

  今天我们来聊聊微服务架构模式下的一个核心概念:应用。 我会从这几个方面来讲:应用的起源、应用模型和应用关系模型建模以及为什么要这样做。最终希望,在微服务的架构模式下,我们的运维视角一定转到应用这个核心概念上来,一切要从应用的角度来分析和看待问题。