光の技术屋

前言

提起中国的lua产品，就不得不想到skynet，一款针对游戏，但又不仅限于游戏的服务端架构。skynet充分利用了lua的特性，并且在此基础上易扩展HTTP、HTTPS、WebSocket等模块，因此由skynet入手理解lua原理以及服务端架构是一个非常不错的选择。

通过skynet，我们可以构建许多小巧而高性能、高可用的应用。废话不多说，让我们一起来探索skynet架构吧~

skynet通信原理与源码分析

服务端架构中，不同子服务的通信调度是核心功能。因此，我们以单点（standalone）的skynet实例为例，由外而内，逐步剖析。

要介绍skynet的通信原理，首先要提到lua中的一个概念——lua_State。lua_State是lua的运行时（runtime），是一个原生隔离的、高性能的运行环境，若在多核并行运行lua_State，其性能一定不会差。lua作为嵌入式语言，以C为基础，可以实现操作系统粒度级的lua_State调度，因此skynet也就如同lua_State管理器一样了。

每一种业务可以看作一个service，而每一个service中，都会有一个lua_State充当执行业务逻辑的环境。举个例子，在实际开发当中，比如做一个HTTP服务的话，我们需要自己预先配置好的skynet service主入口lua文件中，写上skynet.uniqueservice("app")启动一个独特的名为app的服务，而后在其中的逻辑中，根据每一个HTTP连接，解析其中的数据包。并调用skynet.newservice动态创建单独的上下文服务ctx来处理这个请求。ctx服务还有可能需要查询数据库中的数据，并返回结果，因此我们可能还需要通过skynet.uniqueservice("db")预先创建数据库服务db二次封装skynet内置mongo、mysql库的功能，然后再通过skynet.call来与db服务通信，获得db服务某个函数执行的返回结果，再在ctx服务的处理逻辑中写入HTTP Response，从而完成整个处理过程。在这一过程中，具体业务逻辑的处理都会在各个service所拥有的lua_State中运行，但调度通信的逻辑，则就是底层的活了。

因此在skynet底层中，不仅需要支持多个lua_State的运转，而且相对更有挑战性的是，如何让service之间能够相互交流。为了解决这个问题，我们可以看到，在底层中，每一个service都属于snlua类型。snlua除了包括自己的lua_State之外，还维护了一个称之为context的运行状态：

最近小包装了一下Easy Python系列，放到语雀上整合精编了个pdf投放，完成Easy Python系列的最后一项任务。

第一次编撰一个短篇技术系列，小有成就，值得鼓励。但路还有很远，慢慢来吧~

传送门如下：

• 百度网盘

用hexo+NexT搭建博客的同学或许会遇到一个问题：默认的代码配色只有Tomorrow Theme五种，如果想要自己的代码配色，应当如何自定义呢？

其实也是可以的。在NexT的source/css/highlight/theme.styl中，我们就可以看到几种主题的具体配色：

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

$highlight_theme = hexo-config("highlight_theme")

if $highlight_theme == "normal"
  $highlight-background   = #f7f7f7
  $highlight-current-line = #efefef
  $highlight-selection    = #d6d6d6
  $highlight-foreground   = #4d4d4c
  $highlight-comment      = #8e908c
  $highlight-red          = #c82829
  $highlight-orange       = #f5871f
  $highlight-yellow       = #eab700
  $highlight-green        = #718c00
  $highlight-aqua         = #3e999f
  $highlight-blue         = #4271ae
  $highlight-purple       = #8959a8
  $highlight-gutter       = {
    color: #869194,
    bg-color: #eff2f3
  }

if $highlight_theme == "night"
  $highlight-background   = #1d1f21
  $highlight-current-line = #282a2e
  $highlight-selection    = #373b41
  $highlight-foreground   = #c5c8c6
  $highlight-comment      = #969896
  $highlight-red          = #cc6666
  $highlight-orange       = #de935f
  $highlight-yellow       = #f0c674
  $highlight-green        = #b5bd68
  $highlight-aqua         = #8abeb7
  $highlight-blue         = #81a2be
  $highlight-purple       = #b294bb
  $highlight-gutter       = {
    color: lighten($highlight-background, 50%),
    bg-color: darken($highlight-background, 100%)
  }

...

我们可以看到其实如果要增加一个自定义主题的话，其实加一段if跟其配色，然后在配置里配置theme的关键词就好了。那么自己配色的话应该怎样参考呢？我们可以在source/css/highlight/highlight.styl中找到答案：

