你的负载均衡真的均衡么？
公司内部有一个流传很广的负载均衡算法，大概的流程如下：
数组元素对应的是 ip+port 列表，形如下面这样：
100.69.62.1:3232
100.69.62.32:3232
100.69.62.42:3232
100.69.62.81:3232
100.69.62.11:3232
100.
开源书
最近在和 chai 大一起写开源书 advanced go programming book。实际上这个项目 16
年就开始了(汗。。最开始放在闭源仓库里，热情高涨的时候写两句。不过 private 的东西，总感觉像 dev/null
一样，和在只有自己能看到的小本本上写日记差不多，写久了以后会感觉有点没劲。
写书是一个很好的过程，系统化地总结学习过的知识，锻炼毅力和语言表达能力。不管哪种职业，语言表达能力和梳理能力都是必备的。顺便还能达到某些不可告人的目的(233。
具体可以参见这里：
> https://github.com/
clean architecture(下)
接上篇
模块
最早的时候，程序员们为了重用代码，会直接把代码 #include 到自己的项目中来，然后把库代码和应用代码一起编译出一个可执行应用。这个时间点，library
是通过源代码分发的。但是那个时候外部存储设备非常慢，而内存则非常贵并且容量很有限。没有办法把所有代码都放在内存中进行编译，这样编译器就需要多次从外部存储设备中读取源代码，然后多次访问巨慢的外部存储。可以预见，库的代码越多，可能会导致程序的编译过程就越慢，为了缩短编译时间，程序员们想出了可以把库和
application 分开编译的法子：
只要把 library 加载到固定的内存位置，例如 2000，那么我们就可以直接使用编译好的 library 了。
不过这种做法很快遇到了问题，程序自己要使用的内存很快就超过了
clean architecture(上)
这半年来和同事陆陆续续有一些关于业务的代码、框架方面的争论，期间阅读过一篇陶师傅给的，推销 DCI
模式的文章/论文，认真地做了笔记。年底了，又有美团的人跳出来说互联网的业务也越来越复杂了，传统的糙快猛已经满足不了当下的需求，我们必须要认真考虑设计，而不是在学到了样子没学到根本的敏捷开发思想之上堆屎。看起来现在有不少人把矛头指向了曾经奉为圭臬的
OO 和 web 开发中最常见的 MVCL(S) 分层以及国人学了半瓶水的敏捷开发，并且各自提出了一些所谓的解决方案，比如 DCI 号称解决了 OO
驱动的开发模式下代码难以和需求所对应，而 DDD 也解决了项目上了规模以后，代码和业务描述脱节难以理解的问题。(这么看来两者解决的都是一样的问题。
虽然通过阅读，
recover 并不是无懈可击的
曾经天真地认为只要严格遵守有 go 必有 recover 就能保证程序永不宕机。直到有人对开源库有了类似下面这样的误用：
package main
func main() {
var a = map[int]int{}
defer func() {
if err := recover(); err != nil {
println("oh no")
}
}()
go func() {
defer func() {
if err := recover(); err
