支付宝数据加密流程，protobuf和grpc在golang中使用

数据加密：1对称加密（对名文的加密和解密都使用同一把钥匙）2非对称加密（消息的发送和接收，接收后回复，这四个数据传输点的钥匙都不同，钥匙的分类为私钥和公钥，任意一方会生成一对钥匙，保留在自己的的为私钥（任一保留）另一个发送对方为公钥，用私钥加密公钥解密，响应消息也是如此 非对称加密算法有Rivest, Shamir, Adleman）、DSA（Digital Signature Algorithm）和ECC（Elliptic Curve Cryptography）），如下是支付宝使用的RSA（铭文不加密使用签名加验签保证数据安全，如支付宝支付成功响应铭文，并自己定义规则生成铭文的签名发送出去，如果铭文被串改，验签不会通过）实现流程如图：

protobuf安装地址Releases · protocolbuffers/protobuf (github.com)选择指定的win版本，解压将bin目录添加path环境变量中，查看版本protoc --version。第二部下载golang的代码生成工具，默认protobuf不支持go代码生成下载方式如下 go install google.golang.org/protobuf/cmd/protoc-gen-go@latest

go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest
在项目的mod所在工程下下载grpc的依赖包go get goolge.golang.org.grpc会下载第三方依赖包，这是mod的go get包管理工具，要是本地gopath安装工具必须使用go install下载工具使用get get失败，没有报错就下载完成，在gopath目录的bin目录可以查看下载的工具。

创建proto文件，写入内容

// 指定采用 proto3 语法
syntax = "proto3";

// 相当于命名空间,生成的go文件处在哪个目录哪个包中.代表当前目录生成service生成的包名
option go_package =".;service";

//是一个接口实现对客户端和服务端的一个约束，不同的语言实现改方法完成调用
service SayHello{
  rpc SayHello(HelloRequest) returns (HelloResponse){}
}

//message可以理解为go中的结构体
message HelloRequest{
  string requestName = 1;    //不是赋值，而是指定唯一编号
  int64 age = 2;
  repeated string name=3; //定义生成golang中的切片类型
}
message HelloResponse{
  string responseMsg = 1;    //不是赋值，而是指定唯一编号,在message中的位置
}

//message PersonInfo{
//  message Person{
//    string name =1;
//    int32  height=2;
//    repeated int32 weight=3;
//  }
//  repeated Person info=1;
//}
嵌套使用结构体
//message showPerson{
//  PersonInfo.Person info=1;
//}

在同级目录下执行protoc --go_out=. hello.proto;protoc --go-grpc_out=. hello.proto

调用实现步骤如下：

总结：

  grpc是一个应用接口管理服务，它实现了对用户接口提供服务接口重写并调用它的功能，而grpc可以接收服务请求，并执行用户重写的方法，实现grpc和自己写的程序接口远程调用，而protobuf则作为传输数据的协议，它和http协议类似但比http协议快和占用内存小等特点，grpc可以跨语言调用只要语言双方各自实现一对请求和调用接口，就可以通过完整的Grpc框架定位和执行实现的目标方法。客户端在发起远程请求时一定要加密和验证来保证安全传输，Grpc通常用protobuf默认传输。下载openss来为自己的站点实现加密传输服务，在站点下建立key文件夹执行

生成私钥
openssl genrsa -out server.key 2048
使用openssl生成安全证书,全部回车即可
openssl req -new -x509 -key server.key -out server.crt -days 36500
生成csr
openssl req -new  -key server.key -out server.csr

生成密钥key文件以及根据key文件生成对应的证书crt文件，会有提示输入直接回车，最后生成cst文件。文件详情内容如下：

key：服务器上的私钥文件，用于对发送给客户端数据的加密，以及对客户端接收的数据解密。

csr：证书签名请求文件，用于提交给证书颁发机构对证书签名。

crt：由证书颁发机构签名后的证书，或者是开发者自签名的证书，包含证书持有人的信息，持有人的公钥，以及签署的签名等信息。

pem:是基于base64编码的证书格式，扩展名包含PEM、CRT、和CER。

文件生成完成后，找到openssl的安装目录下的bin目录的openssl.cfg文件复制到站点中，用于服务器端域名验证，然后生成证书私钥test.key, openssl genpkey -algorithm RSA -out test.key

通过私钥test.key生成证书请求文件test.csr(注意cfg和cnf)

openssl req -new -nodes -key test.key -out test.csr -days 3650 -subj "/C=cn/OU=myorg/O=mycomp/CN=myname" -config ./openssl.cfg -extensions v3_req

生成最后一个文件SAN证书pem

openssl x509 -req -days 365 -in test.csr -out test.pem  -CA server.crt  -CAkey server.key -CAcreateserial -extfile ./openssl.cfg -extensions v3_req 所有证书申请完成。生成了七个文件能用到的是test.key私钥文件和test.pem证书文件，其他文件是用来生成这两个文件用到的内容文件，pem证书文件是给客户端使用，key文件存放在服务器端用来验证，有了这两个关键文件通过grpc请求时就可以实现加密传输。

客户端只需要pem证书私钥在服务器端test.key比较安全,第二个参数是服务器openssl.cfg中添加的效验的域名，因为证书生成时携带了配置文件里面的设置内容，服务端TSL认证两个参数分别是certFile，keyFile自签名证书文件pem和私钥文件key生成reds传给Grpc服务。

Grpc使用token方式验证；grpc提供接口credentials包下

type PerRPCCredentials interface {
GetRequestMetadata(ctx context.Context, uri ...string) (map[string]string, error)
// RequireTransportSecurity indicates whether the credentials requires
// transport security.
RequireTransportSecurity() bool
}

第一个参数是获取元数据信息，也就是科幻段提供的key，value对，context用来控制超时和取消，uri是请求入口处的uri

第二个参数的作用是否需要基于TSL认证进行安全传输，如果返回是true，必须加上TSL验证，返回false则不用。

token的分发需要查询数据库验证用户名密码，并把token存入到数据库，下次访问时获取请求的token在从数据库查找有无token，没有登陆失败，好处是拒绝频繁地查找用户密码的登陆数据，防止关键信息泄露，查询token好处是数量不大，有过期删除等功能，入放入redis中。