分类目录开源框架

没有什么能够比官网给出的解释更权威了，Kafka为什么那么快，支持的吞吐量为什么那么大，集群的支持那么好，一切从官网的学习开始： http://kafka.apache.org/documentation.html

4. DESIGN

阅读更多

Redis 的 主从复制 模式下，一旦 主节点 由于故障不能提供服务，需要手动将 从节点 晋升为 主节点，同时还要通知 客户端 更新 主节点地址，这种故障处理方式从一定程度上是无法接受的。Redis 2.8 以后提供了 Redis Sentinel 哨兵机制 来解决这个问题。

1. Redis高可用概述

在 Web 服务器中，高可用 是指服务器可以 正常访问 的时间，衡量的标准是在 多长时间 内可以提供正常服务（99.9%、99.99%、99.999% 等等）。在 Redis 层面，高可用 的含义要宽泛一些，除了保证提供 正常服务（如 主从分离、快速容灾技术 等），还需要考虑 数据容量扩展、数据安全 等等。

阅读更多

一、缓存雪崩

缓存雪崩我们可以简单的理解为：由于原有缓存失效，新缓存未到期间(例如：我们设置缓存时采用了相同的过期时间，在同一时刻出现大面积的缓存过期)，所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机。从而形成一系列连锁反应，造成整个系统崩溃。

缓存正常从Redis中获取，示意图如下：

阅读更多

限流算法

• 计数器限流固定窗口滑动窗口
• 桶限流令牌桶漏桶

1. 计数器

计数器限流可以分为：

• 固定窗口
• 滑动窗口

1.1. 固定窗口

固定窗口计数器限流简单明了，就是限制单位之间内的请求数，比如设置QPS为10，那么从一开始的请求进入就计数，每次计数前判断是否到10，到达就拒绝请求，并保证这个计数周期是1秒，1秒后计数器清零。
以下是利用redis实现计数器分布式限流的实现，曾经在线上实践过的lua脚本：

local key = KEYS[1] 
local limit = tonumber(ARGV[1]) 
local refreshInterval = tonumber(ARGV[2]) 
local currentLimit = tonumber(redis.call('get', key) or '0') 
if currentLimit + 1 > limit then 
 return -1; 
else 
 redis.call('INCRBY', key, 1) 
 redis.call('EXPIRE', key, refreshInterval) 
 return limit - currentLimit - 1 
end

一个明显的弊端就是固定窗口计数器算法无法处理突刺流量，比如10QPS，1ms中来了10个请求，后续的999ms的所有请求都会被拒绝。

阅读更多

1. 简介

Dubbo 服务调用过程比较复杂，包含众多步骤，比如发送请求、编解码、服务降级、过滤器链处理、序列化、线程派发以及响应请求等步骤。限于篇幅原因，本篇文章无法对所有的步骤一一进行分析。本篇文章将会重点分析请求的发送与接收、编解码、线程派发以及响应的发送与接收等过程，至于服务降级、过滤器链和序列化大家自行进行分析，也可以将其当成一个黑盒，暂时忽略也没关系。

2. 源码分析

在进行源码分析之前，我们先来通过一张图了解 Dubbo 服务调用过程。

首先服务消费者通过代理对象 Proxy 发起远程调用，接着通过网络客户端 Client 将编码后的请求发送给服务提供方的网络层上，也就是 Server。Server 在收到请求后，首先要做的事情是对数据包进行解码。然后将解码后的请求发送至分发器 Dispatcher，再由分发器将请求派发到指定的线程池上，最后由线程池调用具体的服务。

阅读更多

1. 简介

LoadBalance 中文意思为负载均衡，它的职责是将网络请求，或者其他形式的负载“均摊”到不同的机器上。避免集群中部分服务器压力过大，而另一些服务器比较空闲的情况。通过负载均衡，可以让每台服务器获取到适合自己处理能力的负载。在为高负载服务器分流的同时，还可以避免资源浪费，一举两得。

