Diary

1Password 太贵了，$2.99 和 $4.99 分别对应单人和家庭套餐！！！现在的 1password 收费模式也转向了订阅付费，同时架构也转向了 CS 架构，所以本质上和 Bitwarden 也差不多了。 Bitwarden 是一款自由且开源的密码管理服务，用户可在加密的保管库中存储敏感信息（例如网站登录凭据）。Bitwarden 平台提供有多种客户端应用程序，包括网页用户界面、桌面应用，浏览器扩展、移动应用以及命令行界面。Bitwarden 提供云端托管服务，并支持自行部署解决方案。 – 维基百科 Bitwarden 安全原则 端到端加密：所有的密码和私人数据都通过 AES-256 进行加密。所有的加密密钥均在客户端生成和管理，加密过程均在客户端完成。 零知识加密：Bitwarden 服务端不存储你的主密钥以及加密密钥，你的数据使用你的个人邮箱以及主密钥进行加密。 源代码可用：代码完全开源，并可自行编译使用。 隐私设计：所有登录信息在你的设备中进行加密后在存储到 Bitwarden服务器的保管库中，并将保管库同步到所用你的设备，你的数据采用 AES-CBC 256 位加密、加盐散列和 PBKDF2 SHA-256 进行密封。 安全审计与合规：Open source and third-party audited, Bitwarden complies with AICPA SOC2 Type 2 / Privacy Shield, GDPR, and CCPA regulations. Bitwarden 核心概念 主密钥（Master Key） 最核心的密钥，所有后续的密钥和加密密钥均通过主密钥派生，主密钥也是解密所有登录信息以及私人数据的唯一密钥，丢失会导致无法获取已经保存的数据，泄漏将导致所有的数据公之于众。所以主密钥复杂点毕竟你所有的密钥都不需要记了，主密钥在特别简单岂不是很危险？ 伪代码： masterKeyHash = pbkdf2(masterKey, email) 主密钥哈希 用来鉴权登录，身份认证，从 Bitwarden 服务端获取密码保管库。 伪代码： masterKeyHashHash = pbkdf2(masterKeyHash, masterKey) 扩展主密钥（Stretched Master Key） 通过主密钥派生出加密密钥和签名密钥，并将两个密钥拼接成扩展主密钥。...

只是写自己接手的项目迭代过程，单纯的记录。 这个项目的目的是为了控制电话营销的投诉率，前前后后搞了也有小一年了，大的迭代基本上有三次，这篇文章主要就是记录一下迭代的过程以及自己的想法。 项目伊始 需求：获取 SIP 协议中的手机号信息，去特定的网站查询该手机号在不在投诉黑名单中，并将命中的手机号缓存。 开始的需求很简单，但是本身并不是这个行业的，对 SIP 协议也不是很了解，看了看资料用了最简单的方法实现了他的需求。 实现后的流程如下： 遇到的问题： 由于对 SIP 不了解，所以代码只是单纯的对 SIP 协议做转发，导致中间层只能和前端在同一台机子上。 由于他的前端是破解版本，所以导致系统版本特别低（Centos5）都已经被弃用了，所以最开始设想的中间层运行在 docker 中也随之破灭。 以上问题间接的导致了我需要在他出问题的时候排查和我无关的错误，极大的浪费了个人时间。 第二阶段 由于运行期间间接产生的数据，如自己被投诉的号码，以及明确不愿意在接听到类似电话的人，以及低素质的人。 所以他有了自己的私有数据，但是项目的第一阶段并没有这部分的功能，于是有了第二期的需求。 需求如下： 可以上传自己的黑名单。 可以上传自己的白名单。 可以设定拦截时间（请求过的数据在规定的时间不允许第二次请求）。 第二期的需求本质就是添加自己的黑名单数据，对 SIP 这快的逻辑改动并不大，所以第二期从简实现。 实现后流程如下： 可以看出私有数据服务被单独放到了一台机子，以 RESTful API 的形式给原中间层提供数据拦截状态。 所以阶段二对中间层还是有稍微细小的改动的，但是并没有解决阶段一导致的问题。 阶段二中的片段，由于他的需求一直在增加，导致阶段二变的异常复杂，以下是架构图： 由于配置的繁琐，以及加入了一些新的脱敏数据，出现了一些新的需求，如，满足特定规则后才转发。 介于阶段一，二的复杂程度实在不想基于原先的设计思想继续追加了，所以重新设计了现有的架构。 新设计的架构解决了原先的问题。 必须部署在一台机子上。 由于不完善的 SIP 实现导致处理流程异常耗时（前端的 3 秒 Timeout，3次重试机制）。 无限的堆叠原有服务导致项目结构异常复杂，难以维护。 中间层和和前端必须部署在一起，任何问题都需要登录机器查看，排查问题麻烦（前端属于破解版，系统又是 CentOS 5）。 以下是第三阶段的架构图： 以上架构的优势： 完全基于 K8S 部署，横向扩容，高可用。 我负责的模块完全独立于他的前后端，再也不需要因为前后端的机子出现问题，导致的被迫介入。 规则可配，插件可扩展，基本满足后续的需求。 前后端可 一对多，多对多，多对一，SIP 转发层基本实现了 SIP 协议的真正转发。 第四阶段（规划） 基于 TensorFlow 替换规则的手动设置！！！！ 以上 以上算是对接手这个项目的总结，在项目期间也确实接触了好多新的知识。 如 GRPC 并不能在 K8S Service 层做到负载均衡，需要 Service Mesh 的介入（Linkerd2 等）。...

