metrics 上报在高并发时会带来性能问题，为了解决问题，有时反而又会带来别的问题。 举个例子，一般的 metrics 上报代码可能是下面这样： // when request in metrics.Req(caller, count, latency) 内部实现一般也就是个 UDP 调用，可能碰到的是 fd 锁的问题，在 这篇 [http://xargin.com/lock-contention-in-go/] 里已经写过了。 为了优化这个锁带来的阻塞问题，有些系统会把 metrics 上报改为非阻塞逻辑：

某系统中有类似下面这样的代码： package main import ( "sync" "time" ) type resp struct { k string v string } func main() { res := fetchData() log.Print(res) } func rpcwork() resp { // do some rpc work return resp{} } func fetchData() (map[string]

https://www.zhihu.com/question/364687707 在知乎上已经说了原因，不过只是讲官方的 spec，我们再来看看实现上具体为什么会是这样的。 package main import "fmt" func main() { a := new(struct{}) b := new(struct{}) println(a, b, a == b) c := new(struct{}) d := new(struct{

MQ 对于业务系统建模非常重要，是解决分离关注点、依赖反转、CQRS、最终一致等业务问题的重要法宝。 然而企业对于 MQ 中的数据管理却并不重视。从互联网企业发展的历程来看这个问题，最初 MQ 不是很可靠，大家不会把让特别重要的业务依赖 MQ，所以接入到 MQ 的业务事件并不多。总共也就两三个 topic，开发相应的系统对这些内容进行管理看起来没什么必要，甚至可能连详尽的业务信息都要从生产者的代码注释中去寻找。公司规模不大，这些都是可以接受的。 经历过 1Mb 小水管的朋友大概还记得当初火爆的 Flashget 的 Slogan： > 下载的最大问题是什么——速度，其次是什么—

逻辑复杂的系统中，我们经常能看到“规则引擎”和“决策树”之类的东西。 在数据准备好的前提下，规则引擎和决策树都可以理解成在大宽表上进行决策的过程，两者进行逻辑运算需要较为统一的数据格式，即需要对不同来源的数据内容进行统一抽象。 在之前的文章中，我写过 一劳永逸接入所有下游数据系统 [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，