kvstore: 时序数据key-value存储引擎

chrislee 发表了文章 • 3 个评论 • 62 次浏览 • 21 小时前 • 来自相关话题

接触Go语言挺久了,看过不少开源项目,只是工作中用Go做开发的机会不多。kvstore起源于之前一个C++项目,对其功... 查看全部

接触Go语言挺久了,看过不少开源项目,只是工作中用Go做开发的机会不多。kvstore起源于之前一个C++项目,对其功能简化后用Go重新实现。
工作中主力开发语言是C++,写过少量的Node、Python和PHP,不管是从编程语言排行榜还是国内外很多案例来看,越来越多的公司从Python、Ruby、Node、Scala等开发语言转向Go。
用Go写代码还是很爽快的,当然泛型的缺失导致难免会有一些duplicate code。

#开源项目#wechat-go 微信机器人/web协议

songtianyi 发表了文章 • 4 个评论 • 158 次浏览 • 2017-04-17 16:03 • 来自相关话题

地址: https://github.com/songtianyi/wechat-go

最近改进了两点

地址:
https://github.com/songtianyi/wechat-go


最近改进了两点



  • 支持多开

  • 插件化


目前的插件


switcher


一个管理插件的插件


#关闭某个插件, 在微信聊天窗口输入
disable faceplusplus
#开启某个插件, 在微信聊天窗口输入
enable faceplusplus
#查看所有插件信息, 在微信聊天窗口输入
dump

faceplusplus


对收到的图片做面部识别,返回性别和年龄


gifer


以收到的文字消息为关键字做gif搜索,返回gif图, 注意返回的gif可能尺度较大,比如文字消息中包含“污”等关键词。


replier


对收到的文字/图片消息,做自动应答,回复固定文字消息


欢迎来开发更多的功能插件,然机器人变得丰富有趣,另外急需一个前端朋友开发两个页面(类似微信网页版扫码页面,插件开关页面)
参见项目 go-aida

Go 语言跨平台 GUI 自动化系统 (模拟鼠标键盘和控制 bitmap 窗口以及屏幕以及全局事件监听)

veni 回复了问题 • 15 人关注 • 15 个回复 • 1884 次浏览 • 2017-04-06 16:07 • 来自相关话题

分享一个小工具 Boast:如何从服务端跟踪所有 HTTP 请求,并方便回放?

dcb9 发表了文章 • 0 个评论 • 183 次浏览 • 2017-03-31 16:17 • 来自相关话题

原文链接:http://blog.phpor.me/note/2017/03/31/track-and-replay-http-request.html
客户端工程师:“xxx 接口坏了,我的程序都没动过”,后端经常会收到这样的质问,但是我们现在如何重现这个问题?有以下几种情况:


一、后端测试了一下发现没有问题


“我这里测试了是好的啊”,就只能让客户端工程师再操作一遍,亲眼看到错误之后就肯定是有问题了,就得去找问题,这时候这台手机,以及这台手机里面的数据都非常重要,因为这些数据可以让 Bug 重现。


二、测试了也有问题


这时候后端就去修改程序了,但是每一次的测试是否有问题都需要在客户端中操作,有时候的操作非常的复杂,在这上面花的时间会比较多。最后使了各种神通才终于找到问题,原来是这个用户的某某数据有异常才会出现这种情况。


以上这种情况屡见不鲜,最麻烦的点就在于,每次都要以出现 Bug 的相同参数去请求,有时候你知道这些请求的参数,可以把它们放到 Postman 这种工具里面,但大部分时候你并不知道它对应的参数 (token)


如果我们可以在服务端跟踪所有的请求:接口地址,Header,Body,后端返回的 Header、Body,这样我们就能查到对应的请求参数和返回值,可以直接填到 Postman 里面,要是还能一键重新请求就好了,因为我们不想修改请求的参数,只是想再以相同的参数请求一遍,这样我们来调试对应的程序。


正好以前用过 ngrok,发现它有一个非常好的 debug 界面,可以达到以上的要求,但现在不需要它的内网穿透功能,于是只能自己写一个程序,只包含以下功能:



  • 记录接口所有的 Request 和 Response

  • 可以一键重新请求某个 Request


基本工作原理


HTTP 客户端                   Boast                       Web 服务器
| GET http://localhost:8080/ | 记录请求并进行反向代理 | Response 200 OK
| ---------------------------> | --------------------------> | ------┐
| | | |
| | 记录返回信息并转发给客户端 | <----┘
| <--------------------------- | <-------------------------- |

