怀疑你们公司想搞数据中台。
还有微服务的设计原则是什么？什么原则说只能这样做不能那样做？微服务提出纵向切分服务的可能，但也没有否定横向切分吧。

软件架构符合康威定律，什么样的团队结构，会有什么样的软件架构。

你把 slice 类型看作是一个大概这样子的 struct
type Slice struct {
len int
mem *unsafe.Pointer
... other info
}
函数参数是值传递，就是把 s 复制了一遍到 a
其实 a 和 s 只是用了同一个内存指针，其他都是独立的

背题+1

Make 的时候你只设了容量，没有设长度

mbp16 分 24 期，也就不到 30 块钱一天啊，一顿饭的钱

KPI 和 OKR 其实都是目标管理工具，最直观的区别是，前者和工资挂钩，后者只是和你“谈谈人生谈谈理想”。
“KPI 督促每个人快速解决问题”
这是对的，帮助大家专注于目标
“不考虑问题的深度以及重复性和潜在的风险“
这锅不应该由 KPI 来背，KPI 只是工具，KPI 的内容是人定的
“怎么破才好”
制定 KPI 的时候和管理者谈谈，或者坚定按照 KPI 字面执行

昨晚给奶奶买了台 note8

#6 的代码不对，send header 应该在 send body 之前。
http.HandleFunc("", func(writer http.ResponseWriter, request *http.Request) {
var reader io.Reader
//{
// file, err := os.Open("")
// if err != nil {
// writer.WriteHeader( http.StatusNotFound)
// return
// }
// reader = file
// defer file.Close()
//}
{
resp, err := http.Client{}.Get("")
if err != nil {
writer.WriteHeader( http.StatusNotFound)
return
}
reader = resp.Body
}
writer.Header().Set("content-type", "text/plain")
_, _ = io.Copy(writer, reader)
return
})

如果你不是读取本地文件，而是从别人的请求中转发数据，你留意一下 http.Response 的 body 是已经实现了 reader interface，只需要从 reader copy 数据到 writer 就可以了。

面向接口编程，你需要什么接口，去找对应的实现就可以了。

http.HandleFunc("", func(writer http.ResponseWriter, request *http.Request) {
file, err := os.Open("")
if err != nil {
writer.WriteHeader(404)
return
}
defer file.Close()
if _, err := io.Copy(writer, file); err != nil {
writer.WriteHeader(500)
return
}
writer.Header().Set("content-type", "text/plain")
writer.WriteHeader(200)
})

我猜，这是 LZ 看到的：
jsonObject -> sendRequest(jsonObject) -> client -> server -> handleRequest(jsonObject)

LZ 对 request body 签名的理解：
jsonObject -> sign(encode(jsonObject)) -> sendRequest(jsonObject) -> client -> server -> handleRequest(jsonObject) -> verify(encode(jsonObject), sign)

但实际上是：
jsonObject -> sendRequest(jsonObject) -> body = encode(jsonObject) -> post(body) -> client -> server -> recv(body) -> jsonObject = decode(body) -> handleRequest(jsonObject)

对 request body 签名的正确理解：
jsonObject -> sign(encode(jsonObject)) -> sendRequest(encode(jsonObject)) -> client -> server -> handleRequest(jsonString) -> verify(jsonString, sign)

@LinJunzhu 我尽力了
既然你上来是找答案的，别人已经给了你经过实践验证的答案，那就先实践，遇到问题再提问。你都没解决方案了，你还没试过别人给的方案就忙于反驳，这是真的如你提问中所说，想看看别人怎么做的么？

@chenqh 对，有些地方叫 appid，有些地方叫 clientid

@LinJunzhu
注意这一行：“Content-MD5: ……, 等同于对 body 数据的 md5sum”（简单理解，payload 实际上时一个 byte 数组，可以直接求 md5 ）

劝你先忘掉微信 API 那个方案，它那个场景很有可能是因为安全原因，网关过滤了 header 和 query 的自定义字段，导致 signature 只能放在 body 中。

如果你还是坚持按照微信 API 那种模式，有个笨方法，就是把你要传递的 content 对象序列化后，当作字符串参数看待，即在原来的 body 上再包多一层：
{
content: string // "{\"key\":\"value\"}"
appid: string
sign: string
}

@fkdog lz 的需求其实是身份认证，是想知道这个请求是谁发出的，并且要有数字签名证明。
https 解决不了 C 公司冒充 A 公司向 B 公司发起转账申请，除非你启用 tls 的双向验证，这时候需要给每个请求方发放 client 证书，服务端还需要实现从证书中提取请求方 ID，才知道是谁发起的请求，实现难度比数字签名大一点。

给一个我正在使用的方案：

Signature = HMAC-SHA1( '您的 SecretKey', UTF-8-Encoding-Of( $StringToSign ) ) );

StringToSign = $HTTP-Verb + "\n" +
$URL + "\n" +
$Query + "\n" +
$Content-Type + "\n" +
$Content-MD5 + "\n" +
$Date + "\n" +
$AccessKey;

HTTP-Verb: 指 HTTP 请求方法如, GET, POST, PUT, DELETE
URL: 指所访问的资源路径如, /your/resource/path
Query: 指请求中的 Query 参数, 其构成规则如下:
对参数 key 进行升序排序
对于所有参数以 key+value 方式串联
Content-Type: 请求 Header 中的 Content-Type 值
Content-MD5: 请求 Header 中的 Content-MD5 值, 等同于对 body 数据的 md5sum
Date: 整形, 请求发生时的时间戳（用于防重放的，不需要可省略）
AccessKey: 用户自己的 AccessKey

最后在 request header 中增加：
x-singnature: $Signature
x-accesskey: $AccessKey
x-date: $Date

@LinJunzhu 你发的那个是链接我看了，人家之所以这样做，是因为把 signature 放在了 body 中传送，可能由于他们协议的要求不能在 query 参数或者 header 中存放额外字段。

如果你们没有这种限制，最好的办法是把 signature 放在 header 中（ aws 就是这样做），签名时针对 body 进行签名。这样做得好处是，api 网关做签名校验时，不需要反序列化，性能更高，更通用，无论什么 content 类型都支持。

你签名的目的是保证 request 的 body 不被篡改，至于 body 的 content-type 是什么没有关系。
直接对 request 的 body 进行签名就好了。

我猜 lz 主要是把 json 字符串和 json 对象搞混了，json 对象是具体语言对 json 字符串的面向对象表达方式。
http request 的 payload 实际上只能是一个 byte 数组，你之所以觉得会有 json value，other value 之分，是因为你所使用的库抽象封装了。查看源码你会发现，json 对象是需要 encode 成 json 字符串，才放进 request payload 里面。

回到问题，lz 应该自行对 json 对象进行 encode，并对 json 字符串进行签名，你所使用的库应该提供 set raw payload 的方法。
引申问题，lz 你对 http 协议的理解可能还只停留在你所使用的库层面上，建议你还是更仔细学一下 http 协议。