Mobabel

Just One Pure ITer

Category: Distributed Architecture

0

RPC Solutions

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

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

0

Realtime Log Analyzing based on Kafka

[转]批处理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

CAP, Base

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

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

0

RPC Solutions

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

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

0

Monolith to Distributed

[转]聊聊分布式系统架构

  1. 写在前面 最近几年，我们一直在谈论各式各样的架构，如高并发架构、异地多活架构、容器化架构、微服务架构、高可用架构、弹性化架构等。还有和这些架构相关的管理型的技术方法，如 DevOps、应用监控、自动化运维、SOA 服务治理、去 IOE 等。面对这么多纷乱的技术，我看到很多团队或是公司都是一个一个地去做这些技术，非常辛苦，也非常累。这样的做法就像我们在撑开一张网里面一个一个的网眼。 其实，只要我们能够找到这张网的“纲”，我们就能比较方便和自如地打开整张网了。那么，这张“分布式大网”的总线——“纲”在哪里呢？我希望通过这一系列文章可以让你找到这个“纲”，从而能让你更好更有效率地做好架构和工程。

0

Redis Aof&Rdb Persistence Theory

[转]不管你的Redis集群规模有多大，都是时候思考下如何提升资源利用率了

Redis 是互联网产品开发中不可缺少的常备武器，它性能高、数据结构丰富、简单易用，但同时也是因为太容易用了，我们的开发同学不管什么数据、不管这数据有多大、不管数据有多少通通塞进去，最后导致的问题就是 Redis 内存使用持续上升，但是又不知道里面的数据是不是有用，是否可以拆分和清理。 为了更好地使用 Redis，除了对 Redis 做一些使用规范，还需要对线上使用的 Redis 有充分的了解。那么问题来了：一个 Redis 的实例用了那么大的内存，里边到底存了啥？都有哪些 key？每个 key 占用了多少空间？ 雪球当前有几十个 Redis 集群，近千个 Redis 实例，5T 的内存数据，我们也想要分析业务是否有误用，以提高资源利用率。当然，曾经我们也深深地被这个问题所困扰，今天我就来和大家分享下我是如何解决这个问题的，希望能给各位一些启发。

0

Cache in distributed Architecture / Redis Theory & Solutions

[转]AutoLoadCache – 面对缓存，有哪些问题需要思考？

缓存可以说是无处不在，比如 PC 电脑中的内存、CPU 中的二级缓存、HTTP 协议中的缓存控制、CDN 加速技术都是使用了缓存的思想来解决性能问题。 缓存是用于解决高并发场景下系统的性能及稳定性问题的银弹。 本文主要是讨论我们经常使用的分布式缓存 Redis 在开发过程中的相关思考。

[转]跨库分页的四种方案 0

Database Partitioning&Scaling

[转]跨库分页的四种方案

一、需求缘起 分页需求 互联网很多业务都有分页拉取数据的需求，例如： （1）微信消息过多时，拉取第N页消息 （2）京东下单过多时，拉取第N页订单 （3）浏览58同城，查看第N页帖子   这些业务场景对应的消息表，订单表，帖子表分页拉取需求有这样一些特点： （1）有一个业务主键id, 例如msg_id, order_id, tiezi_id （2）分页排序是按照非业务主键id来排序的，业务中经常按照时间time来排序order by