这个是很多人的痛，如果遇到D哥C哥一晚上起来房子就不见了。
这个代码会检测套餐流量包使用情况,如果低于限定值就停机，扔进crontab定时执行一下就好了。安心睡觉吧。

package main

import (
    "fmt"

    openapi "github.com/alibabacloud-go/darabonba-openapi/v2/client"
    swas_open20200601 "github.com/alibabacloud-go/swas-open-20200601/client"
    "github.com/alibabacloud-go/tea/tea"
)

const (
    ReservedGB = 10                                 // 预留流量GB，低于此值将自动关机
    RegionId   = "cn-hongkong"                      //区域ID
    Key        = "XXXX"         //AccessKey
    Secret     = "XXXX"   //AccessSecret
    InstanceID = "XXXX" //实例ID
)

func CreateClient(Key, Secret string) (_result *swas_open20200601.Client, _err error) {
    config := &openapi.Config{
        AccessKeyId:     tea.String(Key),
        AccessKeySecret: tea.String(Secret),
    }
    config.Endpoint = tea.String("swas." + RegionId + ".aliyuncs.com")
    _result = &swas_open20200601.Client{}
    _result, _err = swas_open20200601.NewClient(config)
    return _result, _err
}

// 返回套餐已用流量，总流量，错误信息
func GetTrafficQuota(Key, Secret, InstanceID string) (int, int, error) {
    client, err := CreateClient(Key, Secret)
    if err != nil {
        return 0, 0, err
    }

    request := &swas_open20200601.ListInstancesTrafficPackagesRequest{
        InstanceIds: tea.String("[\"" + InstanceID + "\"]"),
        RegionId:    tea.String(RegionId),
    }

    response, err := client.ListInstancesTrafficPackages(request)
    if err != nil {
        return 0, 0, err
    }

    return int(*response.Body.InstanceTrafficPackageUsages[0].TrafficUsed), int(*response.Body.InstanceTrafficPackageUsages[0].TrafficPackageTotal), nil
}

func HaltServer(Key, Secret, InstanceID string) error {
    client, err := CreateClient(Key, Secret)
    if err != nil {
        return err
    }

    request := &swas_open20200601.StopInstanceRequest{
        InstanceId: tea.String(InstanceID),
        RegionId:   tea.String(RegionId),
    }

    _, err = client.StopInstance(request)
    if err != nil {
        return err
    }
    return nil
}

func main() {
    Used, Total, err := GetTrafficQuota(Key, Secret, InstanceID)
    if err != nil {
        fmt.Println(err)
        return
    }
    fmt.Printf("Used: %d GB, Total: %d GB\n", BytesToGB(Used), BytesToGB(Total))
    if BytesToGB(Total-Used) < ReservedGB {
        fmt.Printf("Warning: The remaining traffic is less than %dGB,server halt!\n", ReservedGB)
        HaltServer(Key, Secret, InstanceID)
    } else {
        fmt.Println("The remaining traffic is enough!")
    }
}

func BytesToGB(b int) int {
    return b / 1024 / 1024 / 1024
}

这个blog是用typecho弄的，够简单，搭起来很快，不过真要用问题不少。
先前弄在netcup上，性能足够强大，不过国内网络访问一言难尽。
然后弄在香港阿里，为了这个我特地把机器从24升到了34，就是2C1G到了2C2G。不过nginx+php+mariadb+长亭一跑，没多少空闲内存了。其实对于1IP也可以接受，虚拟内存开上应付一下可能偶尔出现的OOM就好，不过我处女座，你懂。
最后决定，手里有个免费的甲骨文的ARM机，已经吃灰了好几年了，4C24G，用起来吧。香港反代到甲骨文，两地连接40ms，用户感觉不出来啥，但24G内存彻底就没了内存焦虑了。
至于甲骨文可能会不稳被删号的问题，小意思，一是我这老号基本不可能删，二是，我跑了一个脚本，每天把它备份到香港就好。甲骨文口子够大，流量不要钱，对阿里，备份是进流量，口子也大也不要钱，完美。

这几天在弄这个blog，所以问题也是特别多。

先前我是用的CF，CF对中国劣化那是很出名的，我看了一下，目前是绕去卢森堡再回源香港，实在没法用。
因为blog在阿里香港，dd来了我没办法，但cc总得想想办法吧。
加了个waf，选了长亭雷池，这个目前还是比较流行。

一般如果前端有CDN/WAF，后端通常走http协议，毕竟web服务器做https也是一个开销，https由CDN端编码。

