原文，向原作者表示感谢。这里省略了一些无关的介绍说明以及过于简单的说明，直接看代码就懂了。
在大多数语言中你可以随便放置花括号的位置，但go语言不一样，你可以理解为为go会自动注入分号（automatic semicolon injection）：
错误代码：
package main
import "fmt"
func main()
{ //error, can't have the opening brace on a separate line
fmt.Println("hello there!")
}
编译错误：
/tmp/sandbox826898458/main.go:6: syntax error: unexpected semicolon or newline before {
正确代码：
package main
import "fmt"
func main() {
fmt.Println("works!")
}
原文，省略了一些无关的内容。
如果你搜到这篇文章，那么什么是gin以及casbin应该不用过多解释了。
很久之前发现一个现象，在生产环境中配置了保留内存reserved_host_memory_mb以及 没配置 内存超分比ram_allocation_ratio的情况下，虚拟机使用的内存居然已经快将物理内存耗尽了。
比如物理机内存300G，方便举例忽略掉一些系统占用，当设置了reserved_host_memory_mb为20G，那么理论上所有虚拟机最大占用内存量为280G，而查看居然已经使用了290G的内存，还是在虚拟机并没有将各自申请的内存全部使用掉的情况下(比如申请一台4G的虚拟机，但物理机操作系统层面并没有分配4G给对应的进程，除非虚拟机内部把内存占满)。
单单就nova而言，如果在集群启动时就指定了保留内存大小和超分比为1的话，是不应该出现上述情形的。除非后期对这2个参数进行过修改，但由于年代久远已经没法追溯，这也就成了一桩悬案。
不过在追踪这个问题的过程中，顺便也学习了下主机热迁移的过程，这里的代码是 N版 。
用共享的方式提供大量细粒度的对象，降低系统创建类实例的性能消耗，不是特别常用的一种模式。
今天遇到一个诡异的问题，对某个有问题的计算节点进行疏散，结果有些虚拟机的根磁盘居然消！失！了？首先能够确定的是ceph不会自动删除，那么一定是某个地方触发了删除根磁盘的操作。
这如果发生在生产环境可是一个极其严重的问题，正好借此排查的机会梳理一下nova关于主机疏散的流程。
以下代码为N版，但大体流程相差应该不大。
这个模式即便没听说过，也很可能在很多地方已经使用了，是非常常用的设计模式之一，完美体现了面向对象“封装”的特性。简单说就是通过一个“外观”将系统内部的实现隐藏起来，将外部系统和内部系统进行解耦。