@xywanghb #72

我也是到了 70 楼的回复才意识到关键所在，你说的就是我想表达的。

Java 的接口和 Go 的接口只是有一样的名字，实际上作用完全不一样，根本不能拿来类比的。Java 的接口是用来解决多重继承问题的，而 Go 天然基于组合而非继承，接口的能力和责任范围都更大。

Java 的思维模型里，抽象（动词）设计这个行为越早越好，而且机制上鼓励你尽可能考虑易用性和扩展性，原因是后期做调整很麻烦。这让我想起了上学的时候，万物皆对象，想把整个宇宙都用对象和类描述出来。这个思路导致了 Java 在工程方面是有过度设计和复杂化倾向的，现实里 java 团队往往也比较大。

Go 的思维模型里，越简单越好，不需要考虑额外的东西。责任划分非常清晰，抽象这个行为局限在非常小的业务层面。

这中间的区别我认为可以上升到哲学层面，就是我开头提到的汉语和其他语言的区别。汉语是建立在组合的哲学上的，把全宇宙所有具象、抽象的概念都解构归纳成最基础的元素，大概只有几千个汉字。任何人学会这几千个字，就可以尝试自行描述整个世界。

换到其他语言，简单举例几个，化学、医学和植物学，每个都有自己无限衍生的词汇表，在一个领域的词汇积累是无法平移到另一个领域的（多继承失败）。

从这个意义上说，我认为以 Go/Rust 等等现代语言就是先进生产力的代表，减轻了开发者的心智负担，也就解放了生产力。

@aababc #64

没办法确定“实现”了接口。

在 Java 这种 strongly typed 语言中，这个判定过程发生在编译时，implements 就是告诉编译器做这个验证工作的。在 Go 这种 weakly typed 语言中，这个判定被推迟到运行时，如果没能真正实现，调用的那一刻会产生运行时错误。

于是 Java 的思维模型就是要先说清楚，即库和包的作者主动声明并接口化。而 Go 的思维模型是用到的时候再说，即调用方来定义到底需要什么接口（我定义的我自己当然知道谁实现了谁没实现）。

我前面举的例子可能不是特别恰当，但是由于 Go 的接口声明在调用方，而实现在上游的包和库，这个隔离或者独立已经是非常大的进步了。从各种开源项目看，引用上游依赖几乎是毫无副作用的事情。

@sagaxu #66

我在这个帖子反复讨论中突然意识到一个问题，就是 Go 的接口其实并不是等价于 Java 中的接口的。在 Go 实现泛型之前，Go 的接口承担了很大的抽象作用，而这个问题在 Java 中并不存在。

我在构思文章的时候一直很纠结，总感觉说不到重点上。现在看我更应该回答的问题是，Go 这样的设计到底带来了哪些实质的好处，而不是执着于辩论这个设计是否先进。

@leonshaw #62

经过这么一整个帖子的讨论，我越来越意识到之前的举例不恰当。

不论是 Go 还是 Java 都需要适配，区别更多是在难易程度上。

我设想了一个新例子，比如我一个已经存在的项目，实现了批量上传功能，调用方法入参是个包含 batchUpload() 方法的接口。

如果需要增加 A 作为云服务后端，而 A 的 sdk 只有单文件 put 功能，那么我适配的时候可以直接 func (a *A) batchUpload() { ... } 然后调用 a.put() 完成实现。

也就是说 Go 支持给我并没有所有权的代码里的结构体添加新的方法。换到 Java 里不能修改 A 的实现，就需要子类实现接口过渡一下。

在 Go 里 A 永远是那个 A ，而 Java 里子类和父类就要额外考虑类型兼容的问题。如果再有下游项目引用了我的包，或者需要 mock 一下做测试，Go 都是肉眼可见比 Java 简单很多。

@shinelamla #44

你说的不啰嗦就是我也感同身受，随便举几个例子。

从读的方面说，项目选型的时候有多个开源库备选，选哪个总要花很久调研。Go 在做同样的事情的时候，再复杂的项目，很快就能梳理清楚架构，了解代码质量。

我也是 Java 过来的人，写 Java 的时候我很讨厌写测试。原因是项目依赖很多都是非接口化的，真正用的时候要自己再封装一层。没有接口化的代码是很难做 mock 测试的，所以有很多测试框架使用了运行时动态生成 mock 代码的方式来解决这个问题，但是我内心还是不情愿写。

接触 Go 之后我反倒非常习惯写测试，不论依赖质量高低如何，mock 就是接口套一下的事情，代码很少。很早之前标准库想要提供 mock 的，后来废弃了，原因就是 mock 这个事情其实用不到再搞个库。还有个意外的副作用是甩锅的时候很有底气，接口内侧是我负责，外侧该找谁找谁。

所以我体会到最重要的事情是，只有机制上足够简洁便利，大家才会愿意用主动用，人性使然。大多数时间我并不想辩论“XXX 也可以”这种能不能的问题，大家都是图灵完备的换个表达方式而已，但是好不好用愿不愿意用才更重要。

@whitedroa #41

10 楼是走在路上手机回复的，感觉没说清楚，所以补了 11 楼的内容，后面的内容比较好理解一点。原意是 A/B 都是封装了对应厂商的 sdk 的实现，调用的时候是不关心具体是 A/B 哪个实例化的。

@lxdlam #45

之前走在路上手机回复了第一条，然后觉得不妥又举了代码的例子。经过反复讨论之后我觉得确实不合适，和我想表达的意思差得比较远了。

我这样重新总结一下，就用“推卸责任”这个说法，我觉得很恰当。

Duck typing 通过把类型检查推迟到运行时，达到了解耦接口与实现的目的。

在 Java 这类语言中，接口的定义和实现总是绑定在一起的。要么库的作者提前声明接口，然后给一个示例实现。要么调用方封装适配，把别人的代码封装到自己的接口里。

Go 里面把这个责任拆分了，写实现的就写实现，写接口的就写接口。都不用向对方负责。

@lxdlam #46

这个是我孤陋寡闻了。

我有个问题，可能严格来说 OCaml 更接近于 TS 那一类 structural typing 类型的语言？

@sagaxu #40

如果你认可要由使用者定义接口，那我们的立场是一致的。用到接口的时候再定义比预先设想就定义要好。

你举的例子正好就是 Go 风格接口的用法。区别在于如果你对 A/B 包的代码没有所有权的话（引入的第三方），并不能直接写 class A implements Storage 这样，所以一般要写一个子类 StorageA 然后你要手动完成 class StorageA implements Storage 内部的代码再封装一下。习惯上一般叫适配器模式吧。

编程语言在图灵完备层面是一样的，只是写法不同。这里的区别在于，Java 里面接口的实现和定义总是在一起的，或者说总是由同一个代码所有者完成的。我上面举的例子，接口定义和实现都是 A 的作者写的，你这个例子里实现和定义都是 main 的作者维护的。

在 Go 的例子里，接口和定义是分属不同的包，由不同的人实现的。

@aababc #38

楼上有个链接，也是提到了原文那个说法 accept interfaces, return structs 含义是很模糊的。

现在 reddit 上有个帖子，里面提到了这句话最原始的出处：
https://medium.com/@cep21/preemptive-interface-anti-pattern-in-go-54c18ac0668a

我上面的回答其实是个简化的版本，并没有非常正面回答 accept interfaces, return structs 的意义，因为这句话根本体现不出来接口对于 Go 的意义（况且很多场合并不适用）。

上面的解释是回归到本质，即它真正想解决的问题什么。我对这个问题的解释是，这样的写法不仅在代码层面把功能进行了解耦，也在工程层面对人的责任边界完成了切分。

就像你所说的，标准库里的接口是个指导作用，如果没有标准库的影响，下层写成任何形式都是有可能的。现在的写法是在当前语言表达能力下，最 idiomatic 那一个。

@gowk #23

就事论事，我不是很认可这位作者的说法。即使我和他得到了相同的结论，也不代表我们有一样的推理过程。

@whitedroa #31

我尝试用注释里带文件名的方式来区分是谁写的某个文件，看起来还是不够清晰表达意图。

现在假设我是一个包的作者，我只关心赶快完成我的功能。这时候 A.go 和 main.go 都是我自己写的，我的 use 方法入参就用我的 *A ，简单粗暴。

现在另一个人看到我写的包，他觉得你竟然把这么复杂的 A 业务给抽象出来了，那他就借你写的 A.go 里面的 get/put/... 方法一用吧，这样他就只需要写个 B 支持，就能同时支持 A/B 了。这里的重点是，他其实只想用我写的 get/put 方法，对其他的不感兴趣。

考虑到对他来说，他的 main 里面不希望为 A/B 写不同的调用方法，于是就写成了 func New(s Storage) *MyStorage 的形式，需要调用 get/put 就在 *MyStorage 上面调用。这个 type Storage interface 里面只包含 get/put 两个方法即可。

这样他的 B.go 就可以简单封装一下 sdk 满足接口就可以了。

这个事情还可以继续下去，第三个人看见了第二个人的代码，还可以添加 C 支持。甚至当他需要 get/put 之外第三个 delete 方法的时候，可以用到 embedding 机制：

```go
type C struct {
a A
}
func (c C) delete() { ... }
```

调用的时候接受一个三个方法 get/put/delete 的接口即可。

全程下游都不需要上游配合。

@yusheng88 #28

你有没有考虑过，为什么上游要提供接口呢？这是下游的事情。上游 preemptively 接口化是个违反工程实践的行为。

你的思路还停留在“Java 可以用 XXX 的方式来做同样的事情”，不好意思，就本文讨论的话题，Java 真做不到。

@sagaxu #19

你提到“我们”的时候，还是没有跳出固有的思维。

在 Go 的设计思想里，包或者说库的作者，应当（ should ）假定自己的包有一天可能成为别人的依赖。然而你并不需要假想别人要以何种方式使用你的包，你只管写你的实现完成功能就可以了。别人可能仅仅因为一个结构定义，或者一个导出方法就引用你的包作为依赖。

如果我自己要同时完成某个功能的 A/B/C 三个实现，我当然会提前把接口写好。但是如果我只有 A 的需求，那我完全可以不写接口，写成接口的形式是为了某一天我要添加 B/C 支持、或者我知道这个包可能被别人拿去用而做的预先设计。

无论如何，受限于 Java 的类型检查机制，如果最初没有写成接口，任何人除了包的作者都没有很简单的办法复用一个没有接口的包，因为把接口抽象出来这个操作只能由包的所有者完成。虽然你觉得原作者对于 A 功能的实现写得很好，但想拿过来用，才不得不选择复制粘贴，否则就要求助原包的作者将代码改成接口的形式。复制粘贴的问题是一旦上游更新，你就会面临是不是要手动跟随更新的问题。提 PR 是考虑到，减轻原作者的工作量，提高原作者接口化的意愿，避免你自己跟随更新的麻烦。

这两个都是在尽量减少对原包作者的依赖，但是在人的层面解耦不够彻底。

Reply

上面解释得可能还不是很清晰，我加一点代码来说明吧，还是以对象存储支持两个后端为例。由于回复不支持 markdown ，所以手动排版了一下。



1.
第一个非接口的版本：

```java
// A.java 实现功能的部分
class A {
____void get();
____void put();
}

// main.java 调用的部分
class main {
____void use(a A);
}
```

这个版本如果别人引用去，是很难添加 B 服务商支持的。除非是复制粘贴拿来用，但如果是复杂的项目，要么只能长期手动维护，要么向上游提 PR 。

所以包作者往往会以 preemptive 的形式，改成接口的版本，方便下游使用：

```java
// A.java
interface Storage {
____void get();
____void put();
}
class A implements Storage { ... }

// main.java
class main {
____void use(s Storage);
}
```

这样下游的人可以自己去适配另一个类 B 来实现 Storage 接口了。

```java
// B.java
import A.Storage;
class B implements Storage { ... }
```

这样做的问题是，如果 Storage 接口方法非常多（正常云服务 sdk 少说都有二三十个方法），那么 B 也要适配同样数量的方法。实际上下游适配 B 可能仅仅需要 get/put 两个方法而已，这对于开发和测试都是非常不利的。



2.
再来看看 Go 的初始非接口版本：

```go
// package A
type A struct { ... }
func (a *A) Get() {}
func (a *A) Put() {}

// package main
func Use(a *A)
```

