使用 Go 和 Let's Encrypt 快速配置HTTPS加密

Let's Encrypt 在2015年秋季推出了免费的数字证书认证计划,旨在消除当前手动创建和安装证书的复杂性,并推广加密的万维网服务,为安全网站提供免费的SSL/TLS证书。
Let's Encrypt 是由互联网安全研究小组(ISRG,一个公益组织)提供的服务。主要赞助商包括电子前哨基金会,Mozilla基金会,Akamai以及思科。2015年4月9日,ISRG与Linux基金会宣布合作。

用以实现这一新的数字证书认证机构的协议被称为自动证书管理环境(ACME)。提案的一个版本已作为一个Internet草案发布。

目前, 申请证书的域名只能是特定的域名, 不支持通配符证书(*.example.com),这对于一个拥有众多子域名的公司来说很不方便。但是今年已经说了,将于2018年1月支持通配符证书和ACME v2 API。

阅读全文

[转][译]面向分布式系统工程师的分布式系统理论

原文:Distributed systems theory for the distributed systems engineer

译者:youngsterxyf

Gwen Shapira,大腕级的解决方案架构师(SA),如今Cloudera的全职工程师,在Twitter上提的一个问题引起了我的思考。

如果是以前,我可能会回答“嗯,这里有篇FLP论文,这里有篇Paxos论文,这里还有篇拜占庭将军问题的论文...”,我会罗列一箩筐重要的材料,如果你一头扎进去,至少花费6个月的时间才能过一遍这些材料。然而我已逐渐明白推荐大量的理论性的论文通常恰恰是着手学习分布式系统理论的错误方式(除非你在做一个PhD项目)。论文通常比较深入难懂,需要认真地研习,通常还需要大量的时间投入(significant experience)来理清这些论文的重要贡献,以及在整个理论体系中的位置。要求工程师具备这样的专业水平又有多大的意义呢?

但是,很遗憾,对分布式系统理论方面的重大研究成果和思想进行概括、归纳、背景分析的‘导引’性质的优秀材料非常缺乏;特别是没有居高临下态度的材料。对这块空白区域的思考让我想到了另一个有趣的问题:

一个分布式系统工程师应该知道些什么分布式系统理论?

在这种情况下,一知半解(a little theory)并不会是一件多危险的事情。因此我尝试整理一个列表,罗列出作为一个分布式系统工程师的我认为能够直接应用于我日常工作的一些基本概念;或者让分布式系统工程师完全有能力设计一个新系统的“筹码”。如果你认为我漏掉了一些东西,请联系我。

阅读全文

[译]使用 bcc/BPF 分析 go 程序

BCC 是基于 BPF 的 Linux IO 分析、监控、网络工具集合。BPF Compiler Collection (BCC) 是创建高效内核追踪和处理程序的工具包,包含几个有用的工具和用例。BCC 扩展了 BPF (Berkeley Packet Filters) 的用途,BPF 之前被称为 eBPF,是 Linux 3.15 新增的一个新特性。BCC 大部分的功能都要求 Linux 4.1+。

本文翻译自性能分析大牛Brendan Gregg的 2017年中旬的一篇文章: Golang bcc/BPF Function Tracing, 介绍如何使用最新的工具更加深入的分析Go程序。

阅读全文

常用配置文件格式

配置文件是工程中常用的初始化参数的配置方式,而配置文件的格式有很多种,不同的操作系统、编程语言都会有不同的配置文件的格式,本文罗列了一些常见的配置文件的格式。

不同的配置文件格式有不同的用户友好性, 对于功能的支持也有简单和复杂之分,很难简单说那种配置文件是最好的,有时候需要从多个方面去考虑, 比如Windows较早的开发喜欢使用int、java喜欢使用properties、通用的编程喜欢yamljson等格式,本文也不会对这些格式进行排名,而是简单介绍一下这些格式,用户可以根据自己的实际情况进行选择。

阅读全文

Go Plugin的一个bug

Go 1.8中增加了 plugin package,但是仅支持Linux操作系统,并且还有一些已知的bug。可以说,这个插件系统的实现还未达到"产品级"的水平。

The plugin support is currently incomplete, only supports Linux, and has known bugs.

一些已知的bug已经推到 Go1.10甚至以后的版本中修复了。

今天在测试Go 1.9中的功能的时候就遇到了plugin的一个bug。

阅读全文

[转]设计一个容错的微服务架构

原文: Designing a Microservices Architecture for Failure
翻译: 设计一个容错的微服务架构 by Jason Geng

微服务架构使得可以通过明确定义的服务边界来隔离故障。但是像在每个分布式系统中一样,发生网络、硬件、应用级别的错误都是很常见的。由于服务依赖关系,任何组件可能暂时无法提供服务。为了尽量减少部分中断的影响,我们需要构建容错服务,来优雅地处理这些中断的响应结果。

本文介绍了基于RisingStack 的 Node.js 咨询和开发经验构建和操作高可用性微服务系统的最常见技术和架构模式。

如果你不熟悉本文中的模式,那并不一定意味着你做错了。建立可靠的系统总是会带来额外的成本。

阅读全文

再谈谈获取 goroutine id 的方法

去年年初的时候曾经写过一篇关于如何获取goroutine id的方法: 如何得到goroutine 的 id?, 当时调研了一些一些获取goid的方法。基本的方法有三种:

  1. 通过Stack信息解析出ID
  2. 通过汇编获取runtime·getg方法的调用结果
  3. 直接修改运行时的代码,export一个可以外部调用的GoID()方法

每个方式都有些问题, #1比较慢, #2因为是hack的方式(Go team并不想暴露go id的信息), 针对不同的Go版本中需要特殊的hack手段, #3需要定制Go运行时,不通用。当时的petermattis/goid提供了 #2 的方法, 但是只能在 go 1.3中才起作用,所以只能选择#1的方式获取go id。

最近一年来, petermattis更新了他的代码,逐步增加了对 Go 1.4、1.5、1.6、1.7、1.8、1.9的支持,同时也提供了#1的方法,在#2方法不起作用的时候作为备选,所以我们可以在当前的所有的版本中可以使用stable的获取go id的方法了。

阅读全文

Go 1.9 sync.Map揭秘

在Go 1.6之前, 内置的map类型是部分goroutine安全的,并发的读没有问题,并发的写可能有问题。自go 1.6之后, 并发地读写map会报错,这在一些知名的开源库中都存在这个问题,所以go 1.9之前的解决方案是额外绑定一个锁,封装成一个新的struct或者单独使用锁都可以。

本文带你深入到sync.Map的具体实现中,看看为了增加一个功能,代码是如何变的复杂的,以及作者在实现sync.Map的一些思想。

阅读全文

Mac OS X显示连接

Mac OSX中虽然带了 netstat工具,可是用起来不像Linux下那么爽, 一个是慢 (netstat -p tcp | grep $PORT),二是不能pid,所以stackoverflow上建议使用lsof工具。

所以你可以使用下面的命令:

1
2
3
lsof -n -i4TCP:$PORT | grep LISTEN # Verified on macOS Sierra
lsof -n -iTCP:$PORT | grep LISTEN
lsof -n -i:$PORT | grep LISTEN

为了不显示端口的俗称,你可以加P参数:

1
2
3
lsof -nP -i4TCP:$PORT | grep LISTEN # Verified on macOS Sierra
lsof -nP -iTCP:$PORT | grep LISTEN
lsof -nP -i:$PORT | grep LISTEN

如果不想grep Listen,可以加-sTCP:LISTEN

没有更多要说的了,谨记一下备用。