BLOG https://blog.yayh.life/ Sat, 16 Nov 2024 04:20:36 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed zh-CN All rights reserved 2024, guozichun <![CDATA[B-Money]]> https://blog.yayh.life/article/6b509ef9-09ec-4879-8520-c76dfa6911de https://blog.yayh.life/article/6b509ef9-09ec-4879-8520-c76dfa6911de Thu, 13 Jun 2024 00:00:00 GMT
😆
Arise, you have nothing to lose but your barbed wire fences!

💰B-Money

戴维的梦想。是他从 Tim May’s的”The Crypto Anarchist Manifesto’的设想而落地的一个提议，加密货币的早期版本是由这篇论文的概念衍生而来，但是戴维发布的是一个Proposal，而没有具体的代码或相关实现。
谁有多少钱的账户由一部分参与者（从现在开始称为服务器）而不是所有人保存。这些服务器通过Usenet样式的广播信道链接。在此信道上广播的事务消息的格式与第一个协议中的格式相同，但每个事务的受影响参与者应验证该消息是否已被随机选择的服务器子集接收并成功处理。

Tim-May

加密无政府主义 ——— The Crypto Anarchist Manifesto
暴力将会被避免，因为你根本找不到参与者的真实姓名和肉身位置。
 

PoW

Proof-work 工作量证明
PoW造币是通过消耗对应的计算量来产生同等价值的奖励（基本都是货币），但是需要计算的内容并不具备实际量化的意义，而是纯粹的消耗。 举个🌰
以BTC为例子，算出对应的数学题后就拥有当前区块的记账权，同时也会获得分配给自己的奖励。每2016会调整一次计算难度，假设当前的计算是一个18位长度的Hash值,并没有任何算法能进行对应的解密，只能通过类似暴力的方式一次次进行对称重试直到找到答案，而每个矿工去计算的时候可以自由的选择方式从哪里开始进行，这里对于高算力的矿工来说提升的只是几率而不是靠速度快就能百分之百的完成计算，低算力的也同样会有机会。
 
优劣点分析：
  1. 去中心化程度高，但是为了确保区块的共识的确认、时间无法缩短又导致非常的不环保。
  1. 计算成本过高导致常见的攻击无效、例如双花攻击、篡改数据，但一旦攻击程度到达51%，而区块算力不够时就无法承受。
 
流程
 

双花问题

BMoney无法解决双花问题、因为没有共识机制来证明，只能确保PoW的工作量证明，但不能保证工作产生的值被多次使用。
因为没有中央账本来进行管理，BMoney没有提供解决类似拜占庭将军的类似问题，而Btc的出现就弥补了BMoney 带来的共识机制问题，通过在分布式的各个参与者记录账本来保证区块的连续性和真实性。
通过区块链、共识机制、时间戳服务器来实现BMoney 没有做到的那部分。
比特币通过链，让后来区块的安全去累加加固以前区块的安全，是非常厉害的安全思路。
 
notion image
 
 

拜占庭将军问题

当 n > 3t 时，可以冗余出现问题的情况。
 

PoS

Proof of Stake 权益共识，解决资源大量浪费的情况，当持有占总币数量、时间决定是否拥有记账权的概率越大。
 
PoW机制中工作机制需要耗费大量的计算量得到 nonce , Pos机制则采取更快速的算法。
H = 哈希函数
t = UTC时间戳
Bprev = 上个区块
balance(A) = 账户余额
当balance(A)足够大的时候，数值越大同等算力的情况下越容易找到符合的t
 
引用知乎的一个例子总结: 你上学的时候，班级里发生的行为需要被记在班级的一个大家公用的账本（区块链）上。
老师或者同学们用这个公用的账本进行记录，并且有一种专门用来支付这个账本上大家记录的、需要支付的代币，我们暂且把它叫做Good币。
这些币可以兑换成钱。你们班级的公共账本不是一个大本子，而是由很多个小本子中间连接一条线组合成的。
在PoW机制下，老师是用一道特别难的数学题来让第一个算出来的同学获得记账权，在这个机制下会导致大部分的同学计算题目导致的时间资源浪费，目前重新推举了PoS的共识机制.
调整区别如下
  1. 不再计算数学题。
  1. 增加币龄的概念(持有币的时间,例: 每个币每天产生1币龄)
  1. 增加持有币的统计 （持有的币越多几率越高）
  1. 增加币的年利率（假设5%）
  1. 每次新区块产生之前会清空币龄
  1. 每清空365个币龄就会产生5%的年化利息
 
现在，如果 A 持有 30天 100个 Good币，则 30 * 100 * 0.05 / 365 = 0.4109589041 Good币
 
 

总结

