> 1 Windows服务器运行asp.net控制第三方验证仅用于apis和webservice – (我们称之为WIN)
> 8个LAMP服务器(Web,报告,cron,存储库等) – (让我们称之为新)
我们目前的环境：
14个LAMP服务器(Web,邮件,存储库等) – (我们称之为CURRENT)
好消息是,新的代码是很好的straigt foward.几百万行代码(大多数是apis,第三方),我可以将其转换为CURRENT系统.新的和CURRENT使用两个CentOs,这将使转换容易,但Windows服务器,我不知道现在该怎么做.
现在的坏消息新系统数据库模式根本不好.它不正则化,查询速度慢(数据库查询和代码).我的第一个想法是将它们重新设计成符合CURRENT代码的更规范的结构,但是我不工作.新系统的表是巨大的.新系统有7个数据库,超过10000个表,最小的表有超过100k行,一些表有超过5亿行.其中一个数据库具有大多数表,每个表有超过25百万行.
迁移是否安全？如果我应该迁移,我想知道为了将Windows和新系统迁移到我的CURRENT系统中,最安全的解决方案是什么？
您的迁移新系统的想法有利与弊,您需要确保顺利进行,以获得最终可靠的产品.
优点：
>只有一个系统要维护：你不想维护3个系统;
>一个代码/数据库环境：PHP vs ASP.NET和MSsql vs MysqL;
>集中代码/数据库;
>一个编码(代码和数据库)标准;
>保存/出售权限(您将把代码迁移到您的14台服务器,也许您不需要其他9(WIN NEW),因此您可以出售或保留下一个项目)
缺点：
>更高的风险(崩溃,不兼容,您需要了解的未知功能等).
>比迁移或重新设计所有东西便宜
>失败的风险低于迁移(因为你已经知道了这两个系统的工作)
>规划,控制,实施,质量保证：如果其中一个失败,非常糟糕;
>昂贵：迁移可能在时间和金钱上昂贵;
这是一个大数据库,改变/优化这将对劳动时间进行大量投资.这不是你可以在几个小时内轻松做的事情.这可能需要几个星期或几个月才能成功将数据迁移到CURRENT系统,而不会发生错误.如果可以,您可以从数据库模式迁移常见或相似之处,如客户端或产品.这样,您可以导入CURRENT系统可以无错误地运行的数据,并且您的代码也可以识别. CURRENT系统的用户可以立即开始管理这些项目/记录,而不会出现问题.从新的或记录您的CURRENT系统无法识别,您可以简单地重新设计这些表并将其迁移到CURRENT系统(然后更新您当前的代码).
在代码迁移方面,如果来自新系统的代码足够好,并且符合您的标准,您可以保留它.这将节省开发时间,只需确保更新查询和服务器连接.另一方面,如果它就像意大利面条代码,你将不得不明白代码的作用.这也可以在劳动时间内大量投资.我可以推荐这里来标准化这一个,并按照与CURRENT组织相同的方式组织代码.您可以使用通用文件和文件夹结构将代码集中在一个通用文件夹中.你可以把所有的公共库,第三方等等,所以当你调用CURRENT和新的代码,它加载相同的PHP类.这将使您轻松实现从NEW到CURRENT系统的转换.这样,你就可以在同一个地方知道你所需的所有文件,并且很容易维护.特别是如果你的代码需要需要文件的文件.如果你的代码遍布你的服务器,你可以创建一个NFS,如果你喜欢这个想法.
现在,我可以建议的是从Parallel Adoption开始.这样你就可以确保所有的系统都能正常工作并且健康.然后缓慢将数据/代码迁移到CURRENT系统,直到一切都完成.这并不容易,您必须确定首先要迁移的新WIN系统的哪一部分.我的建议是迁移WIN系统.因为这是独立于CURRENT和NEW系统,只要你显示相同的输出,你应该很好.在PHP中搜索开源或类似的验证,或者找不到任何的,建立它们.这样WIN系统可以轻松地迁移到您当前的组织结构和编码标准.执行测试和质量保证将很容易,您可以很快完成.
一旦WIN被迁移,您需要确定您需要先转移到CURRENT系统.例如,如果NEW和CURRENT系统具有“客户端”,则从NEW系统收集所有信息,并使用脚本(手动或脚本)将它们移动到CURRENT系统.然后,您可以迁移客户端元素,如产品,结算单或与这些客户端相关的任何其他记录).重复这些步骤,直到所有的数据被迁移.这样,您不必重新设计任何表格或从NEW系统更改任何代码,所有内容都保存在CURRENT系统中,并且一切正常.
我不会推荐big bang adoption这种情况.