负载均衡可分为软件负载均衡和硬件负载均衡。在我们日常开发中，一般很难接触到硬件负载均衡。但软件负载均衡还是可以接触到的，比如 Nginx。在 Dubbo 中，也有负载均衡的概念和相应的实现。Dubbo 需要对服务消费者的调用请求进行分配，避免少数服务提供者负载过大。服务提供者负载过大，会导致部分请求超时。因此将负载均衡到每个服务提供者上，是非常必要的。

Dubbo 提供了4种负载均衡实现，分别是基于权重随机算法的 RandomLoadBalance、基于最少活跃调用数算法的 LeastActiveLoadBalance、基于 hash 一致性的 ConsistentHashLoadBalance，以及基于加权轮询算法的 RoundRobinLoadBalance。这几个负载均衡算法代码不是很长，但是想看懂也不是很容易，需要大家对这几个算法的原理有一定了解才行。如果不是很了解，也没不用太担心。我们会在分析每个算法的源码之前，对算法原理进行简单的讲解，帮助大家建立初步的印象。

阅读更多

1. 简介

为了避免单点故障，现在的应用通常至少会部署在两台服务器上。对于一些负载比较高的服务，会部署更多的服务器。这样，在同一环境下的服务提供者数量会大于1。对于服务消费者来说，同一环境下出现了多个服务提供者。这时会出现一个问题，服务消费者需要决定选择哪个服务提供者进行调用。另外服务调用失败时的处理措施也是需要考虑的，是重试呢，还是抛出异常，亦或是只打印异常等。

为了处理这些问题，Dubbo 定义了集群接口 Cluster 以及 Cluster Invoker。集群 Cluster 用途是将多个服务提供者合并为一个 Cluster Invoker，并将这个 Invoker 暴露给服务消费者。这样一来，服务消费者只需通过这个 Invoker 进行远程调用即可，至于具体调用哪个服务提供者，以及调用失败后如何处理等问题，现在都交给集群模块去处理。集群模块是服务提供者和服务消费者的中间层，为服务消费者屏蔽了服务提供者的情况，这样服务消费者就可以专心处理远程调用相关事宜。比如发请求，接受服务提供者返回的数据等。这就是集群的作用。

Dubbo 提供了多种集群实现，包含但不限于 Failover Cluster、Failfast Cluster 和 Failsafe Cluster 等。每种集群实现类的用途不同，接下来会一一进行分析。

阅读更多

整体设计

Dubbo整体框架可以参考下图

图例说明：

• 图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口，位于中轴线上的为双方都用到的接口。
• 图中从下至上分为十层，各层均为单向依赖，右边的黑色箭头代表层之间的依赖关系，每一层都可以剥离上层被复用，其中，Service 和 Config 层为 API，其它各层均为 SPI。
• 图中绿色小块的为扩展接口，蓝色小块为实现类，图中只显示用于关联各层的实现类。
• 图中蓝色虚线为初始化过程，即启动时组装链，红色实线为方法调用过程，即运行时调时链，紫色三角箭头为继承，可以把子类看作父类的同一个节点，线上的文字为调用的方法。

阅读更多

1. 简介

SPI 全称为 Service Provider Interface，是一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。正因此特性，我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能。SPI 机制在第三方框架中也有所应用，比如 Dubbo 就是通过 SPI 机制加载所有的组件。不过，Dubbo 并未使用 Java 原生的 SPI 机制，而是对其进行了增强，使其能够更好的满足需求。

在 Dubbo 中，SPI 是一个非常重要的模块。基于 SPI，我们可以很容易的对 Dubbo 进行拓展。如果大家想要学习 Dubbo 的源码，SPI 机制务必弄懂。接下来，我们先来了解一下 Java SPI 与 Dubbo SPI 的用法，然后再来分析 Dubbo SPI 的源码。

需要特别说明的是，本篇文章以及本系列其他文章所分析的源码版本均为 dubbo-2.6.4。因此大家在阅读文章的过程中，需注意将代码版本切换到 dubbo-2.6.4 tag 上。

阅读更多

Tomcat 是一个 Web 应用服务器，它是对 HTTP 和 Servlet 规范的实现，简单来说它做了这几件事：处理 HTTP 协议、执行 Servlet 和处理网络 I/O。

