一、前言
在微服务的浪潮下，公司原有的架构已经严重跟不上日益发展的业务需求，随着用户量的增加，
架构越来越臃肿，乃至没有人敢于去动原有的架构，加之架构已经有7、8年的历史，前前后后的
开发人员也换过一批有一批，一旦修改，轻则bug一堆，重则牵一发动全身，所以只能继续沿用
现有的架构，继续叠加新功能，继续改改补补。
基于这样的背景，于去年（也就是2017年）年中开始选型微服务框架，开始进行架构的改造，
开始尝试新的架构体系。
二、过程
选择的过程总是坎坷的，当初有springcloud、有dubbo、有springboot，技术骨干在一起不断的
讨论，争执，各抒己见（眼看着就要打起来了，程序员永远会选择自己最熟悉的技术去解决问题），
在这样的情况下，最终还是选择了下述架构组合：
（图片参考了《某金融公司的架构体系》）
架构中涉及的技术如下：
在这样的架构体系下，团队成员各司其职，在经历了4个月左右的开发时间，最终出了V1.0的版本，
并且有了第一批近5万的用户，只是从这个过程和结果来说，还是相对成功的。
我们的应用就这么上了百度应用市场和360应用市场。
可是，就这么看似成功的一个产品，在刚刚上线后不久，公司就因为各种原因竟然要将其放弃，
或者说是暂停搁置，延续原有的产品体系，继续开拓市场。并且公司潜在的定性这个新的产品是
失败的。（知道这对于技术团队或者产品团队来说是多么大的打击么？？？）
然而，并没有所谓的总结会，也并没有所谓的"复盘会"，有的只是内部的各种矛盾、各种负面
的消息。
三、希望
事情难道就这么结束了？答案当然是NO！
眼看着项目搁置，最先使用的客户要求继续使用，于是，一个面向全国的saas产品，一个采用
了全新微服务架构旨在满足千万用户使用的技术架构，就这么硬生生的转成面向单个客户使用的
定制化项目了。
当然，这未尝不是件好事！
于是，在客户的要求下，基于1.0的产品版本，叠加了客户要求定制开发的新功能：功能1、功
能2、功能3、。。。。。功能N，然后产品的名字也换成了客户要求的名字。。。
一切似乎正在朝着好的方向发展！
公司开始新的决策：基于该产品，如果有客户需要定制，就基于这个来做，既不浪费之前几百
万的成本投入，又能够开拓新的市场机会。
非常好的一个决定！
四、迁移前
公司原有的部署都使用阿里云服务器，我们的微服务架构使用了将近15台服务器，大致如下：
而这些还不是所有的，加上我们的测试服务器、预生产服务器、开发服务器，一共将近30台服
务器。
现在要将所有的应用都部署到客户自己的服务器环境中，那就涉及到将现有的应用、环境、数
据都进行迁移。
一想到要迁移我的头就大了！
五、迁移过程
客户那边都是虚机，出于环境安全考虑，要求我们在本地搭建好虚机环境后导出ova文件，由
客户那边的信息部门人员进行导入；而不是客户提供虚机由我们在虚机上进行环境部署。
于是漫长的虚机构建过程就在本地展开了：（由于原来负责搭建的人员因各种原因离职了，
所有的环境只能由我亲自构建）
这是经过了将近3个礼拜构建的所有虚机，虚机中包含了docker环境、数据库环境、集群环境、
nginx环境、redis环境、mongodb环境、springcloud环境、全文检索环境等等。
构筑过程中积累了一些不是很熟悉的技术点，简要整理如下，大家也可以看看：
1 Ifconfig命令
yum -y install net-tools
2 安装文件系统和挂载
1）检查是否缺少基础环境
rpm -qa | grep nfs-utils
rpm -qa | grep rpcbind
2）如果没有则安装
yum -y install nfs-utils
yum -y install rpcbind
3）安装完成之后配置nfs访问目录，配置文件位置/etc/exports，默认是空的这里添加一行：
/nfs_test 192.168.1.8(rw,no_root_squash,no_all_squash,async) 192.168.1.9(rw,no_root_squash,no_all_squash,async)
4）配置完后启动服务
systemctl start rpcbind.service
systemctl start nfs.service
5）启动之后可以通过status来查看状态，如果下次修改了配置，可以重启服务来使配置生效，也可以直接执行如下命令刷新配置：
exportfs -a
刷新配置即可生效
现在服务端配置完毕，可以在对应的主机上来配置客户端了，需要的环境和服务端一样，要保证安装nfs-utils和rpcbind
保证环境没问题和上面一样启动rpcbind服务和nfs服务
首先创建挂载点： mkdir /mnt/test1
然后挂载nfs： mount -t nfs 192.168.1.3:/nfs_test /mnt/test1
挂载成功之后通过 df -h 可以查看挂载的情况，nfs可用空间就是服务端/nfs_test目录所能使用的最大空间
现在就可以往nfs写入数据了，服务端往/nfs_test读写数据和客户端往/mnt/test1读写数据是一样的，这样就实现了文件同步和共享
卸载nfs和普通文件系统一样，使用： umount /mnt/test1
如果需要设置开机挂载，在/etc/fstab添加一行配置即可： 192.168.1.3:/nfs_test /mnt/test1 nfs rw,tcp,intr 0 1 然后服务端和客户端都要用enable设置nfs和rpcbind服务开机启动，然后才可以正常挂载
————————————————
版权声明：本文为CSDN博主「真爱无敌86」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/dongzhumao86/article/details/82848066