2020 年，多灾多难的一年，戴了一年的口罩，过年也没回家，相比上一年并没有获得很大的进步，相反体重继续走高涨幅 3.9% 。 工作 2020年8月加入了联通大数据，继续做着区块链方向，但是不做交付相关了，转向了 BaaS 平台，工资也小有涨幅，这里要感谢我的同事然而他并不活跃在社交网站就不 @他 了。 学习 在前半年继续较为深入的了解了 Hyperledger Fabric 共识相关的底层实现，也写下了几篇自认为有用文章。 开了个 Fabric BaaS 的坑 Alkaid，但是后面慢慢的就没时间更新了（理直气壮）。 开始了新公司的工作，完成平台的区块链 BaaS。 朋友开了新坑还是跟 VOIP 有关，做了个稍微有点大的项目，预计 TPS 在 500/s 左右，数据量大概有个几亿的数据。 建了个 K8S 集群，搞了个高可用的 Mongo Sharded Cluster 集群。 研究了 Makefile 的编写。 看了看 Plan9 的汇编。 文章 今年共水了 9 篇文章。 回顾 2019 Fabric 中 etcdraft 共识讲解 基于 Windows 的开发环境 Go 删除 Slice 中的某一个值 Hyperledger Fabric peer block 的交付流程详解 Hyperledger Fabric 加入通道时遇到 channel doesn’t exist 问题 神经网络的数据基础 Go HTTP Response 写超时导致的 EOF 错误 Plan9 汇编入门讲解 B站 还是晚上看视频，看的最多相关的视频是 彩虹六号 嗯，是个不错的游戏。...

换电脑啦！！！退役了用了 6 年的笔记本！！！由于未知错误原因导致无法安装 Manjaro Linux，所以决定尝试使用 Windows 进行开发。 由于最开始并没有考虑使用 Windows 所以显卡选择比较随意 GTX 1660 Super，导致无法玩大作，后悔啊！！！ 目前的开发工具主要是： JetBrains Goland Microsoft VSCode （主要用来编辑一些非项目的文件，如 Terminal 的配置文件等） Windows Terminal （主要用于打开 WSL2 子系统的，偶尔用来开 PowerShell） Windows Ubuntu WSL2 （用来 编译，调试 项目，启停 docker） Docker For Windows （WSL2 中操作 docker 容器 都会启动在这个里面） Chocolatey （类似 Linux 中的包管理工具，如 Ubuntu 的 apt） VirtualBox （甲骨文的虚拟机软件，如创建一个 Kubernetes 集群什么的） Vagrant （虚拟机管理工具，如用于一键启动 Kubernetes 集群） Putty （SSH 客户端） 以上就是我目前主要用到的开发工具。 Chocolatey https://chocolatey.org/ 无意中接触到的一个工具，很对胃口所以就决定尝试一下了。 安装也很简单，以管理员模式启动 PowerShell.exe，然后执行一下命令就可以了。 Set-ExecutionPolicy Bypass -Scope Process -Force; [System....

第一次写年终总结, 每次准备写脑海里都飘过 “你比上一年又重了N公斤”, 今年可以写的感觉也并不多, 但是总结一下总是好的. 体重 涨幅 0.052, 目前体重算 95KG 好了, 另外明年的目标一定要下降到 70 左右!!! 加薪 涨幅 0.428, 虽然加薪来的迟了, 但是总比没有要好. 学习 虽然 Hyperledger Fabric 国密支持并不是我实现, 但是我也充分参与到了其中, 算是对 TLS, 加密, 签名, 证书 有了较为深入的研究. 完成了对 Hyperledger Fabric statedb 的扩展, 支持了 TiDB. 部署实施了两个 Hyperledger Fabric 的落地项目. 对 Hyperledger Fabric 以及 Hyperledger Fabric Go SDK 有了较为深入的了解. 给 Hyperledger Fabric Go SDK 贡献了2次源码, 支持了 Java Chaincode 的 安装, 实例化, 升级. 编写了 hlf-deploy 项目, 支持了几乎所有的 Hyperledger Fabric 所有的操作, 例如: 动态更新通道, 动态切换共识算法 等....

二话不说先上一张退回后所有的配件…, 没错就是这么点东西!!!, 所以只要给 Google 寄回坏手机就好了. 废话不多说开始讲讲大概的流程, 咨询方法有两种, 打电话和在线聊天, 如果英文够好, 估计也不会来这里了, emmm… 联系 Google https://support.google.com/pixelphone, 找到 CONTACT US -> Pixel Device Support -> 对应的手机型号 进行聊天. 需要注意以下的几点: 将网站设置成英文, 不然无法看到 CONTACT US. 准备好 双,全币 信用卡 因为要交押金的. 大概是 $869刀, 21天 必须把手机寄到美国,不然会扣钱 准备一个收货地址必须是美国的, 找朋友或者转运公司都行. Google在线聊天工作的时间是 6:00 AM to 9:00 PM PST, 美国的时区是 UTC-8 中国的时区是 UTC+8, 所以中国 10:00 PM 的时候他们刚刚上班… 如果他们给的方法 (基本联系他们的时候就全部做过了) 全部试过还是无法开机的话. 他们会给你说给你寄送一部翻新机, 在 21天 内将坏手机寄回他们给的地址, 这些东西都会在聊天完毕后给你发一封详细电子邮件. 最好在他们发货的时候就将自己的坏手机准备寄送出去, 因为手机到美国有差不多10多天的才能到.