迁移策略

FreeWheel业务系统在决定重构时，新的需求仍然源源不断地产生，不能把需求停掉转而研发新系统；同时团队人力有限，不可能划出一部分人来转型微服务研发。因此，团队在一边研发原有Rails应用的同时，一边做新的系统研发。

在设计服务的粒度上，因为FreeWheel业务系统本身已经有了一套成熟的数据模型，这个数据模型可以反映经营的业务概念，也作为大家共同的语言，围绕这些数据模型是业务实体，团队在确认出三到四个核心业务实体后，围绕这些先创建了大概三到四个服务，最终创建的服务在10个左右，服务的粒度其实比较粗。FreeWheel采用微服务的架构模式，其实主要也是吸收微服务架构中服务治理的一些实践经验，在初期服务设计上先从粗粒度开始。

在进行微服务改造时，团队还面临一个比较大的问题，就是原有架构使用单个数据库，里面有上千张表，数据分支很多，难以进行拆分。为了解决数据访问问题，专门设计了一个数据访问层，将原系统和新系统的数据库连接都通过数据访问层进行。数据访问层（内部简称DAL）的设计目标包括：

1．对业务数据的访问进行全局路由，控制和优化，比如对不同客户的数据做软隔离，读写分离等；

2．在不分库的情况下，实现不同服务对数据的分治；

3．将应用与数据库具体实现隔离，为今后拆分数据库以及应用多种数据源做准备。

其基本架构如下图所示：

最后，FreeWheel还需要解决上线问题，因为面向大B类客户，需要保证新老系统切换的平滑稳定。在这方面，对已开放的Open API, FreeWheel都保证接口和输入不变，通过添加一层适配器来将实现切换到新的服务上，同时通过完善的线下测试和QA，以及线上的灰度发布来解决，并且，代码的单测覆盖率达到80% 以上以保证代码质量，通过线下流量回放来保证原有系统的业务逻辑能够顺利完成。