Mobabel

Just One Pure ITer

Category: Java Architecture

0

SOA Architect to MS Architect

[转]重新理解微服务

微服务是个说的挺长时间的概念，也是比较成熟的技术体系。像 Spring Cloud，甚至提供了微服务所需要的全套框架，包括注册中心 (Eureka)、配置中心 (Config)、断路器 (Hytrix)、API 网关 (Zuul) 等组件。微服务体系庞杂，每个组件都能独自成章。本文作者仅从个人的经验和实践出发，谈了谈自己对微服务及其部分内涵的思考和理解。 作者张轲目前任职于杭州大树网络技术有限公司，担任首席架构师，负责系统整体业务架构以及基础架构，熟悉微服务、分布式设计、中间件领域，对运维、测试、敏捷开发等相关领域也有所涉猎。

Bildergebnis für 火车 0

MQ in distributed Architecture

[转]分布式系统之消息队列

1. 2. 一、MQ简介 消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。 使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ 3. 二、消息队列应用场景 以下介绍消息队列在实际应用中常用的使用场景。异步处理，应用解耦，流量削锋和消息通讯四个场景。

0

Redis High Avaliable Scale Architect

[转]一个包含10节点的Redis集群实践案例

Redis 通常不会被用作主要的数据存储，但它在存储和访问可容忍丢失的临时数据（如度量指标、会话状态、缓存）方面却独有长处，并且速度非常快，不仅提供了最佳性能，还内置了一组非常有用的数据结构。它是现代技术栈中最常见的主要部件之一。 Stripe（一家做支付的硅谷创业公司）的速率限定器就是基于 Redis 构建的，这些限速器运行在一个 Redis 实例上。Redis 主服务器有一些用于失效备援的追随者，不过在任何时候，都只有一个节点在处理读写操作。 各种消息来源声称，一个 Redis 节点每秒可以处理百万次操作。尽管我们的操作没有那么多，但也不会很少。每个速率限定器都需要运行多个 Redis 命令，而每个 API 请求都要通过很多个速率限定器。所以，每个节点每秒钟需要处理数万次到数十万次的操作。 如果节点出现饱和，就会不断出现故障。我们的服务可以容忍 Redis 的不可用，因此大多数情况下是没有问题的，但在某些情况下，问题的严重程度会升级。我们最后通过迁移到包含 10 节点的 Redis 集群来解决这个问题。对性能的影响可以忽略不计，重要的是现在我们可以实现水平可伸缩。

0

Performance Benchmark

[总结]如何快速定位JVM中消耗CPU最多的线程？

在日常 Java 的开发中，性能调优肯定是很多人不能绕开的一个环节。而其中最简单，也是最基础的一个问题就是如何定位消耗 CPU 最多的线程。这篇文章中你假笨以一个简单的 Test 例子为蓝本，给各位总结了分析这类问题的常用『套路』。

0

SQL Query Optimization

[转]我是如何用2个Unix命令给SQL提速的

我试图在 MariaDB（MySQL）上运行一个简单的连接查询，但性能简直糟糕透了。下面将介绍我是如何通过两个简单的 Unix 命令，将查询时间从 380 小时降到 12 小时以下的。 下面就是这个查询，它是 GHTorrent 分析的一部分，我使用了关系在线分析处理框架 simple-rolap 来实现这个分析。

两个连接字段都有索引。不过，MariaDB 是通过对 project_commits 进行全表扫描和对 commits 进行索引查找来实现连接的。这可以从 EXPLAIN 的输出看出来。