原有架构的问题

FreeWheel是一家为客户提供数字视频广告管理技术和服务的公司。其业务端产品需要对接客户，提供视频广告投放优化界面，类似于Web ERP，该业务系统采用Rails技术栈开发，其架构是一个典型的三层架构。

这个系统经过近十年的研发和迭代，代码量达到数十万行，业务的特殊性和代码的复杂度让团队的维护和新功能研发越来越困难：

· 广告系统本身业务逻辑非常复杂，体现在它的数据实体很多，业务流程很长，分支逻辑很多。这样导致代码修改起来困难，可能改一个会影响好几个其它模块，同时维护也变困难，后来者不清楚模块具体实现细节，难以接手继续开发。

· Ruby本身是一个高度动态的语言，通过解释执行。带来的坏处就是团队大了，维护成本很高，当发现问题的时候很难通过看代码知道问题出在哪儿，而且它也缺乏静态检查的工具，导致代码质量难以控制。

由于以上这些原因，FreeWheel架构组决定将系统进行拆分，通过模块化来梳理和简化业务逻辑，当时微服务已经有不少公司采用，并取得了不错效果，架构组在调研之后决定采用微服务架构。同时团队还决定切换技术栈，选择更利于开发维护的语言和工具，基于种种理由，团队最后选择了Golang。