关于并发模型

线程模型可能是最经典的线程模型。在多核cpu诞生之前,线程模型就作为一种并发解决方案被提出来并且大规模使用了。

为什么是线程模型?第一是线程模型符合人类线性思维直觉,心智负担小。第二是线程是对进程的历史延续,实现难度低。第三是线程的overhead相对较小,当时的硬件条件不支持更复杂的并发模型。

但是随着多核cpu的发展,并发需求越来越大,人们发现简单粗暴的线程模型存在很多弊病,一些人试图通过软件工程的方式去回避线程模型的问题,一些人则试图扩展线程模型,另一些人则在考虑新的并发模型。

事件驱动,回调属于第一者,netty是其中的代表。轻线程,包括golang的goroutine和各种stackful的协程实现属于第二者。

actor模型则属于第三者,当然,因为os的并发模型是线程的,现在所谓的新的并发模型也只能是base on thread的。

GraalVM支持解释执行LLVM bitcode

graalvm这个东西从2016年关注,最初是因为其纯java实现的jit编译器而吸引注意,本以为是openjdk的一个项目,没想到如今正式发布后却是甲骨文的一个基于openjdk的产品。

相比起之前技术预览阶段,正式发布版本最大的不同是支持解释执行LLVM bitcode,这是否意味着jni接口可以下岗了呢?

使用bandizip代替7zip

多年来一直使用7zip作为日常的压缩/解压软件,但是其实7zip有一个长期存在的拖拽解压bug让人很不舒服,在很多三方窗口里拖拽解压是无效的,而最近发现的bandizip则无这个问题,且兼界面十分漂亮。

https://www.bandisoft.com/bandizip/cn/

该软件免费但不自由,支持创建zip、7z档案,解压包括rar的主流档案格式。一些细节方面的设置也十分讨喜,比如在解压tar格式档案时默认使用utf8编码解析路径。

重新关注docker容器技术

早在2013年的时候我就曾关注过docker这个新事物。那个时候容器其实已经并不是什么新鲜概念了,在docker前头linux世界里就有了lxc和openvz,目光放在整个*nix世界的话容器的历史还要更长。

与lxc基本只用于实验不同,openvz在当时已经是大规模商用的稳定技术,抛开它本身就是一个商用平台的组成部分不说,在当时世界上大部分的廉洁VPS都跑在openvz设施上。我个人对openvz的熟悉程度也比较高,包括一开始的mc平台和之后的梦世界的基础设施都是基于openvz的集群上。

2013年的docker已经是可用的,但是仍然存在许多的致命缺点,就mc来说,aufs文件系统的性能简直差到无法忍受,文件持久化也是个问题,很多人断言docker只适合stateless的微服务。当时也没有overlay网络,构筑一个最简单的集群网络也需要引入大量额外复杂度,以虚拟网桥/交换机来说性能开销也并不小(即使是现在也不建议把bungeecord放在overlay网络的网络里运行,overlay把以太帧封装入udp报文里传输,容器间的流量稍微有个几百mbps带来的额外开销就很夸张了),而最重要的是外围管理设施的缺失。——

现在有swarm,有k8s等等工具,而在当时选择docker就意味着只能集群管理只能自己手lu了。而现在,尽管docker本身的一些缺陷依然没有克服,但是最致命的文件系统性能和网络架构问题已经基本解决,周边设施也随着社区的发展日新月异,可以说跟我刚接触docker时候的0.x版本已经不可同日而语了。

而openvz这些年一直在原地踏步,并且随着el6的大限将至,openvz7不再单独作为基础组件发布,可以遇见到的是openvz的迅速没落,尽管它提供的一些vm级的特性是docker未来也永远不可能提供的。

现今如果要把梦世界的集群迁移到docker还需要解决一些架构上的问题,最麻烦的服务自动发现部分早在几个月前就已经通过插件解决了,代码开源在gayhub,docker世界里有很多为ha准备的工具,我相信如果能够完成迁移工作的话会给服务带来相当大的提升。