在从零单排Golang第一话中讲到了Golang的基础开发环境配置，其中讲到了Go的依赖管理方面，提及了以后的趋势会采用官方的go mod进行管理。关于这一块，现在有了更加简单的方法。

最新的Go1.13中已经将go mod列为默认的包管理方法，但国内用户go mod vendor时还是有可能会出错，这是因为在go get时会检查哈希值，需要访问官方的sumdb。由于众所周知的不可抗因素，sumdb没法直接访问，这样就会造成下载依赖失败。解决的方法也很简单，只需要一行终端命令即可：

1

go env -w GOPROXY=https://goproxy.cn,direct

如果采用idea+Go插件开发的话需要注意，idea可能会托管环境变量，这个时候需要进入settings, languages & frameworks, go, go modules里，设置proxy为https://goproxy.cn,direct，就ok了。

前言

Github传送门

提起Golang，就不得不提起kubernetes，在崇尚上云的今天，kubernetes已成为服务端同学必需掌握之学问。在第三话中，我们介绍了docker容器，它相当于虚拟操作系统，可以提供环境供各种不同的应用运行，从而实现轻量部署。但要是业务复杂，需要部署较多应用的话，就会遇到许多运维相关的问题，比如：

• 应用关联的资源很多都需要持久化存储，它们的存储空间需要怎样分配及调度呢？
• 不同地域的应用，如何取得相互联系？
• 在应用集群中，如果有一个子应用挂了，该怎么办？
• 。。。

这些问题，单靠docker是解决不了的（也不是docker所要关心的），需要在docker的基础上做更高层次的运维平台才能解决，而kubernetes，就是方案之一。复杂的调度逻辑，都会由kubernetes负责，而运维开发人员则基本只需向kubernetes提供资源及其描述，就能满足运维需求，从而提升工作效率。

既然准备入坑，就需要强行踩下去，因此今天就试试“家中上云”，单机搭建kubernetes，部署一个mongodb数据库。废话不多说，咱们开始吧~

minikube——在Win10本地搭建kubernetes

前言

上周电脑突发极其奇怪的bug，启动了不到一会儿CPU阻塞，所有程序打不开，安全模式查毒、修复系统、清存储卸软件均没有获得较好的效果。因此索性重装了Windows，所有一切推倒重来。

既然推倒重来，那CSGO就是不得不装的一款游戏。CSGO到现在也有10年的历史了，然而在网上能搜到的游戏优化设置要么过时，要么没有详尽的整合。因此，本文章借着装机经验，整理了自己优化CSGO的历程~

由于笔者为Win10+N卡，因此在Linux/Mac以及非N卡下玩CSGO的同学，部分配置还需另行google~

Win10游戏设置

运行在Win10的游戏需要关闭Win10自带的游戏优化与配置

首先关闭XBox自带的DVR（游戏内录像之类），有很多种方法，这里通过注册表方式解决：

前言

rpc（远程过程调用），是不同主机间的交互的机制之一。好比说，我们想要获取服务器的某个资源，我们就可以发送一条讯息给服务器，然后服务器解析信息，再返回推送资源的信息，这样，便实现了我们客户端跟服务器的相互的“远程调用”。

为了让不同主机之间能够相互理解发送的讯息，我们需要约定统一的信息格式标准，使得不同的主机可以发送基于这个信息格式的讯息，也可以解析这个格式。这种标准，我们称之为协议（protocol）。

Lua中协议选择有许多种，protobuf、json均可。但是今天，就稍微介绍一下云风同志当年为lua量身设计的sproto协议以及其用于协议测试的二次开发。So, let the party begin~

sproto协议描述

sproto是专用于lua的协议框架，相对于protobuf跟json，sproto在数据的序列化/反序列化效率上有极大的优势。rpc中为了快速效率地传送协议数据，会将数据组装压缩发送，接收端再解压拆解数据识别消息，从而减小了网络传输的开销。这个数据处理过程便可称之为序列化/反序列化。

sproto的设计类似于protobuf，基本类型为string、binary、integer以及boolean四种。对于array序列的支持，则加上引用星号*即可；对于非整数的支持方面，用户可以parse string来处理实数，或者指定integer的小数位数来处理小数（decimal）。除此之外，用户也可以像编程里面strcut那样自定义类型，类型与类型之间也可以嵌套。

