K8s浅学
k8s1、安装（v.1.17.1,docker-cri）1.1 env.bash123456789101112131415161718192021222324252627282930313233343536373839404142434445#!/bin/bash# 在 master 节点和 worker 节点都要执行# 卸载旧版本yum remove docker \ docker-client \ docker-client-latest \ docker-common \ docker-latest \ docker-latest-logrotate \ docker-logrotate \ docker-engine# 安装并启动 docker(cri)yum install -y docker-ce-19.03.5 docker-ce-cli-19.03.5 containerd.iosystemctl enable dockersystemctl start docker# 关闭 防火墙systemctl stop firew...
常见的分布式服务发现和服务注册方案
常见的分布式服务发现和服务注册方案 Feature Consul Zookeeper Etcd Eureka 服务健康检查 服务状态，内存，硬盘等 (弱)长连接，keepalive 连接心跳 可配支持 多数据中心 支持 — — — kv存储服务 支持 支持 支持 — 一致性 raft paxos raft — CAP定理 CA CP CP AP 使用接口(多语言能力) 支持http和dns 客户端 http/grpc http（sidecar） watch支持 全量/支持long polling 支持 支持 long polling 支持 long polling/大部分增量 自身监控 metrics — metrics metrics 安全 acl /https acl https支持（弱） — Spring Cloud集成 已支持 已支持 已支持 已支持 consulConsul有多个组件，但总体而言，它是基础架构中的一款服务发现和配置的工具。 它提供了几个关键功能： 服务发现：Con...
常见的分布式锁解决方案
常见的分布式锁解决方案 基于MySQL的悲观锁、乐观锁 基于redis的分布式锁 基于zookeeper的分布式锁 基于MySQL的悲观锁、乐观锁悲观锁悲观锁是基于一种悲观的态度类来防止一切数据冲突，它是以一种预防的姿态在修改数据之前把数据锁住，然后再对数据进行读写，在它释放锁之前任何人都不能对其数据进行操作，直到前面一个人把锁释放后下一个人数据加锁才可对数据进行加锁，然后才可以对数据进行操作，一般数据库本身锁的机制都是基于悲观锁的机制实现的 MySQL for update的加锁： 12345678910111213# 向mysql申请一把锁 for update， 使用for update 的时候注意，默认每个语句mysql都是默认提交# 需要关闭@@autocommitselect @@autocommit;set autocommit=0;select @@autocommit;select * from inventory where goods=420 for update;# 具体业务# 释放锁commit;#这是一个行锁#明确查询条件，就锁住指定数据 &...
面试八股文-计算机网络篇
面试八股文-计算机网络篇OSI七层模型和TCP/IP四层协议概述OSI七层模型协议 帧结构 各层级之间的作用网络层： 关键协议：IP协议、ICMP协议 主机之间的通信，目的是向上提供简单灵活、无连接的、最大努力的交付的数据报服务，网络层不提供服务质量的承诺 不需要建立连接 每个数据报单独路由 每个数据报有完整的目标地址 不提供可靠的连接 到达终点可能无序 每终点进行差错控制 传输层： 关键协议：TCP协议、UDP协议 主机间进程之间的通信，向应用层提供通信服务，屏蔽下面的核心网的网络细节，使得面向传输层编程就像二个主机之间有一条端到端的逻辑通信信道一样 传输层使用TCP协议的时候，这个逻辑通信信道是可靠的，尽管下面的网络是不可靠的 应用层： 关键协议：HTTP协议、FTP协议、SMTP协议、DNS 定义了运行不同端系统上的应用程序如何互相传递报文 提供了不同应用之间的通信 TCP/IP四层协议 HTTP版本的演进graph LR A(HTTP0.9/1991) B(HTTP1.0/1996) C(HTTP1.1/1997) ...
Go-内存对齐
内存对齐什么是内存对齐 CPU 访问内存时，并不是逐个字节访问，而是以字长（word size）为单位访问，通过内存对齐，减少CPU访问次数,加大CPU访问内存的吞吐量 内存对齐:两个结构体包含的字段类型一致，但是顺序不一致，最终输出的大小也不一样 内存对齐规则成员对齐规则 针对一个基础类型变量，如果 unsafe.AlignOf() 返回的值是 m，那么该变量的地址需要 被m整除 （如果当前地址不能整除，填充空白字节，直至可以整除 整体对齐规则 针对一个结构体，如果 unsafe.AlignOf() 返回值是 m，需要保证该结构体整体内存占用是 m的整数倍，如果当前不是整数倍，需要在后面填充空白字节。 通过内存对齐后，就可以在保证在访问一个变量地址时： 如果该变量占用内存小于字长：保证一次访问就能得到数据； 如果该变量占用内存大于字长：保证第一次内存访问的首地址，是该变量的首地址 空结构体的对齐规则 如果空结构体作为结构体的内置字段：当变量位于结构体的前面和中间时，不会占用内存；当该变量位于结构体的末尾位置时，需要进行内存对齐，内存占用大小和前一个变量的大小保持一...
Go-日志库Zap
Go-日志库Zap什么是zap 快，非常快，这也是 zap 最显著的特点。速度快的原因是 zap 避免使用 interface{} 和反射，并且使用 sync.Pool 减少堆内存分配。在 zap 面前 Logrus 的执行速度只有被吊打的份，你可以在官方 GitHub 仓库中看到 zap 与不同日志库的速度对比。 支持结构化日志记录。这是一个优秀的日志库必备功能。 支持七种日志级别：Debug、Info、Warn、Error、DPanic、Panic、Fatal，其中 DPanic 是指在开发环境下（development）记录日志后会进行 panic。 支持输出调用堆栈。 支持 Hooks 机制。 安装1go get -u go.uber.org/zap 基础使用// suger 模式会稍微比logger 原生慢一点 1234567891011121314151617 logger, _ := zap.NewDevelopment() //logger, _ := zap.NewDevelopment() defer logger....
Git 规范
Git 规范为什么需要git规范遵循 Git Commit 规范可以提高团队协作效率和代码库的可维护性。 通过明确的 Commit 类型和格式，开发者能够更轻松地理解每个提交所带来的更改，并能够快速回溯和回滚代码。 建议团队在项目中制定统一的 Git Commit 规范，并通过培训和代码审查来确保规范的遵循 git规范 约定式(): git commit 合并 type subject feat 新功能（feature） fix 修补bug docs 文档（documentation） style 格式（不影响代码运行的变动） refactor 重构（即不是新增功能，也不是修改bug的代码变动） chore 构建过程或辅助工具的变动 revert 撤销，版本回退 perf 性能优化 test 测试 improvement 改进 build 打包 ci 持续集成
优雅退出注销服务
优雅退出注销服务为什么需要优雅注销服务当往服务中心注册了服务之后，由于调试，可能会重复注册同一个服务。当时之前服务由于健康检查，并不会立即退出注销，这就会多线多个“重复的服务” 整合优雅退出服务12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970package consulimport ( "fmt" "github.com/hashicorp/consul/api")// register.go 工具type Registry struct { Host string Port int}type RegistryClient interface { Register(address string, port int, name string, tags []string, id string) erro...
微服务之配置中心
微服务之配置中心为什么需要配置中心 添加配置项不方便，大量部署实例需要修改配置麻烦 go使用viper能自动生效，不保证其他服务 开发、测试、生产的环境隔离 配置中心技术选型目前主流有spring cloud config、apollo和nacos apollo是协程开源，nacos是阿里开源 Apollo大而全，功能完善。nacos小而全 部署nacos简单 nacos不仅仅支持配置中心和支持服务注册和发现 都支持各种语言，不过apollo是第三方支持，nacos 是官方支持 功能点 apollo nacos 开源时间 2016.5 2018.6 配置实时推送 支持（http长轮询） 支持（http长轮询） 配置回滚 支持 支持 灰度发布 支持 待支持 权限管理 支持 支持 多集群 支持 支持 监听查询 支持 支持 多语言 主流语言 主流语言（官方支持） 通信协议 http http nacos安装12# docker模式 docker run --name nacos-standlone -e MODE=standalo...
微服务之配置中心
负载均衡什么是负载均衡负载均衡是将网络流量分发到多个后台服务的一种机制。通过负载均衡的流量分发，降低了单台服务器的负载，减少了应用的响应时间 负载均衡类型集中式Load balance集中式LB方案，如下图。首先，服务的消费方和提供方不直接耦合，而是在服务消费者和服务提供者之间有一个独立的LB（LB通常是专门的硬件设备如F5，或者基于软件如LVS，HAproxy等实现）。 进程内load balance 可看到引入了第三方：服务注册中心。它做两件事： 维护服务提供方的节点列表，并检测这些节点的健康度。检测的方式是：每个节点部署成功，都通知服务注册中心；然后一直和注册中心保持心跳。 允许服务调用方注册感兴趣的事件，把服务提供方的变化情况推送到服务调用方。 这种方案下，整个load balance的过程是这样的： 服务注册中心维护所有节点的情况。 任何一个节点想要订阅其他服务提供方的节点列表，向服务注册中心注册。 服务注册中心将服务提供方的列表（以长连接的方式）推送到消费方。 消费方接收到消息后，在本地维护一份这个列表，并自己做load balance。 可见...
