最近准备上马Kubernetes的项目，之前已经把传统单机部署的Java应用程序，改为微服务Microservice架构。
相同的微服务跑在多个不同的容器内，需要为每条业务数据(transaction)分配唯一的ID，并且需要保证在各自容器跑的微服务生成的ID不会出现重复。
当时调研了多种UUID生成工具和算法，最终看上了浓眉大眼的推特Snowflake雪花ID生成算法。

Snowflake是由twitter开源的分布式ID生成算法。(当然Twitter现在已经被特斯拉老板马斯克买下来，并且改名为X了。)

这里没有直接使用snowflake算法，而是进行了改造。WorkerID由Zookeeper分配，利用了Zookeeper的持久顺序节点（PERSISTENT_SEQUENTIAL），因为在K8s环境里，Pod自动分配，可能有成百上千个，一个个去给它分配WorkerID显然不大可能。
还有就是从原先算法里的序列号位数里拿出4位来解决时钟回拨问题。

改造后的SnowflakeID的组成

SnowflakeID是一个64位的Long类型数字，对于bit的分配如下:

1
2
3
4
5

+----------------------------------------------------------------------------------------------+
|    标识位    |     41位时间戳     |    10位机器号     |    4位时钟回拨掩码   |     8位序列号      |
+----------------------------------------------------------------------------------------------+
| 1 Bit Unused | 41 Bit Timestamp | 10 Bit Worker ID | 4 Bit Sequence Mask | 8 Bit Sequence ID |
+----------------------------------------------------------------------------------------------+

1 + 41 + 10 + 4 + 8 = 64 bit

在使用Helm Charts部署应用到Kubernetes Cluster集群中时，可能需要等待一些依赖项先行启动起来，后续应用部署才不至于启动出错。

比如在安装时在加载其他chart之前加载配置映射或密钥。

比如部署的微服务应用需要等待数据库初始化操作成功，才可以启动时。如果这时候应用在数据库初始化还未成功完成时之前便开始执行启动操作时，大概率是会有问题发生的。

为了解决这个问题，我们需要使用到helm charts hooks钩子的权重特性来调整安排资源创建的先后启动顺序：

假设微服务 Microservice A的启动 依赖于应用B， 需要等待B先启动起来，才可以启动A。

1. open the inventory file with your favorite editor and modify it

1

sudo vi /etc/ansible/hosts

add servers likes below:

1
2
3

[servers]
server1 ansible_host=192.168.1.100 ansible_ssh_user=test_user ansible_ssh_pass=password ansible_ssh_extra_args='-o StrictHostKeyChecking=no'
server2 ansible_host=192.168.1.101 ansible_ssh_user=test_user ansible_ssh_pass=password ansible_ssh_extra_args='-o StrictHostKeyChecking=no'

2. verify the inventory

1.add Ansible repository to your system 添加Ansible仓库到系统

1

$ sudo apt-add-repository ppa:ansible/ansible

Then, press [ENTER] to proceed, output likes below screenshoot shows:

2.Run the update command before installing to update existing packages

1

$ sudo apt-get update

在日常使用git版本控制器的过程中，难免会出现不小心push推送提交到远程服务器仓库中，这时就需要后悔药来回退到上一次提交的版本或者指定的版本。
本文使用Git的GUI界面管理工具 TortoiseGit 为例，并在步骤6提供git命令行回退历史版本参考示例，

1.打开git日志 show log

在项目文件夹里，右键菜单 选择”TortoiseGit” -> “Show log”

2. 重置 reset

选择要回退（回滚）的历史提交记录，并在那条日志记录上右键，选择 Reset "$实际分支名称 actual git branch name$" to this...

3. 参数 Rest type 选择 Hard

在弹出的对话框内， 在 Rest type 区域选项内选择第三个参数

在日常使用git版本控制器的过程中，经常会遇到一些错误，特别是在直接使用git命令行操作，而不是使用Git图形界面（比如TortoiseGit或IDE自带的Git版本控制插件）时。
例如在执行 git 命令 git pull 或者 git push 操作的时候遇到了以下错误：

1
2
3
4
5

root@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

错误原因分析

从输出的output错误信息，该操作使用了root用户名去ssh登录github.com, 并提供了错误的验证登录所需要的证书。而正常应该是使用git这个用户名去登录操作。所以引起错误的原因应该是Git的配置信息缺少了git用户名。所以默认使用root这个用户名去尝试操作，才会保Permission denied的错误。那么接下来就可以按下面几种方法来解决这个 root@github.com Permission denied (publickey) 问题。

解决方法:

This article was created by github editor, and automatically deployed by GitHub Action.

测试完毕