夜明的孤行灯

分类： 默认

  • LSM树存储引擎

    B+树使用广泛，而它最大的性能问题是会产生大量的随机IO，随着新数据的插入，叶子节点会慢慢分裂，逻辑上连续的叶子节点在物理上往往不连续，甚至分离的很远，但做范围查询时，会产生大量读随机IO。

    LSM树最早是HBASE引入的，最初目的就是为了克服B+树的弱点。LSM树本质上就是在读写之间取得平衡，和B+树相比，它牺牲了部分读性能，用来大幅提高写性能。本质上就是把树拆开，拆成一个一个小树，当树足够大了再写入，当然读取的时候就需要访问多个树了。在写入硬盘后，也会在一定时机下，处理已经写入的树，进行再次合并。

    LSB树会有一个WAL，因为内存中的数据有丢失风险，所以先写日志，当内存中对应的树刷盘以后删除对应日志就行了。

    LSB树一般有三个放大点需要关注

    • 写放大： 磁盘数据的写入量 / 用户写入的数据量
    • 读放大： 磁盘数据的读入量 / 用户实际要读取的数据量
    • 空间放大：磁盘空间占用 / 有效的用户数据量

    其中写放大往往是最严重的，对它的计算和分析也相对较多。

    写放大是最有意思的，根据LSM的原文，作者提到层与层之间的扇出系数(size ratio)是常量时，写放大最优。FaceBook的文档中有获得最优写放大倍数具体的计算方式，详细推导参见：http://smalldatum.blogspot.com/2018/12/lsm-math-how-many-levels-minimizes.html…

  • 看阿里云云原生架构白皮书

    看阿里云云原生架构白皮书

    阿里云于近日发布了《云原生架构白皮书》，对外开放下载。

    白皮书主要分三大块，第一部分主要是云原生的定义和主要技术，第二部分自然是阿里云作为国内最大的云服务厂商对于云原生架构设计的思考，围绕在周围的相关产品体系和相关实践案例，第三份部分是对于未来发展趋势的研判。

    整体来说内容还是比较充实，对于已经在阿里云上有投入或者准备投入的开发者还是值得一看的。

    云原生

    云原生是Pivotal的Matt Stine于2013 年首次提出，然后这个概念一直沿用至今。云原生发展至今有6年以上，目前看处于第四阶段。

    孵化期（2013年-2014年）
    Docker、微服务、DevOps等的流行，云原声概念初步成型，CNCF的成立，Kubernetes的开源更是补齐了发展的缺乏要素。
    高速发展（2015 年 – 2016 年）
    云原生的容器编排之争落幕，周边生态开始成型。
    野蛮生长 （2017年-2018年）
    大量云原生生态体系的开源项目出现并爆发式增长，Istio、Prometheus、Envoy等相继从CNCF毕业。
    推广期（2019 年至今）
    OAM诞生，定义了云原生应用标准。云厂商的产品体系也趋于完善，经多多年推广，加上大量成熟实践，已经逐步为企业接受。

    云原生的定义各家自然有各家的看法，单从字面上看云原生就是要支持云化，而且要方便的支持云化。
    就这一点看我个人觉得中国信息通信研究院的定义简单直接，它总结云原生的概念为“适合云的应用”和“好用的云架构”。
    Pivotal作为云原生的先驱和探路者，对于云原生的定义前后有变动，其中包括大家熟知的符合12要素的应用，面向微服务等，再到后面的6大特性（模块化、可观测、可部署、可测试、可处理、可替换），现在Pivotal的定义是DEVOPS、持续交付、微服务、容器。

    而阿里云此次的白皮书怎么说的呢？


    云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的 非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、安全、 可观测性、灰度等)，使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。

    这一个说法其实和OAM的定义比较接近，着眼于关注点分离。阿里云白皮书的拆分拆成了三类

    • 业务代码
    • 三方软件
    • 处理非功能特性代码

    而核心特性上提出了七个原则，这个和Pivotal之前的六大特定接近，但是强调了作为云厂商优势的弹性原则。另外就是架构持续演进原则，强调要从架构设计上考虑云迁移的成本/风险，技术上采用数据迁移、网关灰度等方式进行细粒度控制。

    产品体系

    任何厂商白皮书都会提到自身的产品体系，阿里云云原生架构白皮书中的体系图如下：

    阿里云目前大部分产品都是三种路线：

    • 自身开源+商业结合的方式进行
    …

  • Mac上PKG_CONFIG_PATH路径问题

    Mac上有homebrew可以安装常用依赖，但是安装以后pkg-config经常找不到对应的包，需要手动适配PKG_CONFIG_PATH变量。

    一般情况都会安装在/usr/local/Cellar目录下， 最直接的办法就是遍历这里的目录，找到lib/pkgconfig路径的地址，然后加入PKG_CONFIG_PATH中。

    这里可以用一个脚本来处理

    export PKG_CONFIG_PATH=$(find /usr/local/Cellar -name 'pkgconfig' -type d | grep lib/pkgconfig | tr '\n' ':' | sed s/.$//)
    …
  • 构建适用于openwrt的switch-lan-play插件

    构建适用于openwrt的switch-lan-play插件

    openwrt是一个非常实用的系统，附带的插件可以配合满足不同的需求。

    switch-lan-play是一个远程联机的工具，使用时需要一台设备转发switch的网络请求。一般来说使用的时候打开电脑就足够了，如果经常使用或者手边没有电脑，在路由器上运行明显要好很多。

    switch-lan-play官方仓库只提供了win、linux和mac的构建，openwrt的需要自己构建。

    写在前面

    本文是介绍如何构建，需要有相关技术知识储备，如果只是想直接使用，也需要有基本的相关知识储备。也可以参考下：https://www.huangyunkun.com/2021/04/14/switch-lan-play-openwrt-issue/

    构建ipk

    openwrt的ipk包除了程序本体以外一般还需要配置、启动脚本和描述信息。

    先看构建本身，来源还是git，指向switch-lan-play仓库

    https://github.com/spacemeowx2/switch-lan-play.git

    主要依赖是libpcap，版本号就跟随官方仓库，当前为0.2.3

    include $(TOPDIR)/rules.mk

PKG_NAME:=switch-lan-play
PKG_VERSION:=0.2.3
PKG_RELEASE:=1

PKG_SOURCE_PROTO:=git
PKG_SOURCE_VERSION:=v$(PKG_VERSION)
PKG_SOURCE_URL:=https://github.com/spacemeowx2/switch-lan-play.git
PKG_MIRROR_HASH:=c0c663e3fdc95d6d6e8ab401caa2bfb5b5872e00
#PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(PKG_VERSION)

PKG_LICENSE:=GPLv3
PKG_LICENSE_FILES:=LICENSE.TXT

include $(INCLUDE_DIR)/package.mk
include $(INCLUDE_DIR)/cmake.mk

CMAKE_BINARY_SUBDIR := build-openwrt

define Package/$(PKG_NAME)
	SECTION:=net
	CATEGORY:=Network
	SUBMENU:=Lan-play
	DEPENDS:=+libpcap +libpthread +libstdcpp +libatomic @!USE_UCLIBC
    …

  • nx-hbmenu上传Switch应用

    每次开发完应用后都需要走ftp或者usb将生成的nro文件上传到Switch，再运行应用调试查看。每次操作还是比较繁琐。

    nx-hbmenu支持网络加载，在hbmenu界面按Y键盘后，在PC端运行

    nxlink -s -a 192.168.31.66 XXX.nro

    即可。退出应用后需要再次点击Y才能重新上传。

    这里的IP是Switch的IP地址，上传速度比一般的ftp稍微慢一点。…

  • 使用AMis Renderer快速构建页面

    AMis Renderer是一个前端低代码框架，通过 JSON 配置就能生成各种后台页面。

    简单来看就是通过简单的配置（JSON化），搭积木一样的使用已有组件来构建页面。这个对于一些to B的简单页面或者一些简单的小项目是很实用的。

    AMis Render提供两种使用方式，一种是嵌入已有的React Component中，这要求项目本质上还是一个前端工程化的项目。另外一种就是完全不关心React，也没有任何组件定制需求，极简使用。

    官方Demo如下：

    <!DOCTYPE html<html lang="zh"<head<meta charset="UTF-8"<titleAMIS Demo</title<meta http-equiv="Content-Type" content="text/html; charset=utf-8"<meta name="viewport"
        content="width=device-width, initial-scale=1, maximum-scale=1"<meta http-equiv="X-UA-Compatible" content="IE=Edge"<link rel="stylesheet" 
        href="https://houtai.baidu.com/v2/csssdk"<stylehtml, body, .app-wrapper {
    …

  • Switch lan-play原理

    Switch的机器要是被ban了（原因可能有很多，比如买了淘宝数字版。。。），最大的问题就是不能联网了，但是部分游戏是支持局域网联机和当面联机的，所以理论上是可以一起玩的。

    lan-play的作用就是可以让大家在网络环境下也做到当面联机或者局域网联机的效果，这样足不出户就可以和朋友联机。

    由于最近用lan-play老是炸岛，所以花时间看了下大致原理。lan-play大体工作原理如下：

    其中电脑运行了lan-play client，它会和私服链接。而你的Switch需要和电脑链接同一个路由器。

    Switch和lan-play client的通讯

    Switch和lan-play client在一个路由下，而Switch上配置的IP和Gateway地址配置了10.31.XX.XX和10.13.37.1，但是实际上lan-play并没有在这个IP提供服务，而是通过pcap监听相关的包，这就是为什么安装lan-play的第一步是安装pcap。

    pcap是一个抓包工具，支持协议比较广泛，包括

    • Ethernet, Linux SLL, raw IP, PPP (RFC1661, RFC1662), BSD (Mac OS X) loopback encapsulation, and Radiotap
    • IEEE 802.11
    • Probe Request
    • LLC and SNAP
    • IEEE802.1Q
    • ARP
    • IPv4 (RFC791 and RFC1349) and
    …

  • Switch开发环境搭建

    如果由于各种原因需要在Switch上做开发，那么第一个需要的就是环境配置。目前主要需要的是devkitA64和libnx。

    devKitA64是在devkitPro下的，另外还有ARM、3ds等，如果只是Switch开发安装A64即可。这里注意下devkitPro没有版本号管理一说。

    Mac

    我这里以mac为例，首先下载devkitPro_pacman，按照说明安装。然后确认下xcode情况

    xcode-select --install

    修改环境配置为

    export DEVKITPRO=/opt/devkitpro
export DEVKITARM=${DEVKITPRO}/devkitARM
export DEVKITPPC=${DEVKITPRO}/devkitPPC
export PATH=${DEVKITPRO}/tools/bin:$PATH

    libnx在上面安装完成后会自带，不需要额外处理。

    Ubuntu

    如果是ubuntu系统，安装步骤基本一致，首先确保依赖

    apt-get git wget install libxml2 libstdc++6 gpg xz-utils make -y

    安装pacman并设置环境变量

    wget https://github.com/devkitPro/pacman/releases/download/devkitpro-pacman-1.0.1/devkitpro-pacman.deb
     RUN dpkg -i devkitpro-pacman.deb && dkp-pacman -S
    …
  • Github Action使用私有Runner

    Github Action使用私有Runner

    Github Action对于私有库是有一定的分钟数限制，当然如果升级账号可以获得更长时长。

    考虑到有一个空余服务器，且CI对于环境要求没有太高，普通的linux即可。Github Action文档提供了完善的接入说明，对于Windows、Linux、MacOS都支持。

    考虑到方便和隔离，决定在Docker中运行，网上有别人打包好的，直接使用即可。在配置界面找到自己的token，然后运行。

    docker run --name your-runner -e GITHUB_REPOSITORY="github address" \
  -e GITHUB_TOKEN="your token" \
  -e RUNNER_NAME="your-runner" \
  -e REPLACE_EXISTING_RUNNER="true" \
  htynkn/github-action-runner

    在Github上可以看到新的Runner信息

    workflow中修改runs-on为self-hosted就可以了

    runs-on: self-hosted
    …

  • Github Action加密文件的处理

    GitHub Action提供了对于Secrets的支持，可以保存常见的私密信息，比如API_TOKEN等信息，但是对于有些场景还需要私密文件的支持，比如Flutter打包Android APK的时候需要两个文件，一个是key.jks，另外一个是相关配置，一般为key.properties或者放在local.properties中。

    这种情况可以先本地加密需要的文件，然后在Github Action中解密，解密所需的信息放在Github Action Secrets即可。

    这里使用gpg AES256进行加密，指令如下：

    gpg --symmetric --cipher-algo AES256 key.properties

    加密的时候输入秘钥，并配置在Github Action Secrets中。将加密好的文件放在.github目录中，并创建解密用的脚本

    #!/bin/sh

# Decrypt the file
gpg --quiet --batch --yes --decrypt --passphrase="$LARGE_SECRET_PASSPHRASE" \
--output $GITHUB_WORKSPACE/android/key.properties $GITHUB_WORKSPACE/.github/secrets/key.properties.gpg

echo "Decrypt key.properties done"

gpg --quiet --batch --yes
    …