项目 - 后端技术栈转型方案

前言

某开发项目的后端技术栈比较老了，现在想换到新的技术栈上。使用更好的模式、设计思想、更合理的架构等，为未来的需求迭代做铺垫。怎么办呢？假设系统目前在线上运行着的，直接整体换的话耗时太久，且中间还有新的需求植入。有没有什么办法，可以让我慢慢的将整体系统迁移到新的技术栈上。特别是跨语言的迁移。
举例
如后端语言（java、python、go） 转 后端php
或是 php本身使用的技术栈比较老，想换到新的技术栈上。

答案是有的。

本篇适合任何语言的技术栈迁移

方案设计

流程图

我们在新域名（新的技术栈） 和 旧域名（旧的技术栈）之上，抽一层出来（API 网关），所有流量都需要走API网关，经由API网关策略来确定将此流量分发给新域名还是旧域名。

新域名
1、实现业务功能并对外提供接口时，要考虑到不影响旧技术栈的业务使用。
2、基于新的架构和技术栈开发相关功能
3、假设在开发中，旧域名有新的需求任务且正在开发。则需分析新需求，评估牵涉开发内容，在新体系中同步做出相应开发调整

旧域名
1、减少新的需求接入（在系统底层迭代开发期间，最好不再收取新的需求迭代开发）
2、保证系统的稳定运行（业务功能一旦迁移至新域名后，系统运转有出现异常问题，要能快速切换旧域名完成回退）

API 网关
1、新域名每完成一个业务功能，就把API网关的相关业务功能路由映射由原旧域名转到新域名上。

新问题：如何保持用户会话？
方案1：分析就技术栈的用户会话信息的存储介质是以database在存储，还是以redis、memcache在存储。然后新域名模拟旧技术栈的业务实现获取用户信息。
方案2：旧域名提供一个接口，供新域名调用。此接口可通过签名或是cookie获取用户信息。新域名可通过此接口完成相关业务功能。

总结

基于以上思路，可以慢慢的把业务从旧域名迁移到新域名。