好了，现在我们假定用户是通过HTTPS访问WAF，然后再通过后端HTTP访问源。源以为自己是被HTTP访问，它里面的链接，包括图片，包括超链，它将可能会返回 http://xxxxxxx/123.jpg http://xxxx/123.php 这个形式。 这样是不优美的，应该是返回 /123.jpg这样，就是用相对链接，不要用绝对的。但不能指望后端的页面都规范，我现在说的就是typecho，也很有名啊，它就返回了http://xxxxx/123.jpg。

现在问题来了，前端是https页面，然后页面内容里包含进了http形式的图片和链接，因为安全原因，浏览器将拒绝加载它们，所以，这个页面，废了。。

CF的解决是:

Automatic HTTPS Rewrites
Automatic HTTPS Rewrites helps fix mixed content by changing “http” to “https” for all resources or links >on your web site that can be served with HTTPS.
就是，回源返回的页面里，如果有http://，就把它改成https://。

这么简单的解决办法，这么常见的问题，长亭雷池就没注意到。国产软件任重而道远啊。

因为需要买这个，手抢累，手撸了段代码。
这程序本身意义不大，不过可以做为阿里SDK的范本，比如我还需要写一个流量到了自动关机的脚本。

package main

import (
    "fmt"
    "os"
    "time"

    openapi "github.com/alibabacloud-go/darabonba-openapi/v2/client"
    swas_open20200601 "github.com/alibabacloud-go/swas-open-20200601/client"
    "github.com/alibabacloud-go/tea/tea"
)

func CreateClient(Key, Secret string) (_result *swas_open20200601.Client, _err error) {
    config := &openapi.Config{
        AccessKeyId:     tea.String(Key),
        AccessKeySecret: tea.String(Secret),
    }
    config.Endpoint = tea.String("swas.cn-hongkong.aliyuncs.com")
    _result = &swas_open20200601.Client{}
    _result, _err = swas_open20200601.NewClient(config)
    return _result, _err
}

func RealBuy(Key, Secret string) error {
    client, err := CreateClient(Key, Secret)
    if err != nil {
        return err
    }
    request := &swas_open20200601.CreateInstancesRequest{
        RegionId: tea.String("cn-hongkong"),                      //香港
        ImageId:  tea.String("8b798eb927684a08b26bb95da94f5812"), //轻量24
        PlanId:   tea.String("swas.s2.c2m1s40b30t1.un"),          //debian 11
        Period:   tea.Int32(1),
    }
    _, err = client.CreateInstances(request)
    if err != nil {
        return err
    }
    return nil
}

func main() {
    location, err := time.LoadLocation("Asia/Shanghai")
    if err != nil {
        fmt.Println("Error loading location:", err)
        return
    }

    args := os.Args
    if len(args) < 3 {
        fmt.Printf("Usage: %s <AccessKeyId> <AccessKeySecret>\n", args[0])
        return
    }

    fmt.Println("Waiting for 00:00:00 to start...")
    now := time.Now().In(location)
    tomorrowMidnight := now.Truncate(24 * time.Hour).Add(24 * time.Hour)
    time.Sleep(time.Until(tomorrowMidnight))

    for i := 0; i < 10; i++ {
        err := RealBuy(args[1], args[2])
        if err != nil {
            fmt.Printf("%d - Error: %s\n", i, err)
        } else {
            fmt.Printf("%d - Success! Please check it in your aliyun console.\n", i)
            break
        }
    }

    fmt.Println("Done")
}

昨天在检查新上线的系统时发现了大量的 replacement transaction underpriced 错误。google了一下，ETH这个错误的意思是gas price太低了，主要可能性是nonce重复了，一个新增交易于是变成了一个更新交易，而更新交易需要比老交易更高的gas price，但在私链上通常一个固定的操作gas price都是一致的。
但nonce为什么会重复呢?

nonce, err := client.PendingNonceAt(context.Background(), myaddress)

查了文档，PendingNoceAt它是根据当前的链的高度和用户地址来生成的，换句话说，同一个用户多个交易试图打包在同一个区块中，PendingNonceAt就会重复。
再看一下更详细的日志，马上就明白了错误出现的原因。大概是前端有bug，它在发起一个建立用户的操作时，在毫秒级重复发起了几次，所以，只有第一次成功，后面全部失败，不过这个失败在功能上是无所谓的，只是重复的操作失败了。
一下理解了另一个系统的同样的问题，当时一直找不到答案，就是在一个批量的链操作时，如果超过了10次/秒，就会随机性的出现失败，为解决问题我只能把它强行限制在5次/秒。 现在知道了，那是因为链的性能，在高于10次每秒时，就会出现几个交易打包在了一个区块中引发nonce问题。