然后上游作者就什么都不用管了。下游用户看到，想要增加 B 支持：

```go
// package B
type B struct { ... }
func (b *B) Get() {}
func (b *B) Put() {}

// package main
type Storage interface {
____Get()
____Put()
}
type MyStorage struct {}
func NewStorage(s Storage) *MyStorage { ... }
// 没有写成 func Use(s Storage) 是为了体现后半句 return structs ，这个不重要
```

其他不用管了。假如上游发布了更新，只要 Get/Put 接口签名不变（即上有发布的新版 API 向后兼容），那就可以直接升级使用。整个过程里，上游下游的工作是完全独立的。

即便考虑现实中 Storage 有几十个接口，下游用户也只需要实现他所用到的少量方法即可。



二者区别其实是在于：谁来定义接口。Java 的机制决定了只能是 producer 说了算，而 Go 则是 consumer 主导。这样看 preemptive 这个词的意义就很清晰了：还不知道会被怎么用的情况下就把接口定好了，当然是“抢占”了，实际上 Go 这里根本没必要预先定义，等用到的时候再写就是了，用多少写多少。

我刚好在写一模一样主题的文章，完成后会发上来。起因可以看我最近回复，当时我评价某个项目的代码“不能正确使用接口解耦”。

如果你在学习 Go 之前没有太多编程经验，这句话对你来说可能非常自然，自然到令人疑惑，因为你不知道反过来做是什么样子的。如果你的思维模型受 Java 的影响很深，那么理解这句话才能理解 Go 在解耦方面带来的巨大进步。（不抬杠，这里以 Go 和 Java 做对比纯粹因为最方便理解）

要说清楚这个问题需要比较大的篇幅，我这里简单概括一下。

1.
Go/Rust 这类现代语言都放弃了“继承”，这是设计思想的巨大进步，Java 这种旧时代的语言在设计的时候是没有意识到“组合优于继承”的。

理解组合优于继承对于中国人来说非常简单，汉语只需要几千个字就能描述整个宇宙，除此之外的其他语言的，那句台词怎么说的，不是针对谁，在座的诸位……

2.
基于组合的理念之上的 OO 抽象，才产生了 Accept Interfaces, return structs 这个 Go idiomatic 的范式。

我比较认同 Rob Pike 对这句话的评价，它不够准确，也不够精确。如果让我来表述，我会分成两句话：

- The bigger the interface, the weaker the abstraction. 这一句是纯引用作为铺垫，意在表达接口越小越好。

- Don't implement Interfaces preemptively. Preemptive 这个词一般翻译成“抢占式”，这里取其衍生含义，提前或者预先。Java 实现接口的代码范式就是 preemptive 的。

3.
Go 的隐式接口实现和 Java 显式接口实现，根本区别在于 Go 能够以接口为边界，从工程层面将开发工作解耦。

举个例子，你开发了一个库，功能是对象存储中间件，它支持以 A 厂商云存储作为后端，实现了 get/put 的读写方法。

如果有另外一个人需要增加对 B 厂商的支持：

- 用 Go 的话，他只需要引用你的包，然后定义一个包含 get/put 方法的接口，同时将 B 厂商的 sdk 做封装即可。调用的时候直接以接口为参数，而不需要关注具体实现接口的对象。

-用 Java 来实现的话，他要么把你的包以源码的形式复制一遍加入到项目里，要么就要向你提 PR ，来增加对 B 厂商的支持。这是因为 class B implements StorageInterface 只能写在你的包里。

这里就看出 Go 的先进之处了，你要做什么和原包的作者没有关系，原包的作者也不需要关心其他人是怎么用他的包的。而 Java 世界里，要么把上游的人拉进来，要么自己成为上游。代码上好像解耦了，但又没完全解耦，工程上是非常低效率的事情。

为了解决这个麻烦，Java 就有了 Preemptive 实现接口的惯例。考虑到需要增加适配，写类的时候有事没事先写个接口出来，不管用得到用不到。

但这样做的问题是，接口会变得巨大无比。一般的对象存储服务，少说也有二三十个方法。一个有二三十个接口的方法是什么概念？当你需要 mock 一下写测试的时候就有得受了，事实上你可能只会用到 get/put 两个接口而已。

