在这里，加锁可以解决时序问题，原子性倒是不用担心，golang 的指针操作都是原子的。
之前专门写过文章来聊 golang 里面锁到底是什么：
https://wweir.cc/post/%E6%8E%A2%E7%B4%A2-golang-%E4%B8%80%E8%87%B4%E6%80%A7%E5%8E%9F%E8%AF%AD/

代表个人，向阿拉善捐助树苗一颗

@sujin190 亲，这边建议您了解一下二（三）步提交、raft log 是什么呢

讲个笑话，paxos、raft 没解决同步的问题 😹

@goofool 试了 pcap 方案，感觉太重了，我的需求犯不着用重武器，而且测试代码在 Windows 上有问题 。

目前采取最暴力的做法，自己封装了个跨平台的 DHCP client 的简陋实现，在我的场景下轻量、好用。
https://github.com/wweir/sower/blob/4f8376c0414a6f84d23e9092701e405e46af32a0/dns/dhcp.go#L25

@zhu git commit -am m 😹

上 sower，智能全局代理，自动检测被屏蔽的站点，专业解决规则的烦恼
github.com/wweir/sower

@passerbytiny 是离谱的，对 go 而言，10 万行就已经是巨型的项目了，为了避免到处是杠精，才说的 20w 行。
就我自身而言，3、4 万行的代码还能 hold 住，再多的话，没优秀的封装、模块化，根本进行不下去。

@thuai dragonboat：62979 行，同样去除非代码部分和测试代码。

PS: 之前看过几篇 paxos、raft 相关的论文，一直想看一看 dragonboat 源码的。

@azh7138m @blless
golang 在 1.11 之后，包管理这一块依然很欠缺。而且，欠缺的不是工具，而是生态，以下这几个问题是日常踩坑：
1. 没有中心化的包下载仓库，网络、删除方面容易出问题
2. 没有中心化管理，导致大量仓库质量鱼龙混杂
3. 前些年没强调版本管理，导致大量包压根没有版本
4. 部分流行的包版本管理不规范，如：开个 v0.0.1 的版本，之后一两年年不发新版本

关于这些东西，之前专门写了个文章来进行分析：
https://wweir.cc/post/golang-%E9%A1%B9%E7%9B%AE%E7%BB%84%E7%BB%87%E5%BD%A2%E5%BC%8F%E7%9A%84%E6%BC%94%E8%BF%9B/

@abcbuzhiming 单冲这段介绍，必须 follow 一下。
半年前专门思考了 golang 的封装、描述世界的方式两三个月。
当时的结论是 golang 的 interface 方式描述世界的能力远继承的方式，唯一的缺点是业界对其使用方式的思考还比较欠缺。很多时候还是从继承的角度来进行封装，距离最佳实践的距离还很远。
所以看起来像是 golang 描述世界的能力很欠缺，实现不了大型应用。估计再过几年、十几年，大家（真正写业务的普通程序员）的认知够了，周边工具也完善了，也就能拿 golang 写大型单体服务了

@azh7138m 423884
kubernetes 这个 repo 已经远远超出单体应用的范畴了，里面杂糅了 kubelet、kubectl 等一系列单体软件，讨论这个项目的意义不大。

@wweir 统计了一下 engine repo，去除 vendor 目录，去除测试代码，总共 138147 行。这还是吧 daemon、client 等多个子项目合并在一起的项目。
使用命令：
find . -name '*.go' | grep -v '_test.go' | xargs wc -l

@azh7138m 未必哦，把杂七杂八的非代码部分都扣除，再看看有单项目超过二十万行的吗？

@wweir 重型应用 => 中型应用

之前专门探讨过这个问题，我的理解是：go 不需要设计模式，不是没有，而是根本不需要！

想想为什么要设计模式？相信写个普通的 hello world 的话，没人会去套设计模式。在开发大型应用时，设计模式才能体现出它真正的价值。
那么，go 真的需要写成大型应用吗？目前大多数场景的做法是直接做服务拆分，各服务间通过网络来通信。

golang 目前重型应用有一些，大型应用还真不好找。除去第三方包，如果有二十万行以上代码的 golang 项目，欢迎分享一下。

一直用 3.5，有线能提供超过蓝牙的带宽，声音还原度更高