我们可以从readme中寻找各种例子。数据类型的例子如下：

前言

Github传送门

最近回忆起了在学校那会儿趣事：刚开始上数据库原理课程，一开始装Microsoft SQL Server，全班同学都在吐槽，怨声载道——这个说数据库咋启动不了，那个说数据库咋卸载不干净，个个焦头烂额，实在是好一番风景。唉，那时候就在想，要是有一个类似于软件管家的东西托管Microsoft SQL Server，让我们一键安装/卸载，可不就好了。

进入工业界，接触了运维方面的知识，才了解到docker的存在。不同于当年常用的虚拟机软件（VMWare WorkStation），docker并未对操作系统的硬件支撑做虚拟化，只是操作系统的进程，但却模拟了一个操作系统的环境，因此相对于虚拟机而言，docker更加轻量。轻量的运行环境意味着基于docker的部署，在管理与调度上会更加容易。看，kubernetes！

再回到我们的学习生活，拿MySQL为例吧——有了docker，安装卸载MySQL，就会变得无比容易。首先docker pull mysql；而后整理一下配置——通过-v映射数据在本地的存储路径，通过-p暴露出来mysql容器的端口，通过-e设置MySQL密码等环境变量；之后docker run带上上面的设置，我们的MySQL就启动了！要彻底卸载的话，只需要三行命令：docker stop ${MySQL容器ID}、docker rm ${MySQL容器ID}与docker image rm ${MySQL镜像ID}，就ok了，是不是EZPZ？

正好，docker是基于Golang编写。因此本期从零单排，我们就用Golang来挑战一下如何与docker交互吧~

编写Golang程序部署MySQL

首先，我们研究一下相关的技术栈：官方提供的Golang客户端库docker client为Golang与docker间搭建了桥梁，其实质是对docker engine api的抽象；而docker engine api实质则是一个HTTP后端，是对docker内部镜像与容器管理功能的抽象。

通过docker client库，我们只需关心相关的参数输入。库中的方法会自动拼装参数，发送至docker engine api，从而实现交互。docker client的一些小例子，可以参考这里。

接下来，我们必须研究一下，要部署MySQL容器，需要有哪些步骤：

前言

提到lua，就不得不提协程coroutine。coroutine是lua的一种内在机制，为lua提供了原生的异步支持。从用户层面来看，用户不需关心coroutine的内在实现，而只需要用coroutine调度function即可，因此非常方便。

对于一个function而言，coroutine可以将function的代码分片，使得一个function可以分阶段运行。在实现上，function的状态管理会与CPU的机制相似。如果把一个function当做一个任务来看待的话，在coroutine的封装下，这个任务会被分解成多个阶段的子任务。这样，我们就可以把多个任务的子任务相互协调调度，实现更加灵活的功能交互。

因此，本期Lua杂谈，就来小试一抔coroutine的使用吧。

coroutine的基本用法

官方5.3.5版本的coroutine库，提供了如下的接口：

1
2
3
4
5
6
7
8
9
10
11

// lcorolib.c
static const luaL_Reg co_funcs[] = {
  {"create", luaB_cocreate},
  {"resume", luaB_coresume},
  {"running", luaB_corunning},
  {"status", luaB_costatus},
  {"wrap", luaB_cowrap},
  {"yield", luaB_yield},
  {"isyieldable", luaB_yieldable},
  {NULL, NULL}
};

用户可以通过coroutine.wrap与coroutine.create两种方式封装一个function（任务）。通过wrap封装任务会返回一个纯粹的lua函数（type为function），而用create封装则返回的是一个封装好的线程。

在Lua中，线程thread与协程coroutine的概念内涵有较多相似之处，但我们可以认为，线程是更加宏观广泛的概念，协程则是一种特殊的线程。线程强调的不同的routine之间运行是否独立；而协程强调的则是不同routine之间具有相互co的协作功能。

基于这两种方式调度任务的代码写法大同小异。以下以create封装任务为例，我们一起看看会是怎样的进行——

我们的日常生活离不开手机，有些同学喜欢用国产的安卓机，而另一些同学喜欢用简约的iPhone。

对比安卓和iOS的软件生态，我们可以发现：安卓软件的投放渠道繁多，题材花样繁复，质量大小不一，而iOS的投放渠道则为App Store独家，相对安卓软件来讲，不仅质量均衡，而且用户不必担心手机病毒的困扰。这一点，就归功于App Store严格的审核制度。