Gkirito

前言

此技术发现源于一次对Coming后端的Redis报错优化，在用户量激增的情况下Coming的后端遭受巨大的请求压力， 当然相应的对后端服务进行了扩容，在这基础上，我们仍在redis cluster集群中发现了许多的Command timed out after 3 second(s)......，但是Redis的集群监控显示各个分片下的每个node节点CPU和RAM压力都并不大，却一直有出现这个错误，一开始以为是连接池等问题，但是在扩大链接池的情况下仍旧有这个错误，且极易出现在Coming重新部署时，所以逐步判断问题应该不是出在连接池和redis本身的处理能力上(意味着盲目扩充redis cluster集群的容器也是无济于事)

链网几大业务场景分析及解决方案

主要访问有严重问题

1. polkaworld

Istio搭建记录📝

先前准备

1. 部署好一个Kubernetes(1.17, 1.18, 1.19, 1.20)
2. 需要有个cluster

本地搭建

Minikube

要求：

Kubernetes搭建记录📝

工具🔧准备

安装kubectl

Kubernetes 命令行工具，kubectl，使得你可以对 Kubernetes 集群运行命令。 你可以使用 kubectl 来部署应用、监测和管理集群资源以及查看日志。

微服务架构分析

公司业务分析

目前涵盖业务

从Tower上看，目前公司业务范围有这些：

平时ssh过程中针对每台机子都有不同的密码（为了安全性🔒，大多数为随机密码），这样导致了密码繁多，而且难记，保存于🗒️上容易泄露，可以采用SSH 公钥进行认证，这样只需要一个密码