本周ARTS
本周ARTS打卡内容：
- Algorithm 来源 LeetCode21
- Review 分享 Envoy and gRPC-Web，相比于REST，一种新的选择
- Tip 分享 gitlab中添加badge的方法
- Share 分享 go进行前端开发的框架
Algorithm
LeetCode的21题，合并两个排序的链表：
https://leetcode.com/problems/merge-two-sorted-lists/
将两个链表中的元素依次比较，其中较小的作为排序后链表的元素，直到两个链表的最后。这题比较简单，需要注意的是，排序后链表元素，每次需要分配空间，具体程序如下：1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30func mergeTwoLists(l1 *ListNode, l2 *ListNode) *ListNode {
var l3 = ListNode{0, nil}
var node1, node2, node3 = l1, l2, &l3
for node1 != nil && node2 != nil {
if node1.Val <= node2.Val {
node3.Next = &ListNode{node1.Val, nil}
node1 = node1.Next
} else {
node3.Next = &ListNode{node2.Val, nil}
node2 = node2.Next
}
node3 = node3.Next
}
if node1 == nil {
for node2 != nil {
node3.Next = &ListNode{node2.Val, nil}
node2 = node2.Next
node3 = node3.Next
}
}
if node2 == nil {
for node1 != nil {
node3.Next = &ListNode{node1.Val, nil}
node1 = node1.Next
node3 = node3.Next
}
}
return l3.Next
}
Review
本周的内容是：Envoy and gRPC-Web: a fresh new alternative to REST
算是上周Review内容的延续
https://blog.envoyproxy.io/envoy-and-grpc-web-a-fresh-new-alternative-to-rest-6504ce7eb880
gRPC-Web的优势在于构建端到端的gRPC服务架构，从web客户端到全流程。以前，我们想连接一个gRPC的后端和一个web前端，我们需要写REST API服务将HTTP请求，转换到gRPC。如果可能我们想尽可能避免这样的转换。而gRPC-Web能帮助我们做到这一点，通过Protocol Buffers传输数据，不需要HTTP服务。
REST的方式
左图中显示的是传统的REST方式，右图中是gRPC-Web的方式。左图中，REST API服务器扮演着连接web app和后端服务器的作用。比如，我们前端要使用gRPC的后端授权服务，POST json到HTTP服务器的/auth，HTTP服务器将POST请求转换为AuthRequest的Protobuf信息，发送信息到后端gRPC授权服务，然后授权服务返回AuthResponse信息，通过HTTP服务器转换为JSON返回给前端。如果前端能通过gRPC直接发送给后端，发送AuthRequest给后端，后端直接返回AuthResponse，那么就不需要HTTP服务，也不需要维护HTTP状态码、JSON解析、HTTP服务的部署和管理等等。
在右图中，架构更加清晰，一种协议贯穿整个系统，没有HTTP处理，所有的数据接口都定义在.proto文件中。前端发送Protobuf信息，后端返回Protobuf。
Envoy的使用
前面说到给RPC-Web客户端直接发送gRPC请求到后端服务，是不完全正确的。使用gRPC-Web，客户端调用需要被转换为gRPC友好的请求，这个功能已经由Envoy实现。Envoy也是gRPC-Web内置的默认服务网关。
上图展示了一个基本的Envoy结合gRPC-Web使用图。web app和后端gRPC服务交互，该gRPC又依赖其他两个gRPC服务。Envoy将客户端的HTTP/1.1请求转换为后端服务能处理的HTTP/2请求(gRPC使用HTTP/2传输)。底层其实还是需要进行HTTP协议的转换，但客户端和服务端都不需要考虑HTTP层的问题。
Envoy的配置
以下是Envoy 代理的Yaml配置，该Envoy监听8080端口的HTTP客户端连接，然后将这些连接发送到后端gRPC服务。1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43static_resources:
listeners:
- name: listener_0
address:
socket_address: { address: 0.0.0.0, port_value: 8080 }
filter_chains:
- filters:
- name: envoy.http_connection_manager
config:
codec_type: auto
stat_prefix: ingress_http
route_config:
name: local_route
virtual_hosts:
- name: local_service
domains: ["*"]
routes:
- match:
prefix: "/”
route:
cluster: auth_service
cors:
allow_origin:
- "*"
allow_methods: GET, PUT, DELETE, POST, OPTIONS
allow_headers: keep-alive,user-agent,cache-control,content-type,content-transfer-encoding,x-accept-content-transfer-encoding,x-accept-response-streaming,x-user-agent,x-grpc-web
max_age: "1728000"
expose_headers: grpc-status,grpc-message
enabled: true
http_filters:
- name: envoy.grpc_web
- name: envoy.cors
- name: envoy.router
clusters:
- name: auth_service
connect_timeout: 0.25s
type: logical_dns
http2_protocol_options: {}
lb_policy: round_robin
hosts:
socket_address:
address: auth-server
port_value: 9090
以上就是Envoy的一份基本的HTTP配置，做了以下修改：
- 非典型报文头— x-grpc-web，grpc-status以及grpc-message，这些是处理gROC-Web请求需要的
- 内置的envoy.grpc_webHTTP过滤器用来完成繁杂的gRPC-Web代理工作
http2_protocol_options: {}表示auth_service处理HTTP/2(本例中是gRPC)连接
只需要写一些yaml文件，就能从冗长的HTTP服务开发中解脱。再不用关系HTTP与gRPC映射，不用到StackOverflow中询问哪个状态码响应到哪个服务状态，不用将JSON转到Protobuf信息。
Tip
最近在kubernetes集群中搭建了gitlab及gitlab-ci，这里说一个README中加入小图标的方法。
pipeline、coverage的图标：
在Setting - CI/CD - General pipelines 中可以看到Pipeline status和Coverage report图标对应的，注意Coverage report需要添加覆盖率测试的解析地址。
定制图标：
在Setting - Badges中进行定制
Share
使用Go语言来编写前端