逻辑复杂的系统中，我们经常能看到“规则引擎”和“决策树”之类的东西。
在数据准备好的前提下，规则引擎和决策树都可以理解成在大宽表上进行决策的过程，两者进行逻辑运算需要较为统一的数据格式，即需要对不同来源的数据内容进行统一抽象。
在之前的文章中，我写过 一劳永逸接入所有下游数据系统
[http://xargin.com/integrate-downstream-data-system-all-in-one/]
，讲的便是复杂系统中对准备数据过程的一种抽象。这种抽象在方法论大湿们发明的概念中早有总结：Anti Corruption Layer
[https://docs.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer]
。你可以把它叫做 adapter，
依赖反转即 OOP 中的 SOLID 原则中的 D(Dependency Inversion Principle
[https://en.wikipedia.org/wiki/Dependency_inversion_principle])，最早么，是 Uncle Bob
提出的：
> The dependency inversion principle was postulated by Robert C. Martin and
同事给了一个挺有意思的程序：
package main
import (
"fmt"
"os"
"runtime/trace"
"sync"
"time"
)
var mlock sync.RWMutex
var wg sync.WaitGroup
func main() {
trace.Start(os.Stderr)
defer trace.Stop()
wg.Add(100)
for i := 0;
几个月前网友建议我切换到 https，当时比较懒，假期给各种烂尾楼扫尾想起来这件事情，看了看 caddy，确实非常简单。
caddy 的宣传口号是 “Caddy is the HTTP/2 web server with automatic HTTPS.”，会使用 Let's
Encrypt 的服务自动帮你把 https 相关的证书流程自动搞定。颇有各种“一键干坏事脚本”风范。
个人用户用起来确实方便不少。
ghost blog 切换
ghost
某团圆节日公司服务到达历史峰值 10w+ QPS，而之前没有预料到营销系统又在峰值期间搞事情，雪上加霜，流量增长到 11w+ QPS，本组服务差点被打挂(汗
所幸命大虽然 CPU idle 一度跌至 30 以下，最终还是幸存下来，没有背上过节大锅。与我们的服务代码写的好不无关系(拍飞
事后回顾现场，发现服务恢复之后整体的 CPU idle
和正常情况下比多消耗了几个百分点，感觉十分惊诧。恰好又祸不单行，工作日午后碰到下游系统抖动，虽然短时间恢复，我们的系统相比恢复前还是多消耗了两个百分点。如下图：
确实不太符合直觉，cpu
