人必有所执，方能有所成

0%

发表于 更新于 分类于 阅读次数：
本文字数： 9.7k 阅读时长 ≈ 16 分钟

kubeadm介绍

Kubeadm is a tool built to provide kubeadm init and kubeadm join as best-practice “fast paths” for creating Kubernetes clusters.

  • kubeadm init 创建一个 Master节点
  • kubeadm join 将一个 Node 节点加入到当前集群中
阅读全文 »

发表于 更新于 分类于 阅读次数：
本文字数： 404 阅读时长 ≈ 1 分钟

每年给自己列个计划，要读哪些书，到年尾看看真正看完的有多少。

2020年待读清单列表

  1. 《Designing Data-Intensive Applications》

2019年待读清单列表

  1. UNIX环境高级编程（第3版）
  2. 重构网络 SDN架构与实现
  3. 软件定义网络
  4. 全球通史 从史前史到21实际 第7版修订版 上
  5. 全球通史 从史前史到21实际 第7版修订版 下
    阅读全文 »

发表于 更新于 分类于 阅读次数：
本文字数： 13k 阅读时长 ≈ 21 分钟

介绍

gdb是强大的调试工具。但对于golang程序来说，delve是个更好的选择，它能更好地理解Go runtime, data structures, and expressions，尤其是goroutine。

以下描述引用自Debugging Go Code with GDB【1】

Note that Delve is a better alternative to GDB when debugging Go programs built with the standard toolchain. It understands the Go runtime, data structures, and expressions better than GDB. Delve currently supports Linux, OSX, and Windows on amd64. For the most up-to-date list of supported platforms, please see the Delve documentation.

阅读全文 »

发表于 更新于 分类于 阅读次数：
本文字数： 4.5k 阅读时长 ≈ 8 分钟

Visual Studio Code介绍

Visual Studio Code是很轻量但功能强大的代码编辑器，可以在Windows、macOS和 Linux上运行。

阅读全文 »

发表于 更新于 分类于 阅读次数：
本文字数： 1.5k 阅读时长 ≈ 3 分钟

goroutine调度器简介

G-P-M模型，下面这张图很直观。

阅读全文 »

发表于 更新于 分类于 阅读次数：
本文字数： 9.1k 阅读时长 ≈ 15 分钟

今天发现查询mongo时容易慢查询，现在将整个排查及优化过程,总结记录如下。

Database Profiler介绍

类似于mysql,Profiler可以实现慢查询日志的功能，它把数据收集在system.profile集合里。该集合是一个capped collection（有上限的集合）。Profiler默认是关闭的，可以在一个database或者一个instance上设置开启，设置不同的profiling levels.
具体描述见Database Profiler。

阅读全文 »

发表于 更新于 分类于 阅读次数：
本文字数： 3.5k 阅读时长 ≈ 6 分钟

1 node进程负载高的问题

  • 线上有个用node开发的uhost-manager的服务。每个set内会有多台物理机，每台物理机（宿主机）上存在着1台或者多台虚拟机。uhost-manager里有个定时逻辑：每隔30s,从MongoDB里拉取所有的虚拟机的记录，数量为2000多台；将位于同一台宿主机上的虚拟机资源，包括cpu、内存、磁盘容量等，做个sum，将sum再填入对应宿主机（共200多台）的记录里，表示已经被占用的资源。
  • 由于计算量大，和代码写得差，导致在该定时的计算任务执行时，会把占用的cpu单核打满；如果uhost-manager此时又有其他接口被调用时，就会出现响应慢的问题，导致调用方的服务也响应慢，甚至会因超时导致服务接口不可用。

这个单核打满持续的时间短，在1s左右。

阅读全文 »

发表于 更新于 阅读次数：
本文字数： 14k 阅读时长 ≈ 23 分钟

ZooKeeper Sessions

![image](关于客户端重连ZooKeeper的的那些事儿/ZooKeeper Sessions.jpg)

  • ZooKeeper客户端初始化后转换到CONNECTING状态，与ZooKeeper服务器（或者ZooKeeper集群中的一台服务器）建立连接后，进入CONNECTED状态
  • 当客户端与ZooKeeper服务器断开连接或者无法收到服务器响应时，就会转回到CONNECTING状态，此时会一直收到CONNECTION_LOSS。
  • 这时ZooKeeper客户端会自动地从列表中逐个选取新的地址进行重连，如果成功，状态又会转回CONNECTED状态
  • 如果一直无法重连，超过会话超时时间(sessionTimeout)后，服务器认为这个session已经结束了，此时客户端无法感知
  • 最后当客户端终于自动重连到ZooKeeper服务器时，会收到Session Expired；这种情况下，需要应用层关闭当前会话，然后重连。
  • 在CONNECTING状态和CONNECTED状态，客户端都可以显示地关闭，进入CLOSED状态
阅读全文 »

发表于 更新于 分类于 阅读次数：
本文字数： 461 阅读时长 ≈ 1 分钟

摘自 分布式系统架构的冰与火 左耳听风

分布式系统架构的优缺点

需要分布式系统架构，来代替传统的单体架构的原因：

  1. 增大系统容量 –> 提高性能
    单台机器的性能无法满足要求时，需要垂直或者水平拆分成分布式系统架构，让更多的机器去承担。
  2. 加强系统可用 –> 提高服务可用性
    避免单点故障。

分布式系统是一种trade-off

分布式系统的发展

SOA——基于服务的架构

  1. 20 世纪 90 年代前，是单体架构，软件模块高度耦合。
  2. 2000 年左右出现了比较松耦合的 SOA 架构，这个架构需要一个标准的协议或是中间件来联动其它相关联的服务.
  3. 而 2010 年后，出现了微服务架构，这个架构更为松耦合。每一个微服务都能独立完整地运行（所谓的自包含），后端单体的数据库也被微服务这样的架构分散到不同的服务中。而它和传统 SOA 的差别在于，服务间的整合需要一个服务编排或是服务整合的引擎。就好像交响乐中需要有一个指挥来把所有乐器编排和组织在一起。

一般来说，这个编排和组织引擎可以是工作流引擎，也可以是网关。当然，还需要辅助于像容器化调度这样的技术方式，如 Kubernetes.