从ERC20 USDT分析区块链合约原理
加密货币和稳定币加密货币（Cryptocurrency）又经常被称为加密资产（Crypto Asset），是指在区块链技术上运行的数字资产，如比特币（Bitcoin）、以太坊（Ethereum）等，同时也衍生出其他类型的加密资产，如 NFT（非同质化代币）等。此类货币相对于现实世界无固定的锚点，其价值由市场供需决定，且由于区块出块难度调整、市场流动性等因素，价格会有较大波动。为了解决这一问题，市场衍生出了稳定币（Stablecoin）。
稳定币（Stablecoin）是指通过特定机制保持价值相对稳定的加密货币，通常与法定货币（如美元、欧元）挂钩。目前市场上常见的稳定币包括 USDT（Tether）、USDC（USD Coin）等。根据发行机制不同，稳定币主要可分为三类：法币抵押型、加密资产抵押型和算法稳定币。以 USDT 为例，它属于法币抵押型稳定币，由 Tether 公司发行，理论上每发行 1 枚 USDT，Tether 应持有价值 1 美元的储备资产（包括现金、债券等），形成 1:1 的锚定关系，用户理论上可以随时用 1 USDT 兑换 1 美元。
多链问题解决了解区块链的玩家都知 ...
区块链和智能合约工作原理
最近经常和一些朋友聊到区块链相关内容，很多人对区块链的理解只停留在数字货币，对整个区块链及其相关衍生物的了解程度都比较低，我来整理一下最基本的区块链工作原理及知识，以做科普。
区块链？区块链概念最早可以追溯到中本聪时间。2008年中本聪提出了加密数字货币和相关加密算法的概念，从这个时间起，区块链就逐渐的开始在互联网上生根发芽。最早期大部分人都认为比特币是一个骗局，因为这种货币既没有实体，也没有实际价值（注意区分价值和价格，最早期价格也许有，但是价值是确实没有的），所以在最早期持有持有比特币的那一群人在领到mint后的不久都分分出售了手中的BTC，所以现在币圈很难见到手上有上千个BTC的投资者，如果从2012年持续持有BTC的话，现在的收益已经会有几千倍了，从BTC的市值就不难看出，web3在近些年的发展有多迅速了。
那么，现在有一个现实的问题，区块链就是加密货币吗？加密货币是否就是区块链的全部？
区块链原理（基于Ethereum 主网）先从区块链这三个字进行解读，这个词可以拆分为区块和链两部分，区块顾名思义，就是一个一个的数据块，链就是一个链条，组合起来就可以把区块链解释为数据块组成的 ...
docker网络转发路由模型
前叙docker是目前容器服务最常用的containerd上层构建，其docker工具链调用containerd底层实现容器调度和管理。在日常的使用环境中，docker常用四种网络模式：
1、br模式：通常dockerd在拉起时，会在linux系统中生成一个叫docker0的虚拟网卡，这个网卡的ip通常是172.19.0.x，这个网卡不被绑定到任何物理网卡上，所以也就不会进入物理冲突域。在使用br模式时，生成的容器和docker0网卡使用同段ip，以docker0作为网关，流量经过iptables后转发进入外网，或者说流量从物理网卡进入后流量经过iptables转发到docker0后转发到对应目的地址。也就是在默认情况下，出向和入向流量链路大体是对称的。
2、Host模式：容器直接复用宿主机网络，不同容器使用的是同一个ns，也就是不同的容器必须使用不通的端口，否则会冲突
3、None模式：无网络模式，这个直接就是字面意思，没有分配ip，也没有网络，用的地方比较少
4、overlay模式：跨机通信会经常用到，主要用VXLAN实现
这里还经常会用到一种特殊的网络模式：
5、MACVLAN: ...
supervisor子进程oom导致supervisord进程退出问题排查
背景这个问题出自一个线上故障。uwsgi进程查询数据库内容过大导致进程oom，同时supervisord进程接收到一个退出信号后进行优雅退出。因为supervisord进程退出所以uwsgi进程没有被重新拉起导致业务故障。
架构说明
本次故障主要涉及项目中心服，中心服用到的技术栈为python3.11+uwsgi+mysql+mongo+redis，中心服由两个进程构成。uwsgi作为中心服的api接口，也是用户访问的主业务入口，push服务是一个异步推送服务，主要为用户推送信令以及处理一些异步指令。这两个进程都由supervisor进程管理，supervisor以apt方式进行安装。
现场描述uwsgi服务发布了新的版本，新增了评论检测功能（6月4号，历史原因，说不得）导致mongodb查询量剧增，查询结果超级大，之后uwsgi服务和push服务以及supervisor服务全部异常退出（不难想到是oom导致的进程被kill），nginx仍可正常进行服务，但用户访问报错500，errorlog报找不到uwsgi.sock(nginx反向代理到uwsgi的socket文件)，服务不可用。 ...
滴滴故障猜测分析
事件背景11 月 27 日，滴滴出现多端 app/小程序服务异常，截至今天滴滴并未公布具体故障原因，网上说法众说纷纭，今天对这个问题展开讨论猜测一下可能的情况。
故障表现滴滴多端不可用（包含用户端/司机端/青桔），显示网络异常，无故障期间 http/tcp 抓包，无法故障回放。网传滴滴内网同步异常，暂无求证门路。
故障猜想
网络攻击（网传）
k8s 升级故障（网传）
以下均为猜测
中间件及 db，系统内核层面等程序爆发式 bug
白名单异常
中台重要环节故障导致调用链断裂
业务引擎 bug
故障猜想论证网络攻击网络攻击具有不确定性：不确定来源，不可预知流量，不确定攻击时间。本次故障看来从时间持续性较长，具有一定的被攻击的特征，但是在受到攻击后通常企业会做以下操作：
接入流量清洗，但是对于被攻击目标太大时使用流量清洗或者 WAF 也是无力的，会引入很大的接入成本和使用成本
直接切换入口，切换入口主要风险点在于是否有备用 ip 可以更换，链路是否冗余，域名 ttl 是否过长，但是故障收敛速度很快，不过这种方式基本只会存在于单业务故障的时候
从以上解决方案来看，故障时间都可以在较 ...
配置文件动态获取
优点服务可以做到动态更新，配置更新时不需要停服，且文件更新后不需要重启服务。
源码分析12345config.Setup( file.NewSource(file.WithPath(configYml)), database.Setup, storage.Setup,)
Options思想在python中，形参可以定义为可选参数，但是在go这种强语法的语言中形参总是不可变的，所以我们就要引入一种Options的方式来将不可变的参数转换为可变的参数，如下边一段代码：
1234567891011121314151617181920212223242526272829package mainimport "fmt"type Options struct { Test1 string Test2 string}type Option func(*Options)func WithTest1(t1 string) Option { return func(o *Options) { o.Test1 = t1 ...
发布工程
发布对于大型生产环境和复杂的业务系统来说，发布应用或者变更并不是简单的在服务器上运行二进制包或者脚本就可以了，这样很不便于服务的管理，且服务的稳定性也无法保障，所以就会有发布工程这一说法。
发布工程要素自给自足的发布对于每个研发团队来说，都需要有一个相对应的发布工程师，发布工程师指定发布策略，编写发布工具，指定发布流程。
追求速度当发布频繁时，每个版本之间的变更将减少。这样能减小新版本上线侯的测试和调试成本。对于项目可以高频次构建，然后在多次构建中选择一个构建版本进行发布（条件：需要是所有测试都通过的版本）。
密闭性每一次构建的产物，都不能因为构建环境差异导致构建差异。所有依赖在构建过程要自包含。
当构建在生产环境中出现bug时，按照之前的源码版本，加入新的改动之后生成新的构建（即向repo推送fix的commit）。构建的编译环境会被包含到repo中（显然有些不可能，所以最佳做法应该时在repo中保存编译器版本等环境信息），这样能保证每次构建环境都是相同的。
发布流程对于变更发布，一般需要遵循一下流程：
提交代码到repo，提mr，进行review
指定流程中的动作
创建新发布版
...
自动化运维
自动化运维的价值对于大型的计算集群或者线上（测试）环境，有成千上万台服务器在运行，单凭SRE进行手动变更或者运维是远不能支持平时工作的，所以这里就要讲到自动化运维的价值：
一致性大型集群在硬件层面很难做到完全统一，但是在系统层面、软件层面和服务层面是可以通过认为影响达到一致的。生产环境的一直能很大程度上标准化生产环境，以降低环境差异化带来的人力成本或者其他附加成本。比如在生产环境中，机器可以通过群组的方式进行批量管理，每个群组内的机器试用相同的环境配置，对于配置试用repo进行统一管理，由此可以把机器的管理粒度从单机提升到群组（但是同时带来一个隐患，如果对群组进行配置变更，如果配置失败影响面就会从单机上升到大批量）
硬件层面比较难做到一致化或者统一化（主要问题来源于设备供应商不同，不同设备的管理方式也不大一样），所以在设计自动化的时候尽量兼容更多的硬件平台或者指定CFI（以上两个选择一个就好，后者可能更贴合当前实际），同样在设计时也尽量使用通用管理方式，比如ipmi协议。
平台化对于变更或者运维操作具象成平台上操作的一个对象，对象可以是单机，也可以是集群，也可以是自定的群组。平台化是自 ...
密码管理中心
对于生产传环境服务器，密码一定不是固定的。对于安全起见，密码需要设计成动态的，主要防止服务器而已登录和服务器权限管理。
密码管理中心的主要功能就是对于服务器的密码进行动态修改，并对生成的密码进行存储，密码展现给指定的业务线和系统管理员。
JWT认证/Tag认证JWT认证JWT是登录鉴权认证。用户登录系统时向API发送自己的账号和密码，服务端做账号和密码校验，如果校验成功，向前端返回一个加密JWT Token，作为用户的认证标志。
12345678{ "code": 100, "tag": [ "owt.sa", "owt.mi_img" ], "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwiZXhwIjoxNjM3NDIzNjU2LCJpc3MiOiJwYXNzd29yZCJ9.2jEUJyowdtzdz13zkgS6q_iS54ES0wk37uEKj0NN3-Y ...
生产风险管理
$e^x$效应在生产环境下，所有服务的可用性都不可能是100%，大多数企业都会尽量的向100%靠近，但是在极度接近100%的过程中，成本也会成指数上涨。可以理解为可靠性每提升一个等级，就会指出更多的成本，类似于$e^x$函数。
风险管理规避风险的成本主要可以分为两部分：
计算资源成本：包括服务器成本和运维成本
机会成本：由某组织承担，构建资源分配和减少风险系统、监控。
风险度量风险度量的指标主要是服务的可用性，但是可用性通常被分为两种：
基于时间基于时间的服务可用性主要是衡量服务在整个服务时间内的可用时间，其计算公式为$\frac {T_e} {T_a}$。
基于请求基于请求的服务可用性主要是衡量正确请求在所有请求中的比例，其计算公式为$\frac {R_e} {R_a}$。
服务风险容忍可用性目标及可用性容忍可用性目标和可用性容忍通常是一个服务的最低可用性，如果低于这个可用性就可能导致用户对该服务产生负面的评价，同时也会影响服务的收入和上游甲方的评价下降。所以该部分应该更加专注于消费者。
故障类型常见的故障主要是宕机故障，但是其他种类的故障也不容忽视。比如用户信息返回错乱，A ...