Akka入门系列(六):akka cluster中的路由和负载均衡

在使用路由功能之前,我们需要先了解下常规概念:

  • Router 路由器,消息由外部发送到路由器,再由路由器通过路由算法转发给具体的执行者,相当于消息的中转站。
  • Routee 路由目标,最早处理消息的地方。

在Akka中,提供了两种做路由的方式:

actor, akka, 分布式, 并发

Akka入门系列(五):akka cluster的基本使用

前面一个章节akka cluster管理介绍了Akka Cluster的底层原理,这一章就来看看如何使用。

集群后台接入

对外

actor, akka, 分布式, 并发

Akka入门系列(四):akka cluster原理

在前面remote actor一章提到过,akka remotingPeer-to-Peer的,所以基于remote功能的cluster是一个去中心化的分布式集群。

Akka Cluster将多个JVM连接整合在一起,实现消息地址的透明化和统一化使用管理,集成一体化的消息驱动系统。最终目的是将一个大型程序分割成若干子程序,部署到很多JVM上去实现程序的分布式并行运算(单机也可以起很多节点构成集群)。更重要的是, Akka Cluster集群构建与Actor编程没有直接的联系,集群构建是在ActorSystem层面上,实现了Actor消息地址的透明化,无需考虑目标运行环节是否分布式,可以按照正常的Actor编程模式进行开发。

我们知道,分布式集群是由若干节点组成的,那么节点的发现及状态管理是分布式系统一个比较重要的任务。Akka Cluster中将节点的生命周期划分为:

actor, akka, 分布式, 并发

P2P 网络核心技术:Gossip 协议

背景

Gossip protocol 也叫 Epidemic Protocol (流行病协议),实际上它还有很多别名,比如:“流言算法”、“疫情传播算法”等。

这个协议的作用就像其名字表示的意思一样,非常容易理解,它的方式其实在我们日常生活中也很常见,比如电脑病毒的传播,森林大火,细胞扩散等等。

event sourcing, 分布式

Vector Clock/Version Clock

研究Akka过程中,发现Akka的node间是Peer-to-Peer的,就意味着任何一个节点都能处理来自外部请求,那就存在一个一致性的问题,即如果集群中两个节点间的通讯断了,但是又都能对外提供服务,这时各自在接受请求造成的状态变化应该如何解决?Akka采用的是Vector Clocks来解决一致性的。这个算法常见于分布式存储上,对于EBA也很常见,所以如果要搞EventSourcing,这个知识可能会被用到。在研究Vector Clocks时发现两篇好文,本文是其中之一,讲的非常白话清晰,算是先讲算法基础概念,后一篇是直接讲算法实现了。另一篇讲简单实现的我就不转了,有兴趣的直接猛击这里跳转。

physical clock

机器上的物理时钟,不同的机器在同一个时间点取到的physical clock不一样,之间会存在一定的误差,NTP可以用来控制这个误差,机器之间的时钟误差可以控制在几十ms以内。两个事件a和b,a在机器M1上physical clock为12点5分0秒6ms发生,b在机器M2上physical clock为12点5分0秒7ms发生,这并不代表a发生在b之前,因为两个机器上取到的physical clock和真实时间(这个时间就是国际标准时间UTC,可以通过原子钟,internet,卫星获得)之间都有误差。比如机器M1的physical clock比真实时间慢10ms,那么事件a实际上是在真实时间12点5分0秒16ms发生的,机器M2的physical clock比真实事件慢5ms,那么事件b的实际上是在真实时间12点5分0秒12ms发生的,显然,事件a发生在事件b之后。

event sourcing, 分布式

Node.js的__dirname,__filename,process.cwd(),./的一些坑

起因

原文收录在我的 GitHub博客 (https://github.com/jawil/blog) ,喜欢的可以关注最新动态,大家一起多交流学习,共同进步,以学习者的身份写博客,记录点滴。

最近在学习Node.js里面的fs模块,遇到了一个比较诡异的现象,踩到了坑,就是读取当前目录下的一个文件,死活读取不到,由于之前对于Node.js里面的path模块也不太熟悉,也没系统研究过,所以今天就踩了这个坑,记录踩坑的过程,防止以后踩坑和大家也踩坑。

js, nodejs

自动初始化Gitalk评论

最近重新将博客整理了一下,之前忙的都没有时间取打理。其中一下是用Gitalk更换原来的评论系统。
Gitalk是利用了GithubAPI,将网站的评论转写到Github上指定仓库的Issues里,相当于做了一个代理。风格做的简约漂亮,但每种不足的是每次发表了新博文后,需要自己用管理员账号登陆下评论系统,否则就会:

所以就萌生了写个nodejs代码去代替人工初始化的想法。

Gitalk安装

Gitalk, blog, gulp, nodejs

Akka入门系列(三):remote Actor

虽然Akka在单机上可以运行上百万的Actor,但出于容错、负载均衡、灰度发布、提高并行度等等原因,我们仍然需要能在多个不同的服务器上运行Actor。所以Akka提供了akka-remoting的扩展包,屏蔽底层网络传输的细节,让上层以及其简单的方式使用远程的Actor调度。
官方文档:https://doc.akka.io/docs/akka/current/remoting.html

适用场景

remoting的存在其实是为akka cluster做底层支持的,通常并不会直接去使用remoting的包。但为了了解cluster的底层原理,还是有必要看下remoting
同时,remoting被设计为Peer-to-Peer而非Client-Server,所以不适用于基于后者的系统开发,比如我们无法在一个provider为local的Actor里去查找一个remote actor发送消息,必须两者均为remote actor,才满足对等。

actor, akka, 并发

Akka入门系列(二):Actor

Actor模型

由于AKka的核心是Actor,而Actor是按照Actor模型进行实现的,所以在使用Akka之前,有必要弄清楚什么是Actor模型
Actor模型最早是1973年Carl Hewitt、Peter Bishop和Richard Seiger的论文中出现的,受物理学中的广义相对论(general relativity)和量子力学(quantum mechanics)所启发,为解决并发计算的一个数学模型。

Actor模型所推崇的哲学是”一切皆是Actor“,这与面向对象编程的”一切皆是对象“类似。
但不同的是,在模型中,Actor是一个运算实体,它遵循以下规则:

actor, akka, 并发

Akka入门系列(一):基本介绍

什么是Akka,它能干什么?

互联网系统的发展,大多数情况下都是业务倒逼的。发展过程不外乎以下几步:

  1. 最开始时,一个简单的MVC程序就可以,甚至是早期的J2EE也能得到很好的性能。
  2. 忽然某一天,系统压力大了,一些功能变得比较慢,这时会尝试去做代码重构优化,必要的地方开始使用进程内MQ以及线程池,开启异步及多线程
  3. 再往后,单台也不能满足系统的吞吐了,这时就得上集群,前面一个负载均衡,后面部署多台相同的服务器,将压力均衡到若干服务器上,甚至数据库都开始做切片。
  4. 再往后,继续优化,将一些压力大的功能单独提出来,做成一个Service,对外部提供服务,可以是REST,也可以是RPC,用这种方式来提高服务器利用率,毕竟有些业务只需要IO,而有些业务需要很强的CPU,根据实现逻辑不同,需要的物理资源也不同。而这时,简单的负载均衡也无法适用了,需要功能相对复杂的网关总线,并且各种分布式下的难点都出来了——调度、分布式容错熔断弹性扩容、分布式事务、灰度发布、压力调整等等。

actor, akka, 并发, 并行