Http服务器

Golang有一个很强大的官方http库了，使用上很方便。也有一些很强大的三方http框架， 比如gin，beego等等。 自以为，框架在提供便利，提升开发效率的同时，也限制了我们的想象力。 相对beego而言我更喜欢gin这样的简单高效框架，给我们提供了一些基础设施。剩下的有什么功能需要自己写进去就好了。

热更新

1. 动态脚本更新 (php)

2. 短链接无状态服务器热更 (http)

3. 长连接有状态，数据跟逻辑分离

   • golang Plugin热更 (.so 动态库更新) —-逻辑热更

4. 长连接有状态,在运维层面, 利用容器部署热更(docker, k8s)

   • 服务不接受新连接,处理完剩余连接的逻辑，主动关闭。由已经更新过的服务接收新连接处理逻辑。

golang插件更新

下面代码实现的需求:

热更新

1. 动态脚本更新 (php)

2. 短链接无状态服务器热更 (http)

3. 长连接有状态，数据跟逻辑分离

   • golang Plugin热更 (.so 动态库更新) —-逻辑热更

4. 长连接有状态,在运维层面, 利用容器部署热更(docker, k8s)

   • 服务不接受新连接,处理完剩余连接的逻辑，主动关闭。由已经更新过的服务接收新连接处理逻辑。

golang插件更新

下面代码实现的需求:

概述

现在有个需求，需要在grpc的拦截器中，通过token进行身份认证。如果认证不通过则返回错误; 认证通过，则放行;

TLS是用作加密通讯通道的，与该需求无关。

Token认证

具体流程

• 客户端通过账号密码登录服务器，登录成功服务器返回一个token给客户端。
• 客户端携带token信息往服务器请求业务逻辑的接口，，服务器收到请求，解析验证token，验证通过，则放行。

协议文件

概述

现在有个需求，需要在grpc的拦截器中，通过token进行身份认证。如果认证不通过则返回错误; 认证通过，则放行;

TLS是用作加密通讯通道的，与该需求无关。

Token认证

具体流程

• 客户端通过账号密码登录服务器，登录成功服务器返回一个token给客户端。
• 客户端携带token信息往服务器请求业务逻辑的接口，，服务器收到请求，解析验证token，验证通过，则放行。

协议文件

使用golang的grpc库作为例子

grpc使用TLS建立安全连接需要有SAN证书， go 1.15 版本开始废弃 CommonName。

什么是SAN证书

SAN(Subject Alternative Name) 是 SSL 标准 x509 中定义的一个扩展。使用了 SAN 字段的 SSL 证书，可以扩展此证书支持的域名，使得一个证书可以支持多个不同域名的解析。

制作SAN证书

一条指令生成ca证书

使用golang的grpc库作为例子

grpc使用TLS建立安全连接需要有SAN证书， go 1.15 版本开始废弃 CommonName。

什么是SAN证书

SAN(Subject Alternative Name) 是 SSL 标准 x509 中定义的一个扩展。使用了 SAN 字段的 SSL 证书，可以扩展此证书支持的域名，使得一个证书可以支持多个不同域名的解析。

制作SAN证书

一条指令生成ca证书

缘由

最近在写技术博客时，引入的代码太多，影响观感。 在尽力减少代码量，还是有些不可或缺的代码，代码量很惊人，已经占满整个屏幕.

因为个人博客是使用hugo生成的静态博客，我刚开始想的使用原生的js和css来实现，奈何技术不足，我是做后端的，一度想放弃 后面还是在网上发现h5有个新的标签<details><summary></summary></details>可以实现显示/隐藏的功能。

静态网站

应用场景

• 文件服务
• 静态网站
• …

静态网站的配置

配置如下:

worker_processes  1;
pid        nginx.pid;

events {
    worker_connections  1024;
    multi_accept on;
}


http {
    default_type  application/octet-stream;


    sendfile        on;
    keepalive_timeout  100;

     server {
        listen 80;
        charset utf-8,gbk;
        server_name localhost;

        location /{
            root /opt/;
		    autoindex on;
		    autoindex_localtime on;
	    }

	    index index.html; # 显示首页

        #静态文件访问
	    location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|js|pdf|txt) {
            root /opt;
        }
    }
}

• root: 表示网站根目录
• autoindex: on 显示目录, off 关闭目录展示

同一个IP:PORT指向不同的地址

应用场景

• 移动端+PC端两套网站，部署在同一台服务器上

配置

配置如下:

A*算法思路

寻路步骤

1. 从起点A开始, 把它作为待处理的方格存入一个"开启列表", 开启列表就是一个等待检查方格的列表.
2. 寻找起点A周围可以到达的方格, 将它们放入"开启列表", 并设置它们的"父方格"为A.
3. 从"开启列表"中删除起点 A, 并将起点 A 加入"关闭列表", “关闭列表"中存放的都是不需要再次检查的方格
4. 从 “开启列表” 中选择 F 值最低的方格 C (绿色起始方块 A 右边的方块), 把它从 “开启列表” 中删除, 并放到 “关闭列表” 中.
5. 检查它所有相邻并且可以到达 (障碍物和 “关闭列表” 的方格都不考虑) 的方格. 如果这些方格还不在 “开启列表” 里的话, 将它们加入 “开启列表”, 计算这些方格的 G, H 和 F 值各是多少, 并设置它们的 “父方格” 为 C.
6. 如果某个相邻方格 D 已经在 “开启列表” 里了, 检查如果用新的路径 (就是经过C 的路径) 到达它的话, G值是否会更低一些, 如果新的G值更低, 那就把它的 “父方格” 改为目前选中的方格 C, 然后重新计算它的 F 值和 G 值 (H 值不需要重新计算, 因为对于每个方块, H 值是不变的). 如果新的 G 值比较高, 就说明经过 C 再到达 D 不是一个明智的选择, 因为它需要更远的路, 这时我们什么也不做.
7. 当我们发现 “开始列表” 里出现了目标终点方块的时候, 说明路径已经被找到.

对每个格子怎么走，往哪个方向走有一个很重要的函数-估价函数, 公式如下: