Go与微服务-序言

好奇心

我是在2012年左右开始接触Go，那会主要是基于C/C++做大型的嵌入式系统。初并不觉得Go有什么优势。一方面来看，性能比不上C/C++，相差数倍，且无法控制内存生命周期，只能依赖Go本身的GC机制。另一方面来看，我们基于C/C++已有一套程序的流程体系，用Go的开发效率并没有显著提升，且编译后的二进制程序往往过大，这对大多嵌入式系统而言是难以接受的。

那时候关注Go主要是出于好奇心，为什么Rob Pike和Ken Thompson等大拿要设计这么一门语言，是因为C不够好？具体是哪里不好？Go本身又有什么优势，在设计初究竟做了怎样的取舍？

权衡

同年，开始推行敏捷开发，尝试适应短平快的互联网节奏，才发现要基于C/C++从零开始设计开发系统是件多么痛苦的事情，于是转而怂恿组内转Go。也正是这时，我才开始深刻明白Go所做Tradeoff的意义。

• 牺牲性能，换取代码可读性
• 牺牲灵活语法，换取语言简洁性
• 牺牲内存管理能力，换取程序健壮性
• ……

以上这些都是我们所能看到Go所做的部分Tradeoff，这其实就是一种妥协，或也可以说是一种佳实践，只是这种妥协/佳实践是在语言层面就做了，并没有给开发者过多的选择。这或许也是从C++这门语言学到的教训，当人们有太多选择时，他们往往容易做出错误的选择，或是把简单的问题复杂化。

微服务

微服务这个概念，应该是在2014年开始被Martin Fowler（ThoughtWorks创始人）提出的。

微服务是一种以业务功能为主的服务设计概念，每一个服务都具有自主运行的业务功能，对外开放不受语言限制的 API (常用的是 HTTP)，应用程序则是由一个或多个微服务组成。

不过其实早在之前，我们的LET核心网络系统就已经是这么设计的了。当然了，这套系统的核心架构本身也是老外设计的……其实很多大型系统（譬如Linux内核）中都可以看到这样的思想，而现在不过是尝试把这些思想应用到上层业务系统中来。

不同业务的服务不断进行拆分，总的说来做的就是以下三点：

• 确定协议
• 约束边界
• 独立自治

结合

那么，如何将Go于微服务快速结合起来，构建一套完整的业务系统？这将是我这个系列文章所要说明的，欢迎关注。