Spring 框架就是对 Servlet 的封装，Spring 应用本身就是一个 Servlet，而 Servlet 容器是管理和运行 Servlet 的。

Servlet 接口和 Servlet 容器这一整套规范叫作 Servlet 规范。Tomcat 和 Jetty 都按照 Servlet 规范的要求实现了 Servlet 容器。

阅读更多

一、Window & Time 介绍

Apache Flink（以下简称 Flink） 是一个天然支持无限流数据处理的分布式计算框架，在 Flink 中 Window  可以将无限流切分成有限流，是处理有限流的核心组件，现在 Flink 中 Window 可以是时间驱动的（Time Window），也可以是数据驱动的（Count Window）。

下面的代码是在 Flink 中使用 Window 的两个示例

阅读更多

1. 流处理基本概念

对于什么是流处理，从不同的角度有不同的定义。其实流处理与批处理这两个概念是对立统一的，它们的关系有点类似于对于 Java 中的 ArrayList 中的元素，是直接看作一个有限数据集并用下标去访问，还是用迭代器去访问。

图1. 左图硬币分类器

硬币分类器也可以看作一个流处理系统，用于硬币分类的各部分组件提前串联在一起，硬币不断进入系统，并最终被输出到不同的队列中供后续使用。右图同理。

阅读更多

本文主要面向于初次接触 Apache Flink（以下简称Flink）、或者对 Flink 有了解但是没有实际操作过的同学。希望帮助大家更顺利地上手使用 Flink，并着手相关开发调试工作。

课程内容包括：

• Flink 开发环境的部署和配置
• 运行 Flink 应用（包括：单机 Standalone 模式、多机 Standalone 模式和 Yarn 集群模式）

一、Flink 开发环境部署和配置

Flink 是一个以 Java 及 Scala 作为开发语言的开源大数据项目，代码开源在 GitHub 上，并使用 Maven 来编译和构建项目。对于大部分使用 Flink 的同学来说，Java、Maven 和 Git 这三个工具是必不可少的，另外一个强大的 IDE 有助于我们更快的阅读代码、开发新功能以及修复 Bug。因为篇幅所限，我们不会详述每个工具的安装细节，但会给出必要的安装建议。

关于开发测试环境，Mac OS、Linux 系统或者 Windows 都可以。如果使用的是 Windows 10 系统，建议使用 Windows 10 系统的 Linux 子系统来编译和运行。

建议选用社区已发布的稳定分支，比如 Release-1.6 或者 Release-1.7。

阅读更多

一、Apache Flink 的定义、架构及原理

Apache Flink 是一个分布式大数据处理引擎，可对有限数据流和无限数据流进行有状态或无状态的计算，能够部署在各种集群环境，对各种规模大小的数据进行快速计算。

1. Flink Application

了解Flink 应用开发需要先理解Flink 的Streams、State、Time 等基础处理语义以及Flink 兼顾灵活性和方便性的多层次API。

• Streams：流，分为有限数据流与无限数据流，unbounded stream 是有始无终的数据流，即无限数据流；而bounded stream 是限定大小的有始有终的数据集合，即有限数据流，二者的区别在于无限数据流的数据会随时间的推演而持续增加，计算持续进行且不存在结束的状态，相对的有限数据流数据大小固定，计算最终会完成并处于结束的状态。
• State，状态是计算过程中的数据信息，在容错恢复和Checkpoint 中有重要的作用，流计算在本质上是Incremental Processing，因此需要不断查询保持状态；另外，为了确保Exactly- once 语义，需要数据能够写入到状态中；而持久化存储，能够保证在整个分布式系统运行失败或者挂掉的情况下做到Exactly- once，这是状态的另外一个价值。
• Time，分为Event time、Ingestion time、Processing time，Flink 的无限数据流是一个持续的过程，时间是我们判断业务状态是否滞后，数据处理是否及时的重要依据。
• API，API 通常分为三层，由上而下可分为SQL / Table API、DataStream API、ProcessFunction 三层，API 的表达能力及业务抽象能力都非常强大，但越接近SQL 层，表达能力会逐步减弱，抽象能力会增强，反之，ProcessFunction 层API 的表达能力非常强，可以进行多种灵活方便的操作，但抽象能力也相对越小。

