kratos 的proto http 插件——protoc-gen-go-http，对body以及query参数只能选择其一支持，不论其Method为何种。query、vars支持同时存在。

源码可查：go-kratos/kratos/cmd/protoc-gen-go-http/template.go。

这一部分由于内部技术栈的问题，需要统一，同时，需要有更多的改造，接入公司内部RPC，导入一致的服务治理等需求，所以需要一个Go版本的发号器，搜了网上很多版本，发现并没有Leaf的替代版本，而Leaf的实现细节有很多文章都分析过了，这样看起来移植一下也不困难了。

美团Leaf的技术细节在官方文档中介绍的很详细，这里参考其技术实现细节Leaf——美团点评分布式ID生成系统。

本篇将演示如何简单的搭建起整个监控平台。当前服务主要使用语言为Go，所以下面均用Go作为后端服务。

看下服务治理的大概定义：

1、服务注册与发现。

2、可观测性。

整理一下docker的基础命令，以及多阶段编译的简单应用。

基础命令

• FROM

传输层：UDP和TCP。

这俩协议真是有太多说的了，毕竟网络里头，TCP/IP协议栈，可太重要了。

TCP与UDP区别

常见的，TCP是面向连接的，UDP是面向无连接的。

在互通之前，面向连接的协议会先建立连接。例如，TCP会三次握手，而UDP不会。

趁着这段时间有点时间，把之前了解的零零散散的网络知识笔记都整理了一下，集中回顾一遍，加深一下印象。

网络方面的东西，我也是后面才去详细了解的，之前知道的都比较片面，对一些点知道的比较浅，也就对UDP、TCP了解的会稍微多一点，后面当我详细去了解的时候，我发现看完之后豁然开朗，就像表面上没改变什么，但实际上对上层的事了解的更多了，很玄妙的感觉。

软件架构大多数情况下不会影响我们将来上线产品，但糟糕的代码必然会堆积成山，由我们未来背负。这里我们首先要明白软件开发的两个难点：

技术难，代码量可能不多，但都是一些比较核心的需要攻坚型的问题，不是靠“堆人”就能搞定的，比如自动驾驶、图像识别、高性能消息队列等；

复杂度，意思是说，技术不难，但项目很庞大，业务复杂，代码量多，参与开发的人多，比如物流系统、财务系统等。

Frangipani: 一个可伸缩的分布式文件系统

摘要

理想的分布式文件系统应该为所有用户提供对同一组文件的一致的统一的访问，并且可以任意伸缩，以便为不断增长的用户社区提供更多的存储空间和更高的性能。尽管组件出现故障，但它仍然具有很高的可用性。这将需要最少的人工管理，并且随着添加更多组件，管理不会变得更加复杂。

论文理解

ZK的论文里面的东西感觉很多都是和ETCD相似的，之前也写过ZK的一些不同的点，原理上，毕竟其也是基于raft协议的，操作上相似感觉比较合理。

Aurora，这里面还是有很多东西的，不管是基于MySQL的改造（canal搬运log感觉很像），另外还有quorum因地制宜的使用，数据库服务与存储层服务的分层设计，简化副本复制，采用链式复制等，对这种大型服务的设计能力可见一斑。