根据PoW和PoS来看，在去中心化的区块技术下没有最好的机制只有更好的机制, 每种机制都有取舍、包括还有新推出的PoA机制，多多少少都有对应的优劣。

📎 参考文章

 
]]> <![CDATA[从对腾讯云COS加密的需求开始的轮子]]> https://blog.yayh.life/article/dc112037-fd4b-4843-9339-ab04c24d039a https://blog.yayh.life/article/dc112037-fd4b-4843-9339-ab04c24d039a Thu, 25 Apr 2024 00:00:00 GMT
😀
一句话需求： 返回给前端通过腾讯云COS存储的图片预签名URL，简单来说。出于安全考虑（这个方式存疑！）就是要把存储在COS里的某些文件数据进行签名加密之后进行可控的访问，可以添加的参数包括不限于 Query\Headr 可以设置签名的有效时间在一定范围时间内可以用签名好的链接进行访问，如果超出时长就失效。
 

📝 签名步骤

通过对应的APPID + Bucket + KEY 等参数通过腾讯云COS鉴权之后后进行对某个文件Key的预签名或者直接获取签名后的Download URL

 

但是没有好用的NestJS的腾讯云包

腾讯云的SDK小版本比较频繁、问题也比较多 依赖更新也很草率。 COS和CLOUD的两个SDK是分了两个项目包 导致打包的问题（+2小时）目前最新的在16小时前发布的 4.0.842 有和目前开发项目的sub-modules包的依赖冲突，目前比较稳定的是 4.0.837 目前实现的是 OCR、SMS、COS
索性就写了个包，将来项目上也可以复用和慢慢升级改造。
@cardbrother/nestjs-tencent-cloud-sdk
因为底层冲突问题 目前version发布的比较混乱（回头会抽空整理下）
npm: @cardbrother/nestjs-tencent-cloud-sdk
nestjs tencent cloud sdk. Latest version: 1.0.11, last published: 3 hours ago. Start using @cardbrother/nestjs-tencent-cloud-sdk in your project by running `npm i @cardbrother/nestjs-tencent-cloud-sdk`. There are no other projects in the npm registry using @cardbrother/nestjs-tencent-cloud-sdk.
npm: @cardbrother/nestjs-tencent-cloud-sdk
https://www.npmjs.com/package/@cardbrother/nestjs-tencent-cloud-sdk?activeTab=readme
npm: @cardbrother/nestjs-tencent-cloud-sdk
 

回到加密需求本身

考虑以后难免需要签名加密的图片或者文件可能会有，业务实现的方式变成拦截器来实现并不是在业务中固定 核心代码
 
调用方式
 
 

结论

综上，所以实际工作量超出预期（顺便提了个PR给changeset/action 🍉)
notion image
 
]]> <![CDATA[从西门开始一路向东-岳麓山西门徒步]]> https://blog.yayh.life/article/2da19215-3d61-43f7-ae06-aeb4101e83ff https://blog.yayh.life/article/2da19215-3d61-43f7-ae06-aeb4101e83ff Mon, 29 Apr 2024 00:00:00 GMT
😀
“没人疼就去爬山吧，爬完浑身疼。” 那天也不知道为什么，珩坨妈妈导航到了西门。
notion image

🚗 出发

π崽近日一直跟我念叨想去爬山

我说 游乐场和爬山你二选一，他居然毫不犹豫的选择了爬山。
 
正好近日我调休还剩余几天，五一前夕。趁着假期人流高峰来临之前夜。索性休假带着π崽珩坨去岳麓山
 

海尔兄弟👬 不畏困难

居然没想到，几乎99%完全独立走完全程的哥哥。一路上不哭也不闹尽量自己向上攀爬台阶的弟弟，共同愉快的完成了登顶。

🤗 沿路都在享受过程 没有拍很多照片

notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
]]> <![CDATA[使用Rollup构建React项目]]> https://blog.yayh.life/article/8ce7ef45-3263-476d-94e1-48da9a75561c https://blog.yayh.life/article/8ce7ef45-3263-476d-94e1-48da9a75561c Fri, 29 Mar 2024 00:00:00 GMT
💡
最近参加了北京大学计算与数字经济研究院下的工业智能的面试，一面之后二面需要在复试之前做2个小Quize，因为是全栈岗，所以考核中也包括了一个前端组件的实现，实现要求很自由并没有任何限制。 不想用太重的框架或成熟生态技术脚手架来做这个实现，正好对比了目前生态各个毕竟流行的打包方式，Webpack、Vite、esbuild等等，看到目前比较火的Vite其实内部打包也是利用的Rollup来做的处理只是非显性的配置，联想起多年前在Ant做过的统一认证认证的Sdk，当时也是选用的Roullup早期版本方案来做的打包输出，那时还没有很完善的生态周边插件，现在朝花夕拾了
 
 

