FreeWheel服务化的基本设计

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

1. 服务分为业务服务和基础服务两种，业务服务拆分基于核心业务概念，从粗粒度开始，将相关功能都封装在同一服务内，尽量避免业务服务之间的直接调用；

2. 不提供跨业务服务的ACID性质的事务支持；

3. 用事件（Event）来传递服务状态的变化；

4. 服务通过容器来部署，并使用容器管理系统来运维；

5. 使用统一语言（Go）和统一框架（后面会提到的Wheels）。

这些原则基本与主流微服务的架构思想一致。基于本文开篇所提及的，目前Go社区在构建微服务系统的成熟整体方案上的缺乏，FreeWheel才有了开发Wheels的想法，目标就是实现快速的将FreeWheel的业务迁移到微服务架构，并保持基础架构的一致性。