然后 Java 提了一个叫 SOLID 的原则，其中 I 代表接口隔离，意思是要把接口拆分。问题是作为库的作者，你只有一次拆分机会，而包的使用者却有数不清的排列组合。


PS
补充几句题外话，我在 Go 语言主题里的回复经常会被人说是踩 Java 捧 Go ，但我依旧坚持有理有据地论证，而不是停留在嘴巴或者屁股上。

很容易看出来，如果设计思想落后了，想要模仿先进的东西是非常困难的。我不止一次重复过，考虑到 Java/Python 这些语言诞生的时间，从设计层面上评价它们落后是不公平的，毕竟这些语言作为先驱踩了坑，才会有后来现代语言的设计指导思想。

另外需要指出的是，Go 基于 duck typing 的隐士式接口的范式是少数不能通过语法糖等方式在 Java 中实现的机制。在一个静态类型语言上实现 weakly typed 的特性（ duck typing ），Go 应该算是第一个。

TLDR

不知道你考虑过冲突解析的问题？同一时间两个节点上的同一文件产生了不同的变化，要以哪个副本为准？如果存在这种情况，那你要解决的实际上是分布式系统的同步问题，方案会非常复杂。比如一般的对象存储，都是传一个副本，然后节点之间完成副本同步。

如果不存在这种情况，可以降级成非分布式问题，方案也简单很多。比如你只是需要多个备份，同一时间只会在一个节点上操作。这个情况比较简单的做法是选一个节点作为权威副本，其他的节点都以这个节点为准，向权威副本推送更新的时候要先合并权威副本。类似于使用 github 之类的平台进行协作的模式。rsync 加上简单脚本就能实现。


----手动分割----

这个问题没有普适的答案，本质上它是受分布式系统 CAP 理论限制的。需要确认需求，进而在 CAP 三者当中选二，然后才能确认方案。由于绝大多数情况下，P 是不能放弃的，所以要么只能 AP 要么只能 CP 。

AP 方案放弃 C ，结果就是某一个时刻，各个节点之间的副本有的是最新版，有的是旧版。

CP 方案放弃 A ，在任意同步行为完成之前，不能进行其他操作。

实际应用里最先考虑的是降级，把分布式降级为星型，就是上面说的权威副本节点。如果无法降级，那就需要使用基于 paxos/raft 这类共识算法的同步机制。

这个需求也算是 V2EX 上的常客了，我详细说一下思路和方向。

Linux 网络栈是在内核里实现的，流量统计就是 packet 计数（或者计量）这个计数有几个方式：

1. 内核态 pf 用户态 iptables

最简单的方式就是 iptables 对 chain 计数，只要把想统计的流量走一下自定义的 chain （这个 chain 可以什么都不做），就可以利用 chain 自身计数达到目的。

像 openwrt 之类的路由器统计内网流量基本都是这个方式，用 arp 配合 MAC 地址来区分客户端。

这个方式的优点是轻量，缺点是要预先设定规则。你的这个场景，如果几个朋友的 IP 有比较明显的区分度，可以根据 IP 段每个人走一个规则 chain 来统计。但是对于大量无规律来源 IP 就很难写这个规则，或者写出来几万条不实际。

2. conntrack

想要动态处理 ip 规则，就需要做基于状态的统计。conntrack 有自己维护一套映射表，这样就无需预先知道来源 ip 就可以按需统计。优点是灵活性比较高，但是性能影响也会比上一个方法高一些。

这两个方法的实现可以参考 https://openwrt.org/docs/guide-user/services/network_monitoring/bwmon 这个帖子 Available tools 章节，可以参考拿来用。

第一个方案其实很好写，第二个要想自己写可能需要比较多的背景知识。

3. 抓包自己算

就是计量的方式，不是很推荐的做法，为了做流量统计结果把所有数据包都过滤一遍，有点杀鸡用牛刀的意思了。

做个无责任推测，如果很多人同时发生类似的事情，可能是这个程序有个访问特定服务器的定时任务，然后服务器挂了导致程序无限高频重试，进而放大了内存泄漏、cpu 占用等问题。