准备

 
使用的包管理器是 yarn@4.1.1
 

安装依赖

 
首先按照rollup对React项目中所需要用的包开发依赖进行安装
 
关键开发依赖库的用途
  • rollup-plugin-commonjs 将CommonJS模块转换为ESM
  • rollup-plugion-node-resolve 帮助Rollup直接查找并使用第三方库 node_modules模块
  • rollup-plugin-clear 清空输出目录
  • rollup-plugin-terser 压缩
  • @rollup/plugin-typescript rollup编译解析typescript
  • rollup-plugin-serve 开发服务启动（热更新）
 
 
 

配置

 
初始化配置
 
yarn dlx tsc —init or tsc --init
yarn dlx @yarnpkg/sdks vscode
Then, In VSCode
CMD + SHIFT + P → Select Typescript Version
Use .yarn/sdk/typescript/lib
 
Rollup配置
 

Rollup相关回顾

 

ES6 Module

 
 

导入第三方模块

 
在rollup中需要引入第三方模块时，需要引入插件 rollup-plugin-node-resolve 来实现，因为默认rollup本身只能通过本地文件路径来引入模块，并不能通过包的名称来引入node_modules中安装的第三方类库。
 

Tree Shaking 树状摇曳

 
Rollup 提供Tree-Shaking功能，这个形象的名词描述了功能就像是摇晃树，那些不再被需要的树枝叶子会掉落下来，这里指的是那些不需要被打包进去的代码。
 
这个功能在Webpack中可以通过 babel-plugin-import 可实现按需加载减少打包体积
 
 

CommonJS 和 ESM

 
为了确保你的 ES 模块可以立即被处理 CommonJS 的工具，例如 Node.js 和 webpack 使用，你可以使用 Rollup 编译成 UMD 或 CommonJS 格式，然后在 package.json 文件中使用 main 属性指向编译后的版本。如果你的 package.json 文件还有一个 module 字段，那么像 Rollup 和 webpack 2+ 这样的可感知 ES 模块的工具将直接 导入 ES 模块版本。
 
默认rollup 是不支持CommonJS打包的，默认输出的为ESM，更偏向于前端类库支持。如果需要想在Rollup中实现CJS 输出的话，需要引用 rollup-plugins-commonjs 来实现。

🤗 总结归纳

当需要使用一种简单有效的对类库的打包当时Rollup 还是非常适用的，但是如果开发一个复杂度更高项目而不是单一功能或表现的库，还是需要webpack或Vite等更加丰富完善的打包工具。

📎 参考文章

]]> <![CDATA[Prometheus 监控预警]]> https://blog.yayh.life/article/806529b1-70c5-45a7-8582-28f778b4634c https://blog.yayh.life/article/806529b1-70c5-45a7-8582-28f778b4634c Wed, 27 Mar 2024 00:00:00 GMT

💡Prometheus能做什么？

 

Google SRE的运维理念

SRE是一种运维的标准、亦或者是一种岗位职责制度，SRE制度里有一条红线，运维的人只能把一半的时间花在运维上，另外一半的时间必须搞工程上、研发上的东西。研发可以是写工具，可以是参与系统设计，参与可靠性的提高，但是要保证运维不能只干运维
 
主要定位作为企业服务监控告警解决方案
 

核心组件

 
  1. Prometheus Server 主要用于抓取数据和存储时序数据，另外还提供查询和 Alert Rule 配置管理。
  1. Client libraries 用于对接 Prometheus Server, 可以查询和上报数据
  1. Push Gateway 用于批量，短期的监控数据的汇总节点，主要用于业务数据汇报等。
  1. Exports 各种汇报数据的 exporters ，例如汇报机器数据的 node_exporter, 汇报 MongoDB 信息的 MongoDB exporter 等等
  1. AlertManage
      2. 用于告警通知管理的 alertmanager 。
       
       
服务架构图
服务架构图
 

服务流程简述

 

TIPS:

Prometheus 的数据是基于时序的 float64 的值，如果你的数据值有更多类型，无法满足。
Prometheus 不适合做审计计费，因为它的数据是按一定时间采集的，关注的更多是系统的运行瞬时状态以及趋势，即使有少量数据没有采集也能容忍，但是审计计费需要记录每个请求，并且数据长期存储，这个 Prometheus 无法满足，可能需要采用专门的审计系统。
OpenTSDB的表示法是一致的
时序数据库 OpenTSDB
 

数据模型

索引

Prometheus存储的是时序数据, 即按照相同时序(相同的名字和标签)，以时间维度存储连续的数据的集合，（但不保证连续不中断)
 