┌----------------------------------------------------------------------------┐
| url: http://localhost:8081 |
| ---------------------------------------------------------------------------|
| All Transactions ┌ - - - - - - - - - - - - - - - - - - - - - - - ┐ |
| ---------------------- | time: 10 hours ago Client: 127.0.0.1 | |
| |GET / 200 OK 100 ms | | | |
| ---------------------- | Request [ Replay ] | |
| | - - - - - - - - - - - - | |
| | GET http://localhost/ HTTP/1.1 | |
| | User-Agent: curl/7.51.0 | |
| | Accept: */* | |
| | | |
| | Response | |
| | - - - - - - - - - - - - | |
| | HTTP/1.1 200 OK | |
| | X-Server: HTTPLab | |
| | Date: Thu, 02 Mar 2017 02:25:27 GMT | |
| | Content-Length: 13 | |
| | Content-Type: text/plain; charset=utf-8 | |
| | | |
| | Hello, World | |
| └ - - - - - - - - - - - - - - - - - - - - - - - ┘ |
| |
└----------------------------------------------------------------------------┘

最近正在学习 Go,正好拿它来完成这个小程序,取名为 Boast 为了让我们在重现 Bug 上更为主动和方便,以及更快地修复,好多花点时间来造轮子!


Boast 项目地址


Go 和前端都是现学现卖,欢迎大家拍砖。

基于 Gin 的 Go 前端组件化 web 框架

veni 回复了问题 • 3 人关注 • 2 个回复 • 434 次浏览 • 2017-03-23 14:49 • 来自相关话题

beego1.8的文档还没更新么?

回复

kaixinmao 发起了问题 • 1 人关注 • 0 个回复 • 260 次浏览 • 2017-03-23 10:31 • 来自相关话题

实时现在毫秒时钟 RTClock

Akagi201 发表了文章 • 7 个评论 • 273 次浏览 • 2017-03-22 12:46 • 来自相关话题

找了很久, 没有找到一个在线可用的毫秒时钟. 自己用 websocket 写了一个.

https://github.com/Akagi201/rtc... 查看全部

找了很久, 没有找到一个在线可用的毫秒时钟. 自己用 websocket 写了一个.


https://github.com/Akagi201/rtclock


rtclock



An HTML5 Real Time Clock based on WebSocket



rtclock


Features



  • [x] Use WebSocket to send backend real time clock to frontend.

  • [x] Support go-bindata.


Install



  • go get github.com/Akagi201/rtclock


Build



  • ./gobin.sh (when you modified the html template)

  • go build


Run



  • ./rtclock -h

  • Simple usage: ./rtclock

请问有没有比较好的分布式系统监控项目?

hacpai 回复了问题 • 4 人关注 • 2 个回复 • 325 次浏览 • 2017-03-10 22:40 • 来自相关话题

Gitea 发布 v1.1 版本,支持Git-LFS,两步验证,MSSQL,Github登录等大量改进

lunny 发表了文章 • 0 个评论 • 236 次浏览 • 2017-03-10 10:20 • 来自相关话题

我们很高兴的宣布Gitea 发布了 1.1.0 版本。在这个版本中,我们关闭了 查看全部

我们很高兴的宣布Gitea 发布了 1.1.0 版本。在这个版本中,我们关闭了 126 工单,同时合并了 348 合并请求。你可以从 下载页面 根据你所处的平台和架构下载预编译版本。更多安装详情请参考 安装向导



Changelog



  • BREAKING

    • The SSH keys can potentially break, make sure to regenerate the authorized keys


  • FEATURE

    • Git LFSv2 support #122

    • API endpoints for repo watching #191

    • Search within private repos #222

    • Hide user email address on explore page #336

    • Protected branch system #339

    • Sendmail for mail delivery #355

    • API endpoints for org webhooks #372

    • Enabled MSSQL support #383

    • API endpoints for org teams #370

    • API endpoints for collaborators #375

    • Graceful server restart #416

    • Commitgraph / timeline on commits page #428

    • API endpoints for repo forks #509

    • API endpoints for releases #510

    • Folder jumping #511

    • Stars tab on profile page #519

    • Notification system #523

    • Push and pull through reverse proxy basic auth #524

    • Search for issues and pull requests #530

    • API endpoint for stargazers #597

    • API endpoints for subscribers #598

    • PID file support #610

    • Two factor authentication (2FA) #630

    • API endpoints for org users #645

    • Release attachments #673

    • OAuth2 consumer #679

    • Add ability to fork your own repos #761

    • Search repository on dashboard #773

    • Search bar on user profile #787

    • Track label changes on issue view #788

    • Allow using custom time format #798

    • Redirects for renamed repos #807

    • Track assignee changes on issue view #808

    • Track title changes on issue view #841

    • Archive cleanup action #885

    • Basic Open Graph support #901

    • Take back control of Git hooks #1006

    • API endpoints for user repos #1059


  • BUGFIXES

    • Fixed counting issues for issue filters #413

    • Added back default settings for SSH #500

    • Fixed repo permissions #513

    • Issues cannot be created with labels #622

    • Add a reserved wiki paths check to the wiki #720

    • Update website binding MaxSize to 255 #722

    • User can see the private activity on public history #818

    • Wrong pages number which includes private repositories #844

    • Trim whitespaces for search keyword #893

    • Don't rewrite non-gitea public keys #906

    • Use fingerprint to check instead content for public key #911

    • Fix random avatars #1147


  • ENHANCEMENT

    • Refactored process manager #75

    • Restrict rights to create new orgs #193

    • Added label and milestone sorting #199

    • Make minimum password length configurable #223

    • Speedup conflict checking on pull requests #276

    • Added button to delete merged pull request branches #441

    • Improved issue references within markdown #471

    • Dutch translation for the landingpage #487

    • Added Gogs migration script #532

    • Support a .gitea folder for issue templates #582

    • Enhanced diff-view coloring #584

    • Added ETag header to avatars #721

    • Added option to config to disable local path imports #724

    • Allow custom public files #782

    • Added pprof endpoint for debugging #801

    • Added X-GitHub-* headers #809

    • Fill SSH key title automatically #863

    • Display Git version on admin panel #921

    • Expose URL field on issue API #982

    • Statically compile the binaries #985

    • Embed build tags into version string #1051

    • Gitignore support for FSharp and Clojure #1072

    • Custom templates for static builds #1087

    • Add ProxyFromEnvironment if none set #1096


  • MISC

    • Replaced remaining Gogs references

    • Added more tests on various packages

    • Use Crowdin for translations again

    • Resolved some XSS attack vectors

    • Optimized and reduced number of database queries


召集:grpc服务docker化,给API-GATEWAY写example

donaduo 回复了问题 • 3 人关注 • 3 个回复 • 470 次浏览 • 2017-03-09 00:08 • 来自相关话题

Golang 的框架或者包有听说过有漏洞的么?

astaxie 回复了问题 • 2 人关注 • 1 个回复 • 474 次浏览 • 2017-03-07 13:00 • 来自相关话题

用google/gops诊断Golang程序

myml 发表了文章 • 1 个评论 • 249 次浏览 • 2017-03-04 22:55 • 来自相关话题

在github上发现一个有趣的程序。 google/gops可以列出本机正在运行的Go程序,并诊断程序,可以查看程序的堆栈,... 查看全部

在github上发现一个有趣的程序。
google/gops可以列出本机正在运行的Go程序,并诊断程序,可以查看程序的堆栈,运行时等信息
只需要在程序里加入github.com/google/gops/agent包,一个简单的例子


// gopsTest project main.go
package main

import (
"log"
"time"

"github.com/google/gops/agent"
)

func main() {
if err := agent.Listen(&agent.Options{}); err != nil {
log.Fatal(err)
}
time.Sleep(time.Hour)
}

➜  bin gops
8548 gops (/home/myml/src/go/bin/gops)
8302* gopsTest (/tmp/gopsTest)

➜  bin gops memstats 8302
alloc: 194.63KB (199304 bytes)
total-alloc: 194.63KB (199304 bytes)
sys: 1.66MB (1740800 bytes)
lookups: 9
mallocs: 1182
frees: 67
heap-alloc: 194.63KB (199304 bytes)
heap-sys: 704.00KB (720896 bytes)
heap-idle: 136.00KB (139264 bytes)
heap-in-use: 568.00KB (581632 bytes)
heap-released: 0 bytes
heap-objects: 1115
stack-in-use: 320.00KB (327680 bytes)
stack-sys: 320.00KB (327680 bytes)
next-gc: when heap-alloc >= 4.27MB (4473924 bytes)
last-gc: -
gc-pause: 0s
num-gc: 0
enable-gc: true
debug-gc: false

也可以远程诊断


➜  bin gops stats 127.0.0.1:41861
goroutines: 6
OS threads: 9
GOMAXPROCS: 4
num CPU: 4

更多的命令


Usage: gops is a tool to list and diagnose Go processes.

Commands:
stack Prints the stack trace.
gc Runs the garbage collector and blocks until successful.
memstats Prints the allocation and garbage collection stats.
version Prints the Go version used to build the program.
stats Prints the vital runtime stats.
help Prints this help text.

Profiling commands:
trace Runs the runtime tracer for 5 secs and launches "go tool trace".
pprof-heap Reads the heap profile and launches "go tool pprof".
pprof-cpu Reads the CPU profile and launches "go tool pprof".

All commands require the agent running on the Go process.
Symbol "*" indicates the process runs the agent.

搞了个解析 redis rdb 文件,分析 redis 内存分布的小工具

iddmx 发表了文章 • 2 个评论 • 179 次浏览 • 2017-03-02 18:28 • 来自相关话题

https://github.com/xueqiu/rdr

基于这个小工具改改很容易就做出一个离线自动化分析 redis 使用情况的内部系统,想搞的同学...

https://github.com/xueqiu/rdr


基于这个小工具改改很容易就做出一个离线自动化分析 redis 使用情况的内部系统,想搞的同学可以拿去试试

Golang API 业务监控项目求大神指点

tkk 回复了问题 • 2 人关注 • 1 个回复 • 327 次浏览 • 2017-03-02 16:40 • 来自相关话题

mqant分布式服务器框架设计动机

liangdas 发表了文章 • 1 个评论 • 331 次浏览 • 2017-02-28 17:49 • 来自相关话题

2016年底的时候对即时通讯以及游戏开发产生了一些兴趣,而且自己这方面的知识掌握也非常少,在未来很多产品应该都会使用到长连接技术(物联网IOT),因此很有必要掌握这方面的技术。于是就在网络上查询相关的资料,但发现目前网络上的开源游戏服务器框架相对较少,而... 查看全部

2016年底的时候对即时通讯以及游戏开发产生了一些兴趣,而且自己这方面的知识掌握也非常少,在未来很多产品应该都会使用到长连接技术(物联网IOT),因此很有必要掌握这方面的技术。于是就在网络上查询相关的资料,但发现目前网络上的开源游戏服务器框架相对较少,而目前市面上已有的一些开源游戏框架又不太对自己的胃口。正好17年初刚回公司的时候事情比较少,就抽时间按照自己对游戏服务器的架构思路做了一套,取名就叫mqant了,现在已经发布到Github上,欢迎大家Fork mqant开源框架


为什么决定要重新造一个轮子?


目前网上优秀的开源游戏服务器框架也不少(当然与web框架比起来就少太多了),但总结起来都各有各的优缺点,下面列出我在选型过程中的一些考量,希望大家能开放的讨论,有不恰当的地方也请指正。


首先是开发语言


目前用于游戏服务器开发的主要应该有以下这些语言:




  1. c/c++


    优点:


    性能很好


    缺点:


    不过我个人不会C++


    开源框架:


    skynet
    底层是C 开发语言是lua,
    没有客户端库

    kbengine
    底层是C++ 开发语言可以使用C#,Python
    有多个平台的客户端库



  2. C#


    优点:


    性能很好


    缺点:


    不过我个人不会C#


    开源框架:


    Scut
    底层C# 开发语言是 C#、Python和Lua多种脚本进行开发
    有多个平台的客户端库

    Photon
    底层C# 好像是收费的,但毕竟出名
    有多个平台的客户端库



  3. python


    是我最想使用的一种开发语言



    1. 开发效率非常高

    2. 支持协程,能开发出高并发性的游戏,而且代码可读性好

    3. 目前有很多游戏公司应该都使用的是Python作为后端游戏服务器开发语言,有相对成熟的案例


    缺点:



    1. Python很致命的一个问题是进程不能利用多核,也就是说一个进程只能利用一个CPU进行计算,如果要用多核就需要新开进程,这样会造成服务器的维护成本增加,而且开发项目时所需要考虑的问题也更多


    开源框架:


    twisted  可以用来做网关服务器
    firefly 应该很早就不维护了



  4. java



    1. 没有找到比较好的开源框架

    2. 对协程支持不够好

    3. 开发效率较低




  5. javascript


    优点:


    1. 语法灵活(这是一把双刃刀,用起来要小心,尤其是团队开发中)
    2. 开源库丰富

    缺点:


    1. 语法上有一些缺陷
    2. 跟Python一样不支持多核
    3. 对协程支持不够好,地狱回调很可怕,虽然有一些解决方案,但用起来稍微有点别扭

    开源框架:


    Pomelo 网易出的,安静了一段时间,最近又开始维护了
    有多个平台的客户端库



  6. golang


    优点:


    1. 性能好,跟C/C++/C#一样编译型语言
    2. 语法比较简单,开发效率也比较高,接近Python
    3. 语言级别支持协程
    4. 单进程支持多核并发计算

    缺点:


    1. 开源库较少,会golang的开发者比较少

    开源框架:


    leaf        接触的第一个golang框架,设计不错,但不支持多进程
    没有客户端库,需要自己实现
    cellnet 刚接触,没法评价,但好像它用了callback回调函数的设计,这样的设计在golang应该可以避免



游戏框架的不足


结合个人的实际情况,当时我主要的选择从 skynet Pomelo leaf 这三个框架里面来选择


skynet设计思路非常牛逼,看了风云大牛的设计感觉应该是一个高性能,高稳定性的游戏服务器框架,而且有很多产品已经使用上了。
但个人认为skynet可能也会有以下的两个问题



  1. Actor模式可能对架构能力比较高,不如rpc模式明了

  2. skynet使用第三方网络库的时候可能需要造轮子,要放开膀子开发有些难,跟python tornado的一样,要写出高性能的程序也对开发人员有一定的要求


Pomelo由网易团队开发的,对多进程架构做的非常好,不过由于javascript性能的关系Pomelo的定位也在一些中小型非即时战斗类游戏,经过一段时间的学习和测试,最后还是无奈放弃了


最后经过多方考虑,我选择golang作为开发语言,当时第一个接触的就是leaf,学习开发了一段时间发现了leaf的一些不足



  1. 不支持多进程

  2. 没有客户端开发库,需要自己造轮子


上面列出来的都是这几个框架的缺点,其实这几个框架都非常优秀,只是不同的需求有不同的要求罢了,希望大家能根据自己实际需求选择最适合自己的框架


对游戏服务器框架的想法


自己心里也对游戏服务器框架有一些自己的想法,最终决定造这个轮子。




  1. 高性能,支持多核


    这在未来开发,扩展,维护会轻松很多,比如Python这样一台服务器跑上百个进程的游戏服务器,维护起来就很让人头疼




  2. 支持协程


    协程在客户端中应用不大,但在服务器开发中可以发挥极大的威力:



    1. 高并发,能最大的利用cpu资源

    2. 异步开发同步化,免去了回调函数设计,避免了地狱回调




  3. 支持分布式,但也支持单进程部署


    有些框架写一个demo都需要启动多个进程,实际上在项目前期可能一台服务器就能够支持了,我希望实现一个既可以单进程部署又可以分布式部署的框架



    1. 单进程能够实现高性能

    2. 分布式部署不用重新设计编码


    这个需求的实现主要靠约定,只要开发的时候按分布式环境来开发,代码一般都不需要移植




  4. 有丰富的客户端开发库


    让开发者专心业务开发,不同再去造轮子了




mqant框架的架构


mqant就是按照以上的思路设计的,同时设计思路上参考了Pomelo,并且也使用了leaf框架的部分代码。



  1. golang本身支持高性能,支持多核


  2. 支持协程
    因此mqant的RPC通信都可以按同步来写, 例如:


    //远程调用 Login模块的getRand方法
    result,err:=m.RpcInvoke("Login","getRand",roomName)
    if err==nil{
    //getRand 调用成功了,再做下面的远程调用
    result,err:=m.RpcInvoke("Login","getName",roomName)
    }
    //上面的调用都执行完了才执行下面的代码
    ....

    result 是远程调用成功以后的返回值
    err 是远程调用失败的信息

    以上代码非常清晰,跟普通的函数调用基本一样,但如果用回调函数的话,如下:

    m.RpcInvoke("Login","getRand",roomName,func(result string,err string){
    if err!=nil{
    m.RpcInvoke("Login","getName",roomName,func(result string,err string){
    //调用都执行完了才执行下面的代码
    })
    }
    })
    ...



  3. 支持分布式,但也支持单进程部署


    mqant是按模块为单位来划分功能模块的,可以将一组模块放到一个进程来运行,也可以将所有模块放到同一个进程来运行(即单进程模式)


    mqant模块间约定按标准的RPC来相互调用


    RPC底层分两种模式


    1. 基于golang chan的单进程通信
    2. 基于rabbitmq的跨进程通信

    RPC会根据模块间的部署情况选用适当的通信方式,以达到在单进程模式下RPC通信的最低性能损耗和最快的响应时间




  4. 有丰富的客户端开发库


    mqant没有考虑帮开发者造一个客户端开发库,而是选用了目前物联网中非常流行mqtt协议来作为通信协议,mqtt本身就有各个平台的客户端开发库,因此可以直接用mqtt的客户端开发库对接到mqant上来。实现了mqant跨平台通信的要求




总结


mqant还是一个非常新的框架,有很多地方都不完善,但我相信有更多大牛的加入进来参与完善和优化的话,mqant框架将变得更好。