阅读更多

Kafka 是一个消息系统，原本开发自 LinkedIn，用作 LinkedIn 的活动流(Activity Stream)和运营数据处理管道(Pipeline)的基础。

现在它已被多家不同类型的公司作为多种类型的数据管道和消息系统使用。活动流数据是几乎所有站点在对其网站使用情况做报表时都要用到的数据中最常规的部分。

活动数据包括页面访问量(Page View)、被查看内容方面的信息以及搜索情况等内容。

这种数据通常的处理方式是先把各种活动以日志的形式写入某种文件，然后周期性地对这些文件进行统计分析。

运营数据指的是服务器的性能数据(CPU、IO 使用率、请求时间、服务日志等等数据)。运营数据的统计方法种类繁多。

近年来，活动和运营数据处理已经成为了网站软件产品特性中一个至关重要的组成部分，这就需要一套稍微更加复杂的基础设施对其提供支持。

阅读更多

在现实生活中，我们每个家庭都有一个户口本，我们会统一的去户籍中心，去注册自己家的信息，包括自己家的门牌号，家里几个人，如果有人找我们，就可以通过这个来定位，同理微服务中的注册中心也是一样，所有的服务实例都到注册中心去注册，后续大家如果需要查找别的服务，就到注册中心去查找即可

服务调用方式

服务调用方式主要是指微服务中服务之间调用的方式，主要分为两类：

• 基于负载均衡：通过负载均衡设备对外提供VIP地址来实现服务的调用
• 基于注册中心：微服务之间通过服务注册中心进行节点发现，然后在服务端直接调用对应的节点进行调用

阅读更多

随着越来越多的开发人员构建可扩展的云原生应用，利用托管服务来部署和运行这些云原生应用。在过去几年中，这一转变值得人们关注。随着这一转变，微服务架构已经成为构建云原生应用的标准，预计到 2022 年，将有 90% 的新应用采用微服务架构。微服务架构提供了极具说服力的好处，包括可扩展性、松散的服务藕合和独立部署等，但这种方法的成本可能很高，因为开发人员需要了解和熟练掌握分布式系统。

开发人员希望专注于业务逻辑，频繁且增量地迁移遗留代码，同时依靠平台为他们的应用提供所需的规模、弹性、可维护性、灵活性和云原生架构的其他属性。然而，开发人员发现，在云端和边缘之间的可移植性有限，他们不断地解决相同的分布式系统问题，如状态管理、弹性方法调用和事件处理。此外，许多编程运行时通常具有狭隘的语言支持和严格控制的特性集，这使得构建微服务架构变得具有挑战性。

为了使所有开发人员能够使用任何语言和框架轻松地构建可移植的微服务应用，无论是编写新代码还是迁移现有代码，我们很高兴地宣布将 Dapr 开源。

阅读更多

Kubernetes is the cloud’s breakout success story. It’s gone from nothing to the application development equivalent of a superstar in only a few years, a rapid growth that’s left developers looking for better ways to build and manage Kubernetes-hosted applications.

There have been plenty of workarounds and extensions. Tools such as Helm make it easy to deploy resources to clusters, whereas CNAB (Cloud Native Application Bundle) wraps up applications and all their dependencies ready for deployment. At a lower level, services such as Draft help design and build basic services. You can build code and deploy it using familiar containers, and you can quickly assemble elements into Kubernetes applications. You can even automate management with Azure Kubernetes Services.

阅读更多

Hystrix简介

在分布式环境中，不可避免地会有许多服务依赖项中的某些失败。Hystrix是一个库，可通过添加等待时间容限和容错逻辑来帮助控制这些分布式服务之间的交互。Hystrix通过隔离服务之间的访问点，停止服务之间的级联故障并提供后备选项来实现此目的，所有这些都可以提高系统的整体弹性。

Hystrix的历史

