Newsletter电报频道微信公众号

Serverless与Web后端天生不合?

Serverless/Faas/BaaS 等概念在这几年的技术圈中是绝对的热点词汇之一,国内外众多云厂商也纷纷推出自家的 Serverless 和函数计算产品,微信也依托腾讯云推出了基于 Serverless 和 FaaS 理念的「小程序·云开发」,对应的新型岗位也不断涌现。

如今,我们确实看到很多中小型业务在拓展新领域、开发新功能时会优先考虑使用 Serverless 产品作为后端架构基建,但却鲜有见到面向 C 端的一线大厂中,有核心业务在 Web 后端层面改为采用 Serverless 作为开发模式,这又是何缘由呢?

Antilibrary能拯救稍后不读吗

从「稍后再读」到「再也不读」

上学时,我有一套自认为很高效的资料搜集工作流。大致流程是浏览到感兴趣或可能有用的信息时,粗略扫过一眼后即用 Pocket 将其保存为稍后再读,随后借助 IFTTT 的某个自动化 applet 即可将添加到 Pocket 中的文章内容整体自动同步至 Evernote 中。这样一来我便可以在以后有时间的时候再到 Pocket 中详细阅读这篇文章,而 Evernote 也充当了持久化的数据库角色,永久保存这篇文章以备后用。

然而理想很丰满,现实很骨感。由于人类的常见病——「拖延症」,我时常将一篇文章保存到 Pocket 后一两周都懒得去细读研究。这样一来,仅仅一年多的时间, Pocket 中就堆积了几百篇的待阅读文章,粗略计算了下我可能需要夜以继日地花费一周时间才能消灭掉所有的未读小红点,可是我连阅读一篇文章都时常拖延,这样沉重的沉没成本我又怎会有意愿去承担呢。

在阿里都不写周报的2021年,我却写起了个人周报

为什么我们反感周报

周报对于公司来说是管理流程的重要组成部分,对于直属领导来说能够归纳性地掌握下属当期的工作内容及核心项目的进展,对于部门领导来说可以通过几分钟的时间迅速了解麾下部门的运作情况,从定义和功能上来看周报都是很有效的总结和评估手段,那么为什么我们又如此反感周报呢?

人生苦短,快用双拼输入法

还记得小时候执拗地认为打字速度是证明计算机水平的硬通货所以一直想学下五笔,但每每看到那复杂的字根表时这个想法就不了了之了。其实除了五笔这种复杂的低重码率中文输入方案,双拼也是一种显著提升输入效率的选择。

什么是双拼

双拼是汉语拼音输入法的一种编码方案。相对于全拼而言,使用双拼输入汉字时只需输入一个代表声母的字母,一个代表韵母的字母,就可以打出任意一个中文单字了。

以上是中文维基百科对双拼一词的解释,简单来说双拼方案就是对全拼做了层映射,从而使得我们可以通过输入两个字母即可确定一个汉字。比起全拼通常需要输入 2~5 个字符才能确定一个汉字,双拼的输入的效率显然更高。 与五笔类似,市面上有许多种双拼方案,这些方案的基础理念与上文无异,但其声母、韵母和键盘的映射方案不尽相同且无法互通,因此用户需要斟酌选定一套方案来固定使用。

上手成本如何

学习过程:一小时记忆键位,一周习惯双拼节奏,一月恢复全拼时速度。

以上是小鹤双拼官网对其上手成本的描述。本人也选择了小鹤双拼方案,在花费了半个下午来熟悉和练习键位映射后,我便将所有设备的输入法均切换为了双拼。诚然,初期的使用中经常出现忘记映射、记错映射的情况进而影响输入效率,但在重度使用了五、六天后,整体的输入效率已与全拼无异。而从网友的反馈来看,大家也基本上能够通过不断使用而在一周内从感官上追平全拼的输入效率,因此小鹤双拼的这个描述其实还算保守。

基于腾讯云Serverless的HTTP服务探活函数

本文基于 Golang 开发了一款简单易用的 HTTP 拨测云函数,入口函数与腾讯云 Serverless SCF SDK 绑定。与目前腾讯云中默认的拨测函数不同的是, url-tester-func 支持将非 200 响应码作为预期值且通知机制由邮件变更为了 Telegram Bot 。使用者借助腾讯云提供的免费 Serverless 调用配额即可搭建一套简单的 HTTP 接口探活服务。

功能

  • 周期性探测指定 HTTP 地址是否可正常响应,并将非正常的探测结果发送至指定即时通讯工具的对话中以实现近乎实时地异步监控网站状态
  • 支持将 Telegram/Server酱 V1(微信)/Server酱 V2(微信)/Qmsg酱 (QQ,支持单聊及群聊)
  • 可识别的包含 Bot 信息的自定义 User-Agent (url-tester-func BOT)
  • 基于腾讯云 Serverless SCF ,部署简单且用量小时零成本(具体成本见下文费用说明)

