ETCD Resolver 示例

ETCD ：gRPC naming and discovery

无意中在V站发现了有人提到ardanlabs的课程，课程怎么样不清楚，贵是真的很贵(699刀了)，但其在GitHub上的文档我觉得写的很好。

Ultimate Go：https://github.com/ardanlabs/gotraining/blob/master/topics/go/README.md

服务内部访问中，负载被均匀地分发给所有的后端服务，在任何时刻，最忙和最不忙的节点永远消耗同样数量的CPU。负载均衡（Load Balancing）是微服务可用性比较重要的一个技术，其目标：

• 均衡的流量分发。

消息队列一直是一个神兵利器，我之前也写过用于简化kafka消费和生产的中间件，其完整版也尝试在一些项目中使用。效果也还不错，这里也是巧然了解到可以增加Kafka单一partition并发消费能力的方法（为了保证partition而使用单一线程进行消费），也找到了解决方法，这里是对代码的一些分析，完整的注释解析就不放了。

Protocol Buffers（简称：ProtoBuf）是一种序列化数据结构的协议。对于透过管道(pipeline)或存储资料进行通信的程序开发上是很有用的。这个方法包含一个接口描述语言，描述一些数据结构，并提供程序工具根据这些描述产生代码，用于将这些数据结构产生或解析资料流。——维基百科

如题，etcd终于解决了一个老大难的问题，就是依赖问题，它简直不要让人再多痛苦了。

在新发布的etcd 3.5中，已经解决了对Go Module 的支持，并将之前大的 etcd 模块按功能进行了拆分，实现了 etcd 的模块化等，解决了各种 “go get fail”、依赖复杂、循环依赖、以及强制依赖过低的 gRPC 版本等问题，使用起来更简单了。

引言

对于后端来说，可能都会从入门的HTTP，到后面的Server RPC阶段，在实践中GRPC确实好用，调用其他服务和调用一个似的，没什么区别，而且相对于HTTP来说，功能更强劲，扩展性更强。

当我们使用gateway作为HTTP—GRPC的转换器后，前端既可以直接通过HTTP访问后端服务的GRPC接口，不需要多开发一个HTTP Server，而且引入GRPC后好处还不止这些。

之前对ETCD中实现的MVCC了解了一点，现阶段了解MySQL也看到了这一部分，还是比较有收获的，以前写代码虽然有注意，但是没有这么深入理解过，所以有些代码现在看来，依然是有瑕疵的。

下面会讲到一致性，我这里查过了，MySQL中的一致性，和ETCD、ZK中的一致性不是同一个东西，这个知乎回答比较好，但没有说明两者的区别。当然这里是一个事务中的，一个各副本间进行线性读操作的，从实际上来看，貌似就有不同。

MySQL中的索引，一般来说，我们使用的比较多的是b+tree，hash索引。

且因为在MySQL中，存在不同的存储引擎，这两种索引存在的形式也有些不大一样。这里我们也只引入MyISAM和Innodb存储引擎。