时序由time series，<metric [name]>{<label name=[values…]>, ...} 一组 K/V标签格式定义的具有相同的名字以及标签属于相同时序。
 
名称规则
  • 时序的名字可以使用规则为 ASCII字符，数字，下划线，以及冒号组成，它必须满足正则表达式[a-zA-Z_:][a-zA-Z0-9_:]* 其名字应该具有语义化，一般表示一个可以度量的指标，例如 http_request_total
  • __开头属于Prometheus保留
  • 支持中文
 
 

时序样本

  • float64
  • unix时间戳
 

格式

 
 

Metric时序的4种类型

 
  • Counter 表示数据收集指标用于趋势变化的，例如增长的请求数、异常等统计值
  • Gauge 表示数据瞬时值，服务器压力等指标，磁盘、内存、网络吞吐、CPU占用率等
  • Histogram 主要用于表示一段时间范围内对数据进行采样（通常是请求持续时间或响应大小），并能够对其指定区间以及总数进行统计，通常它采集的数据展示为直方图。
  • Summary 由 <basename>{quantile="<φ>"}，<basename>_sum，<basename>_count 组成，主要用于表示一段时间内数据采样结果（通常是请求持续时间或响应大小），它直接存储了 quantile 数据，而不是根据统计区间计算出来的。
  • Histogram vs Summary
 

作业和实例

 
 
Tips:
独立的数据源（target) 在Prometheus中称为 Instance 包含当前相同类型实例的集合叫做 Job
 
 

自动生成标签和时序

如果其中任一标签已经在此前采集的数据中存在，那么将会根据 honor_labels 设置选项来决定新标签。
 
对每一个实例而言，Prometheus 按照以下时序来存储所采集的数据样本：
 
 
 

功能模块

 

Server

 

Exporter

 

PushGateway

 
 
 

配置

 

全局配置 - Global

告警配置 - alerting

规则文件配置 - rule_files

拉取配置 - scrape_configs

远程读写配置 - remote_read remote_write

 
 
 

围绕网关服务健康度检测

 
 
 
部署一台mysql服务
企业微信推送消息测试
 
 
 
 

🤗 总结归纳

 
  • Prometheus 需要手动修改文件配置。
  • Prometheus 适用于主机监控，还适用于 Cloud, SaaS, Openstack，Container 等监控。
  • Prometheus 属于一站式监控告警平台，依赖少，功能齐全。
  • Prometheus 支持对云或容器的监控，其他系统主要对主机监控。
  • Prometheus 数据查询语句表现力更强大，内置更强大的统计函数。
  • Prometheus 在数据存储扩展性以及持久性上没有 InfluxDB，OpenTSDB，Sensu 好。
 
 

📎 参考文章

]]> <![CDATA[OpenTSDB]]> https://blog.yayh.life/article/e5afa554-4564-41ea-a099-50c922dea5a3 https://blog.yayh.life/article/e5afa554-4564-41ea-a099-50c922dea5a3 Wed, 10 Apr 2024 00:00:00 GMT
😀
本文由之前写的 《Prometheus》 衍生而来

🕰 基于时间

对于采集频率快、采集依赖时间维度、测量点庞大的数据存储结构有一种比较成熟的解决方案，对于这系列的数据格式称为 基于时间序列数据。
 
而针对这部分数据特性，关系型数据库又不再满足，转而出现了针对性时间序列数据存储的数据库。
 
基本需要满足的特点有:
  • 根据时间序列快速写入
  • 持久化
  • 多维度聚合查询
  • 精确到毫秒
  • 不需要转换步骤存储数据和写入一致
  • 永久保留原始数据
 
 
OpenTSDB是TSD和实用命令组成的，独立且没有master、不共享状态。
底层是通过HBase在存储数据，必须先有HBase环境
 

💡核心概念

 
  • Metric 监控项/指标
  • Tags 维度/标签
  • Value 值
  • Timestamp 时间戳
  • DataPoint 某个Metric在某个时间点的数值
    • 格式例如： Timestamp-Tags-Metric-Value
 
 

🤗 总结归纳

OpenTSDB不适合超大数据量，在千万级、亿级中提取几万条数据，比如某个指标半年内的5分钟级别的数据，还是很快响应的。但如果再提取多点数据，几十万，百万这样的量级，又或者提取后再做个聚合运算，OpenTSDB 就勉为其难，实际使用的时候用作服务端机器的监控无任何问题，如果作为客户端APP监控，响应就比较迟缓。
 
TIPS: 如果需要支持特大批量时序数据，建议使用Druid或InfluxDB，其中InfluxDB是最易用的时序数据库。

📎 参考文章

 
]]>