化茧成蝶: Go在FreeWheel服务化中的实践

近一年来,FreeWheel正在将业务系统迁移到微服务架构,而Go语言因其原生对HTTP服务开发的良好支持及易于容器化部署的特点,成为我们微服务开发的首选语言。

在 Go 开源之后的 7 年里,它已被全球采用。可以看到全球一批顶尖企业,如 Adobe、IBM、Intel 等都开始使用 Go 开发自己的服务,甚至完全转向 Go 开发。而令人惊讶的是,随着数据科学和机器学习技术的发展和成熟,Go 有了更大的展示舞台,它的易部署等特性也正推动其向现代架构走来。

2014 年,FreeWheel 开始使用 Go 语言。最初是用于重写某一视频信息上传程序以提升其性能,后来因其接近 C 语言的执行效率,具备较低的学习曲线,能帮助实现简单的部署以及拥有丰富的类库,Go 语言也在 FreeWheel 越来越多的项目中被使用,至今已累积超过 10 万行代码。近一年来,FreeWheel 正在将业务系统迁移到微服务架构,而 Go 语言因其原生对 HTTP 服务开发的良好支持及易于容器化部署的特点,成为我们微服务开发的首选语言。目前 Go 社区中已有不少针对微服务中特定问题的项目——从 HTTP-to-RPC Mapping 到 ORM。但纵观下来,仍缺少成熟的构建微服务系统的整体方案。

为了快速地将业务迁移至微服务系统并保持基础架构的一致性,FreeWheel 利用业界优秀的工具和经过实践开发了一个微服务框架——Wheels,以解决业务服务中的共性问题,包括接口定义、访问控制、负载均衡、服务监控、数据库访问、事件消息、容器化部署和文档管理等。

在开始服务化改造之前,FreeWheel 的业务系统是一个基于 Ruby on Rails 的单体应用,大约有 60 万行代码,但其内部根据业务分为若干模块,且边界比较清晰,这也成为我们设计服务拆分时的基础。我们还有一个主要考量是尽量降低服务化带来的额外运维成本,这对于前期推动服务化非常必要。基于上述两点,我们设定了 FreeWheel 服务化的基本原则:

  1. 服务分为业务服务和基础服务两种,业务服务拆分基于核心业务概念,从粗粒度开始,将相关功能都封装在同一服务内,尽量避免业务服务之间的直接调用;
  2. 不提供跨业务服务的 ACID 性质的事务支持;
  3. 用事件(Event)来传递服务状态的变化;
  4. 服务通过容器来部署,并使用容器管理系统来运维;
  5. 使用统一语言(Go)和统一框架(后面会提到的 Wheels)。

Go 语言已经在我们向服务化迁移的进程中发挥了重大作用,无论是其简洁高效的语法,还是高性能的运行和并发支持,都为我们的开发和运维带来了极大的便利。我们将在公司继续推进 Go 语言的深入研究和挖掘,相信它也将在未来的舞台上扮演更重要的角色。

最后,真诚感谢作者团队:罗昕、杨谕黔、李瑜伟、张啸为本书撰稿,并使得 FreeWheel 的技术实践得以传播给其他技术同行。

目录

FreeWheel 服务化与 Wheels 框架从 0 到 1 实践

深入理解 Go 语言对象模型 (Go Object Model Inside Out)

说一说 Go 语言并发模型中的 Channel

ETCD 背后分布式存储实现

gRPC 实践中的两个问题与思考