项目地址

MrEasonYang/url-tester-func

使用

填写函数配置

首先需要根据腾讯云文档创建 Serverless 函数的配置文件, 可参照如下示例配合文档进行配置: serverless.yaml

构建

本地安装 Golang 并构建项目:

1
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build main.go

打通内外网互联的任督二脉

近几年家里陆陆续续购入了软路由和群晖 NAS 后,在家中的使用体验还不错,那么出门时又如何能无缝使用家中的服务呢?

如何在外网访问内网

对于外网访问内网的链路,我们通常称之为内网穿透,之所以是穿透,原因是目前大部分 ISP 并不会主动提供公网 IPV4 地址。虽然在部分地区可以与当地 ISP 沟通来获取,但住址变更、内网完全暴露后的安全问题也较为棘手。本人目前手上的宽带就没有提供公网 IPV4 地址,故需要通过一种穿透途径来打通内外网。(值得一提的是,截至 2021 年,很多 ISP 会主动提供公网固定 IPV6 地址,这也是一个可选方案,但据网友测评,目前国内 IPV6 的链路稳定性较差,所以还是实践才能出真知)。 目前常见的穿透方案大概有两类:

  • 一类是通过公网服务器与内网设备建立 TCP 长连,用户访问外网服务器时穿透程序会将流量通过之前建立的 socket 代理至目标内网设备上,由于是基于基础的 socket ,故每个转发关系都需要进行一次配置,即可以理解为内网 IP 和端口的排列组合,这种方案以 FRP 、NPS 和 Ngrok 为代表。
  • 另一类实际上实现了一种虚拟私用网络方案,外网服务器负责维护网关,用户请求时需要先使用客户端连接到对应网络。这类方案由于应用层的逻辑不同有许多种实现,而我们知道大部分企业也是通过这种方式来打通内外网的,下文提到的 Zerotier 也是这种方案的变种。 那么这两类方案应该如何进行选择呢?我的解决方式是两条腿走路:
  • 借助 FRP 对常用的内网服务进行代理,这样只要有浏览器即可访问这些服务,不要求设备必须装有客户端,非常灵活。
  • 另一方面建立基于 Zerotier 的私有网络,这样就不必为各种不常用的内网服务进行繁琐的 FRP 配置,同时像 SSH 、Windows 远程或 Git 服务等敏感、安全风险大的服务也无需直接暴露于外网之上。

内网穿透的前提条件

我们在内网直接访问各类内网服务的网络延迟是低于 1ms 的,但在公网上的耗时可就是几十毫秒起步了,此外,丢包率、带宽等问题也直接影响内网穿透的使用体验。所以选择一个链路稳定、带宽合适的公网服务器是非常有必要的。 这里提供几个选择方向做参考:

Podistributor播客分发系统介绍

一个基于 Golang 的播客分发程序。 Github Repo:MrEasonYang/podistributor

特性

  • 向用户暴露节目的别名 URL ,在用户访问时重定向至真实的目标资源 URL ,以高效地进行 CDN 切换和便捷地建立失效转移机制。
  • 异步转发请求至统计服务,以解耦用户请求和数据统计,可方便地接入多个数据统计服务或替换失效的统计服务。
  • 内建针对数据库的本地缓存层以提供高性能的服务并降低攻击流量带来的影响。
  • 内建基于 Prometheus 的监控和统计系统。

GIA线路VPS评测

最近折腾个新项目,原价入了某工的 LA GIA 线路机器,这么贵的机器自然是要简单测评记录下的。

图床服务的搭建思路

早年写过一篇关于常用图床的介绍,时过境迁,连当时最稳定的微博图床都已经不能简单地正常使用了。后来改用了一段时间 Github 图床,虽然一共没几张图片,但总感觉这是在滥用 Github 提供的免费服务,正好最近在折腾其他项目,干脆就自建了一个图床服务。这里就借机讲讲自建图床的思路。

图床的主要功能是图片的持久化存储和外部通过链接访问,由于图片的大小通常在几十 KB 到几 MB 不等,因此我们必须着重考虑以下几个因素:

SoftBank线路VPS评测

最近入手了个软银线路的某工的日本机器,此线路是联通友好线路,可惜机器低配高价,性价比很一般。 入手的主要原因是为了能给家里的 NAS 建立个稳定的穿透链路,由于宽带和移动网络使用的都是联通,所以其实整体体验还不错,这里贴一下相关测试,给大家个参考。