kuanat

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 占用等问题。

语法层面过一遍官方的 Tour 差不多够了。

练手的话我比较推荐尝试写个爬虫服务，不是让你真去爬什么，而是这个过程用到的东西学习曲线比较平滑。

解析页面元素这个过程，大概能熟悉强类型语言处理字符串的模式，了解结构体的应用。后期还会接触到反射等机制的应用。

之后是一般的网络编程，发送接收请求。这个过程可以熟悉标准库的风格和惯例，网络库算是 Go 比较精髓的部分了。

再之后是多线程处理，了解 chan/goroutine 的使用，以及常见的并发模型。领会一下用通信的方式来共享内存的核心思维。

最后把改造成服务，学习一下路由处理、中间件等等服务端常见的应用。之后有可能会慢慢接触到模板、泛型的应用。

前期不用考虑处理太复杂的情形，用标准库把功能实现出来就行。整个过程里可以慢慢熟悉后端工程化的实践。