Hystrix源自Netflix API团队于2011年开始的弹性工程工作。2012年，Hystrix不断发展和成熟，Netflix内部的许多团队都采用了它。如今，每天在Netflix上通过Hystrix执行数百亿个线程隔离和数千亿个信号量隔离的调用。这极大地提高了正常运行时间和弹性。

阅读更多

Nginx 是一个 免费的 ， 开源的 ， 高性能 的 HTTP 服务器和 反向代理 ，以及 IMAP / POP3代理服务器。 Nginx 以其高性能，稳定性，丰富的功能，简单的配置和低资源消耗而闻名。 Nginx 是一个 Web 服务器，也可以用作 反向代理 ， 负载均衡器 和 HTTP 缓存 。

很多高知名度的网站都使用 Nginx ，如： Netflix ， GitHub ， SoundCloud ， MaxCDN 等。

阅读更多

既然Sentinel开源了，作为 承接了阿里巴巴近 10 年的双十一大促流量的平台，有必要了解一下阿里开源限流熔断方案Sentinel功能、原理、架构、快速入门以及相关框架的比较。

基本介绍

1 名词解释

• 服务限流 ：当系统资源不够，不足以应对大量请求，对系统按照预设的规则进行流量限制或功能限制
• 服务熔断：当调用目标服务的请求和调用大量超时或失败，服务调用方为避免造成长时间的阻塞造成影响其他服务，后续对该服务接口的调用不再经过进行请求，直接执行本地的默认方法
• 服务降级：为了保证核心业务在大量请求下能正常运行，根据实际业务情况及流量，对部分服务降低优先级，有策略的不处理或用简单的方式处理

服务降级的实现可以基于人工开关降级（秒杀、电商大促等）和自动检测（超时、失败次数、故障），熔断可以理解为一种服务故障降级处理

2 为什么需要限流降级

系统承载的访问量是有限的，如果不做流量控制，会导致系统资源占满，服务超时，从而所有用户无法使用，通过服务限流控制请求的量，服务降级省掉非核心业务对系统资源的占用，最大化利用系统资源，尽可能服务更多用户

阅读更多

我们都知道，提高系统性能的最简单也最流行的方法之一其实就是使用缓存。我们引入缓存，相当于对数据进行了复制。每当系统数据更新时，保持缓存和数据源（如 MySQL 数据库）同步至关重要，当然，这也取决于系统本身的要求，看系统是否允许一定的数据延迟。

这里分享几种最常见的缓存策略、它们的优缺点以及使用场景。

Cache-Aside 策略

Cache-Aside 可能是最常用的缓存策略。在这种策略下，应用程序(Application)会与缓存(Cache)和数据源(Data Source)进行通信，应用程序会在命中数据源之前先检查缓存。如下图所示：

我们来看一次请求数据的过程：

• 首先，应用程序先确定数据是否保留在缓存中；
• 如果数据在缓存中，也即 Cache hit ，称作“缓存命中”。数据直接从缓存中读取并返回给客户端应用程序；
• 如果数据不在缓存中，也即 Cache miss，称作“缓存未命中”。应用程序会从数据存储的地方，如 MySQL 数据源中读取该数据，并将数据存储在缓存中，然后将其返回给客户端。

阅读更多

Now 10 years in the wild, Google’s Go programming language has certainly made a name for itself. Lightweight and quick to compile, Go has stirred significant interest due to its generous libraries and abstractions that ease the development of concurrent and distributed (read: cloud) applications.

But the true measure of success of any programming language is the projects that developers create with it. Go has proven itself as a first choice for fast development of network services, software infrastructure projects, and compact and powerful tools of all kinds.

阅读更多

What is KeyDB?

KeyDB is an in-memory, high performance database with support for numerous data types, on-disk persistence and high availability. Compatible with Redis™ API and protocols, KeyDB is a drop-in replacement for your existing Redis™ deployments with numerous enhancements, higher performance, and lower Total Cost of Ownership (TCO).

Designed for use as both a cache as well as use as a primary database, KeyDB is a fast and versatile NOSQL database useful in many applications. Its low resource requirements and high-speed mean fewer instances to manage and much lower costs. KeyDB looks to fully utilize the hardware provided to your instances enabling a higher throughput and efficiency.

阅读更多