一、 适配迁移方案整体理解
 
根据对应用系统现状及需求分析的理解，整体理解如下：
 
1、首先对应用系统进行现状调研，了解应用系统的功能内容、性能指标、使用情况等，根据了解到的需求情况编写应用适配方案，即可开始准备适配与迁移改造工作。
 
2、为了不影响用户正常使用应用系统处理工作，因此本次应用适配与迁移按照“双轨并行、试点突破、符合实际、有效验证”的战略要求，“双轨并行”路线主要是不对实际的业务处理结果产生实质性影响，保证混合环境运行的一致性和完整性，圆满完成应用的适配与迁移。
 
3、数据库适配是本次应用迁移重点、难点，解决方案是使用国产数据库自有的适配迁移工具和人工重复多次验证，最终保障数据完整迁移，不异常。
 
4、鉴于原系统建设单位并非我单位，适配与迁移过程中还存在与原软件开发商协调的风险，我单位会与原厂商积极协调，紧密合作，圆满完成本次迁移工作。
 
5、为了防范物理损坏导致的数据丢失问题，在数据安全方面，最重要的是保障数据的备份和恢复，尤其是在双环境分布式数据架构环境中，不仅需要使用国产数据库软件提供的备份工具进行本地备份，还需要开发不依赖于特定数据库基础软件的工具程序，将数据备份到指定的备份服务器上，使数据体系具备多个副本，尽可能保证在设备异常情况下，能够及时恢复数据，维系应用系统的不间断运行。
 
6、本次迁移适配选择以飞腾CPU、长城整机体系代表的国产ARM架构，ARM技术架构具有体积小、低功耗、低成本、高性能、执行速度快等明显优势。
 
 
 
二、 技术路线
 
目前国产CPU 厂商得到了相应指令集的架构授权，CPU 的指令集分为复杂指令集(CISC)和精简指令集(RISC)两大类。复杂指令集以 x86 架构为代表，精简指令集则包括 ARM、MIPS、Alpha、Power 等。
 
我单位选择的迁移适配技术路线是以飞腾CPU、长城整机为体系代表的国产ARM架构。
 
ARM架构的优势体现在：
 
1、ARM 通过三大层级授权联合行业伙伴，扩展产业应用生态。
 
使用层级授权：是最低的授权层级，可以使用封装完毕的ARM处理器核心，可通过增加封装之外的DSP核心的形式实现更多的功能和特性，例如频率、功耗等，不可改变原有设计，ARM 对大多中国背景的企业采用这一级别的授权。
 
内核层级授权：可以以内核为基础添加外设，比如USART、GPIO、 SPI、ADC 等，最终都形成了新的 MCN，代表厂商为三星、德州仪器、 博通、飞思卡尔、富士通等。
 
架构/指令集层级授权：可以对 ARM架构或 ARM指令集进行改造以实现自行设计处理器，代表厂商为高通 Krait、Marvell 以及飞腾等。
 
2、体积小、低功耗、低成本、高性能
 
ARM 架构是一个精简指令集（RISC）处理器架构家族，ARM处理器体积小，不占空间，能够完美完成嵌入式环境下的应用，ARM同样保持着超强的性能，在世界都处于领先地位，不仅如此还力求做到最低的功率消耗。ARM结构的优点是能兼顾到性能、功耗、代码密度、价格等几个方面，而且做得比较均衡。
 
3、指令执行速度更快，指令长度固定
 
ARM处理器共有37个寄存器，被分为若干个组（BANK），这些寄存器包括：31个通用寄存器，包括程序计数器（PC指针），均为32位的寄存器。6个状态寄存器，用以标识CPU的工作状态及程序的运行状态，均为32位，目前只使用了其中的一部分。与ARM代码相比较，可节省30%～40%以上的存储空间，同时具备32位代码的所有优点。
 
4、很好的兼容8位/16位器件
 
ARM微处理器同时还支持较新体系结构中的支持两种指令集：ARM指令集和Thumb指令集。其中，ARM指令为32位的长度，Thumb指令为16位长度。但同时Thumb指令集又是ARM指令集的功能子集。
 
5、丰富的可选择芯片
 
拥有丰富的芯片，在国内市场上，常见的有ST、TI、NXP、Atmel、Samsung、OKI、Sharp、Hynix、Crystal等厂家的芯片。用户可以根据各自的应用需求，从性能、功能等方面考察，在许多具体型号中选择最合适的芯片来设计自己的应用系统。
 
6、高并发处理效率，升级速度快
 
目前ARM已经做到高密度整合，由于ARM授权的弹性以及核心架构的简洁，ARM架构与GPU、多媒体译码核心、基频调制解调器、I/O 控制等架构整合，透过 SoC（System On a Chip，系统单芯片）的方式，ARM架构应用处理器完成近年 x86 架构处理器积极跨足的单芯片设计，并且通过各种不同的核心分工各司其职，相较于传统处理器有更好的并发处理效率。目前 ARM 已经明确了其针对数据中心的 Neoverse 架构迭代升级策略，每一代性能提升都在 30%以上，远远超过X86架构CPU每一代性能提升的幅度。未来，ARM在性能上与 X86之间的差距将不断缩小，产品性能将逐渐优越。
 
7、AI 时代，数据处理层面优势
 
在云端市场，随着人工智能、云计算、物联网等新一代科技领域的兴起，云端计算架构拐点已至。在以上领域，云端、计算对intel X86服务器 CPU依赖较弱，ARM凭借在CPU和GPU处理器领域领先技术优势，目前，ARM凭借技术先发优势，设计的ML 处理器架构已成功补全 AI 市场空白，能够应对几乎所有应用场景的AI/ML 需求。
 
 
 
三、 方法的科学合理性
 
   通过调研后的需求编写应用迁移方案，开始进行迁移适配实施。适配方案在已搭建的迁移适配实验室中进行测试，通过在国产化环境下测试应用系统迁移方案的可行性，不断验证方法合理性，通过以上测试认证，证明迁移、适配方法科学合理。
 
 
 
四、 系统调研
 
4.1 调研目的
 
  充分调研系统使用单位各业务应用系统情况，包括具体应用系统名称、系统功能情况、系统性能指标、系统用户数量、系统安全等级保护等级、系统安全指标、系统部署情况、系统开发语言及系统架构等，同时摸清应用系统使用服务器的资源情况，网络情况，并进行系统适配分析和技术路线选型。
 
4.2 用户分析
 
了解系统使用单位当前使用习惯现状，包括对操作系统、办公套件、安全防护软件等，是否对国产化平台下相关软件的存在了解。对于大部分用户来说，可能面临着操作模式、使用习惯、用户体验等方面的较大调整。
 
 
 
五、 迁移改造
 
  应用迁移工作正式启动，首先在迁移适配实验室国产化环境下进行迁移改造，主要是系统功能、历史数据的迁移及改造工作。
 
5.1 系统功能适配与迁移及改造
 
   迁移改造不影响用户使用方正常办公的前提下，按照“双轨并行”的原则，将业务应用系统的功能平滑移植到迁移适配国产化环境下。根据迁移后的完整内容，修改调整代码层、数据库表结构、字段等，达到与原应用系统无任何差异。
 
5.2 数据库适配
 
5.2.1 数据整理策略
 
数据整理就是将原系统数据整理为系统转换程序能够识别的数据。数据整理大致分为两个阶段：第一阶段就是将不同类型来源数据采集备份到统一的数据库中；第二阶段就是将原始数据进行整理，按照不同的要求分类进入不同的中间数据库，为数据转换提供中间数据。数据整理过程采用了以下方法：
 
（1）确保原始数据的完整性
 
在进行数据整理之间，我们先需要对原始采集数据进行备份。备份的目的有两个：一个是统一数据库，便于数据转换，另一个就是为以后数据追根溯源提供参考依据。在本系统中，我们将采用DB2作为备份统一数据库。
 
（2）数据分级过滤策略
 
数据分级过滤就是把数据按照不同的数据级别进行分类整理进入不同的中间数据库中。本系统中我们把数据分为三个级别：废弃数据、待调整数据、可转换数据。废弃数据就是该部分数据的存在对系统资源造成浪费的数据，并且会影响以后系统的运行。待调整数据就是该部分数据严重影响新系统的运行，必须进行人工调整后，方可进行数据转换。可转换数据就是该部分数据不需做任何处理，基本满足数据转换的要求或者是该部分数据新系统建议调整，但是不影响系统的运行，可以等新系统运行后再调整，这样可以为数据转换工作节省很多时间。
 
（3）借助数据整理相关工具
 
数据整理非常艰巨，涉及的数据量很大，通过人工检查是不可能完成的，因此必须编写相关的数据整理工具完成数据整理。包括数据整理工具和数据纠错工具。数据整理工具负责将原始备份数据库中的数据进行分类进入不同的中间数据库；数据纠错工具负责提供友好、方便的工具界面供用户方相关人员完善和纠正错误数据。
 
（4）利用中间库作为桥梁
 
由于原系统和新系统的数据库结构可能不一样，所以采用中间库作为衔接新旧系统数据的重要桥梁，对于建立新旧系统的对照关系很重要。一旦业务人员对新系统中某项转换数据存在疑问的情况下，就可以通过中间库的关联，顺利找出原数据。
 
5.2.2 数据转换
 
数据转换就是将整理后的数据，依照对照表的要求进行转换，并写入到新系统。这个过程可以通过交换系统实现。
 
数据整理与转换步骤
 
（1）设计数据移植方案
 
设计数据移植方案主要包括以下几个方面工作：研究历史数据的结构、来源、数据项定义、取值等现状，研究新旧数据库结构的差异，评估和选择数据移植的软硬件平台、选择数据移植方法、选择数据备份和恢复策略、设计数据移植和测试方案等。
 
（2）源数据库数据清理
 
对于一个运行已久的数据库，主要存在三种数据库垃圾：数据库对象垃圾、数据库权限垃圾、数据垃圾。数据库对象的清理不是一件容易的工作，需有认真负责的态度，要有耐力，任何错误的清理不仅会造成前端不能运行，而且将会造成数据的丢失。所以清理数据库对象也许需要一个安全、准确，可很快恢复的方法。
 
首先要认识数据库资源，包括数据库对象，如表、数据库事件、过程、函数，数据库结构关系，在此基础上结合运行系统，确认数据库垃圾，制定合理的垃圾清理方案，达到清理垃圾的目的。
 
主要方法是对数据库数据进行整合和分解，整合相关数据减少数据的重复，分解数据则可是数据团体更趋向合理，当然整合和分解要以适合新设计的数据库结构为基础，以便简化转化程序。
 
（3）进行数据模拟移植
 
根据设计的数据移植方案，建立一个模拟的数据移植环境，它既能仿真实际环境又不影响实际数据，然后在数据模拟移植环境中测试数据移植的效果。
 
数据模拟移植前也应按备份策略备份模拟数据，以便数据移植后能按恢复策略进行恢复测试。
 
（4）测试数据模拟移植
 
根据设计的数据移植测试方案测试数据模拟移植，也就是检查数据模拟移植后数据和应用软件是否正常，主要包括：数据一致性测试、应用软件执行功能测试、性能测试、数据备份和恢复测试等。
 
（5）准备实施数据移植
 
数据模拟移植测试成功后，在正式实施数据移植前还需要做好以下几个方面工作：进行完全数据备份、确定数据移植方案、安装和配置软硬件等。
 
（6）正式实施数据移植
 
按照确定的数据移植方案，正式实施数据移植。
 
5.3 操作系统适配
 
国产操作系统多为以Linux为基础二次开发的操作系统。Linux，全称GNU/Linux，是一套免费使用和自由传播的类Unix操作系统，是一个基于POSIX和Unix的多用户、多任务、支持多线程和多CPU的操作系统。Linux不仅系统性能稳定，而且是开源软件。其核心防火墙组件性能高效、配置简单，保证了系统的安全。伴随着互联网的发展，Linux得到了来自全世界软件爱好者、组织、公司的支持。通过对服务器端国产Linux操作系统进行适配，并对适配结果进行适配性改造和升级。
 
5.4 中间件适配
 
中间件位于底层平台(操作系统)和应用软件之间，是一种跨平台的基础软件。目前，中间件主要用于解决分布式环境下数据传输、数据访问、应用调度、系统构建和系统集成、流程管理等问题，是分布式环境下支撑应用开发、运行和集成的平台。随着 IT 行业的发展，许多软件需要在不同的硬件平台、网络协议异构环境下运行，应用也从局域网发展到广域网，传统的“客户端/服务器”两层结构已无法适应需求，以中间件软件为基础框架的三层应用模式应运而生。通过在中间层部署中间件，主要目的在于：1）高并发访问的处理和快速响应；2）屏蔽异构性，实现互操作；3）可对数据传输加密，提高安全性。
 
我方在服务器端适配的中间件产品为三期名录产品，将正在使用的业务应用系统内的中间件轻松移植替换成国产中间件，通过一系列的操作配置，使国产中间件可以有效支撑业务应用系统，同时兼容国产CPU、操作系统、数据库等主流国产软硬件产品，实现业务应用系统与国产中间件能够良好兼容适配，支撑用户正常工作。
 
5.5 系统架构适配
 
现在软件开发的整体架构主要分为B/S架构与C/S架构，选择哪种架构不仅对于软件开发公司很重要，也对应用企业很重要，在应用的过程中，肯定会碰到这个问题。
 
C/S（客户端/服务器模式）：
 
客户端和服务器都是独立的计算机，客户端是面向最终用户的应用程序或一些接口设备，是服务的消耗者，可以简单的将客户端理解为那些用于访问服务器资料的计算机；服务器是一台连入网络的计算机，它负责向其他计算机提供各种网络服务。
 
B/S（浏览器/服务器模式）：
 
这种模式是随着Internet技术兴起而出现的一种网络结构模式，将系统大部分的逻辑功能集中到服务器上，客户端只实现极少的事务逻辑，使系统的开发和维护都更简洁。
 
最常用C/S架构技术为微软.Net平台。对此类应用适配，项目重新开发是最好选择。原因两点：.Net平台在理论上可以迁移国产操作系统，实际基本无法迁移。数据库也面临重新对接AQKK数据库。所以，.Net平台迁移基本就属于重构。
 
C和C++也可以实现C/S架构，以及常用的算法库也会由C&C++语言编写，对于此类项目迁移，基本不可能用Java重写，重写之后也不可能达到技术要求（如速度、效率、硬件调用、并行计算、图形计算、加密算法等）。此类项目只能通过C&C++重写。
 
C/S架构适配，将满足UOS、麒麟等纳入三期名录的国产操作系统适配。而B/S架构通常分为含插件的B/S架构和不含插件的B/S架构，不含插件的B/S架构可直接进行基于浏览器的跨平台迁移，含插件的B/S架构，除基于浏览器的跨平台迁移外，还需考虑插件本身的适配情况，需要获取到插件厂商的支持，必要时涉及源代码的修改。
 
 
 
六、 适配改造
 
    应用系统适配适用于依旧运行于X86服务器的应用系统，在X86服务器运行的基础上，满足对国产化软件的适配使用，主要包括操作系统适配、数据库适配、中间件适配、应用客户端适配等。
 
6.1 多浏览器适配
 
对B/S架构下应用系统的Web浏览器进行兼容性适配，适配国产化环境下的国产浏览器和X86环境下火狐、chrome、360等主流浏览器，页面是否能正常打开、页面内容是否完全显示、页面打开无明显卡顿等为评判标准进行适配优化。
 
6.2 外设适配
 
外设适配主要为常用第三方外接设备的适配，与外设厂家紧密结合，获取外设系统接口，与应用系统在国产环境下进行适配兼容。
 
 
 
七、 适配自验证
 
    根据应用系统的特点，在我公司搭建的迁移适配国产化环境下进行多方面的测试，对操作系统、数据库、中间件、应用客户端、多浏览器、外设等进行适配自验证，以获得良好完善的功能、性能、可用性、兼容性及安全性等。
 
7.1 功能测试
 
验证迁移之后的应用系统功能的完整性和正确性，包括应用功能模块测试、高可靠性测试、数据备份测试等。
 
7.2 性能测试
 
吞吐量：每秒钟系统能够处理客户的请求数、任务数，其直接体现系统的承载的能力。
 
并发用户数：同一时刻与服务器进行数据交互的所有用户数量；
 
响应时间：服务处理一个请求或一个任务的耗时。
 
错误率：一批请求中结果出错的请求所占比例。
 
7.3 用户界面测试
 
   测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯，此外还要测试界面操作便捷性、导航简单易懂性，页面元素的可用性，界面中文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否完美等。
 
7.4 兼容性测试
 
   应用系统要进行严格的兼容性测试，首先是与操作系统的兼容性测试；其次对国产不同的浏览器进行综合性的测试，还要对同一浏览器进行不同版本的测试。最后要对分辨率和打印机进行兼容性测试，分辨率主要是测试页面版式在不同分辨率下是否能正常显示，打印机测试是看浏览器网页是否能正常打印。
 
7.5 安全测试
 
登录与权限：验证用户输入有效性，验证输入错误的用户名或密码不能登录，不能输入非法字符，允许登录失败的次数等。
 
超时限制：用户登录后在一定时间内（通常为15分钟）没有对该页面进行包括点击在内的任何操作，是否需要重新登录才能正常使用。
 
加解密测试：测试用户名和密码是否为加密，加密是否正确。
 
7.6 组合测试
 
对出现的缺陷进行修改并重新验证，确保修改的正确性，最终达到所有功能、性能所规定的标准，即完成在我公司的测试验证，由我公司出具测试报告。
 
 
 
八、 测试认证
 
我公司将修改验证成功后的应用系统测试完成后，由甲方进行验证测试。
 
 
 
九、 迁移实施
 
首先与用户确定割接时间，建议正式数据转换时间放在月结刚刚完成后并且最好是节假日期间进行迁移切换。
 
 
 
第一步：编写《系统切换方案》。
 
系统切换方案包括系统切换方法、系统切换计划等内容。
 
第二步：组织相关人员对《系统切换方案》进行评审，如果未通过，则需要调整系统切换方案。
 
第三步：进行业务系统数据转换。
 
在进行业务系统数据转换前，需要先选择一个时间点进行业务系统数据采集。该时间点的选择以完成一个完整的业务周期为准。
 
（1）转换时机
 
根据以往的经验，我们建议将正式数据转换的时间放在系统月结刚刚完成后并且最好是节假日。
 
（2）准备工作
 
正式数据转换前的准备工作是非常多的，现列举如下：
 
编写详细的《数据转换指南》。《数据转换指南》应该是在前面的几次试转换过程中编写并完善的，要详细说明数据转换的全过程，包括：准备工作、执行步骤、注意事项等。
 
编写执行脚本。在前面几次试转换的基础上编写并完善好数据转换执行脚本。执行脚本包括：转换执行脚本、验证执行脚本等。所有的脚本都必须安装执行的先后顺序编写，在正式转换时将按照顺序来执行。
 
数据库环境准备。根据以往的经验，在正式转换阶段出现的异常往往都是有数据库方面的，大部分是因为数据库环境没有准备好。数据库方面需要做好如下几方面的准备：表空间划分、大数据文件准备、大回滚段准备、创建索引等。
 
其他必要准备。在正式转换前，老系统要停止使用，同时在还需要把老系统的数据做一次完整的备份。
 
（3）执行过程
 
数据转换时将按照已经编写好的转换执行脚本来进行。对没一步的操作都要做好日志记录，日志分两种，一种是计算机自动产生的日志，如LOG文件；另一种是在转换执行过程中手工做的记录。在正式转换时，要求至少两人一起工作，其中一人负责操作，另外一人负责监督，两人都必须做好记录。
 
每执行完一条转换命令后都需要去查看一些错误记录表，如果出现异常错误信息，需要暂停转换执行，对错误分析处理完毕后才能继续执行。
 
（4）验证过程
 
转换执行结束后，需要对转换的结果进行验证，验证时按照已经编写好的验证脚本来进行，验证最好由两名以上的人员分开来进行，在验证过程中做好每一步的验证记录。
 
如果在验证过程中没有发现异常，并且几名验证人员的验证记录都非常一致，则可以认为已经通过验证。
 
（5）收尾工作
 
数据转换工作执行完毕后，需要对关闭原有系统全部的业务经办功能，只开发查询功能，以便业务人员在需要时可以继续查询旧系统中的数据。
 
对新系统的数据进行一次物理备份，同时启动新系统数据库的重做日志功能。
 
到此时为止新旧系统数据转换工作全部结束，整个应用系统将切换到新系统上来运行。
 
第四阶段：新系统运行监控及数据整理
 
在所有新系统平稳运行后，还需要进行定期的运行监控以及对部分数据进行调整。对于那些对系统运行未造成影响的，在数据整理过程中，没有进行数据修正，所以在系统平稳运行后，需要对这些数据进行调整。
 
系统切换保障措施
 
系统在整个切换过程中，安全、平稳过渡是第一位的。我们将采用如下措施保证系统切换安全：
 
（1）数据备份
 
在进行新旧系统数据转换时，对原系统数据进行备份以保证历史数据的可追溯性。一旦在新系统中业务办理出现问题，则可以通过追溯历史数据来判断是数据转换错误，还是新系统程序存在BUG。
 
（2）数据测试
 
数据测试分为两个层次测试，一个是数据监测性测试，就是在数据转换完成后，测试数据的转换正确性；二是验证性测试，验证性测试通过使用已经通过功能测试的新系统办理实际业务来验证数据转换的正确性。
 
数据测试是一个关键环节，关系到系统切换的成功与否，所以必须加大测试力度来保证数据转换的正确性。而与数据测试相关的系统功能测试也必须重视，因为如果系统功能如果存在问题，则数据测试也就无法保证正确性。
 
（3）切换点的选择
 
系统在什么时候进行切换，也是一个很关键的问题。一般情况下，我们都选择一个业务周期结束，下一个业务周期开始的时候进行切换。
 
（4）切换方式的选择
 
系统切换有两种方式，一种是新旧系统并轨运行，一种是新系统单轨运行。对于第一种方式旧系统为主，新系统为辅，在时机成熟的时候在切换到新系统运行；第二种是以新系统为主，旧系统为辅，旧系统只是验证新系统业务办理的正确与否。第一种方式安全系数由于过渡期时间会很长，业务人员工作量很大，而第二种由于直接采用新系统，存在一定的风险，我们可以通过加大测试力度来降低风险。综上所述，我们建议采用第二种方式，就是新系统为主，原系统为辅的方式。
 
 
 
十、 试运行
 
将系统部署在政务云上，进行试运行，试运行期间，新旧系统并轨运行，试运行期间无任何问题后，慢慢将业务过渡到新系统上正常使用。
 
 
 
十一、 信息化系统迁移适配保障
 
1、双轨并行
 
应用系统迁移全程按照“双轨并行、试点突破、符合实际、有效验证”的保障措施成功完成本次应用迁移。
 
建立现有运行环境和国产化运行环境的双轨运行模式，必须保证现有系统和国产化适配试点应用的协同联动，通过数据同步分发和一致性校验，使终端用户无论使用现有系统还是使用国产化终端应用，均能够获得一致的用户体验，确保所有应用操作在双运行环境间同步一致，所有单元功能的请求、响应正常、稳定，不对实际的业务处理结果产生实质性影响，保证混合环境运行的一致性和完整性。
 
2、数据备份
 
为了防范物理损坏导致的数据丢失问题，在数据安全方面，最重要的是保障数据的备份和恢复，尤其是在双环境分布式数据架构环境中，不仅需要使用国产数据库软件提供的备份工具进行本地备份，还需要开发不依赖于特定数据库基础软件的工具程序，将数据备份到指定的备份服务器上，使数据体系具备多个副本，尽可能保证在设备异常情况下，能够及时恢复数据，维系应用系统的不间断运行。
 
 
 
作者：宁桂华

每个公司的服务器运行的服务和管理的方式都不一样，在此简单总结一下前段时间迁移服务器所做的工作。
 
第一步 确定服务器运行的服务
 切换到root权限，netstat -tunlp可查看所有进程。弄明白所有进程的作用，并确保迁移新服务器启动旧服务器的所有进程。注意有一些是服务器自身进程，如网络同步时间进程ntpd,在新的服务器上可能已切换为chronyd等等，请不要过于执着。
 
第二步 迁移nginx服务
 进入/etc/nginx/conf.d/里面，下载所有的*conf 的nginx配置。确保每个conf配置的域名，在新服务器上能成功访问。
 
第三步 定时任务
 查看当前所有定时任务： crontab -l
 编辑定时任务：crontab -e
 如果没安装：(centos 默认已安装）
 yum install crontabs
 systemctr start crond
 编辑完后使用reload使任务生效： systemctr reload crond
 
因为我们是用docker搭建服务器，所以代码迁移，项目迁移都比较方便，直接docker-compose文件迁移，然后重新建image，container。
 docker-compose pull 项目名
 docker-compose up -d 项目名
 docker-compose start 项目名
 
这里写一些常用的进程或备份
 hub.docker.com 这里面有docker镜像
 git的备份：
 docker-compose 配置参考:
 version: “3.3”
 services:
 gitlab-ce:
 container_name: gitlab-ce
 image: hub.docker.com寻找您要的镜像
 ports:
 - “9086:22”
 - “9087:80”
 volumes:
 - ./gitlab-ce/data:/data
 
备份：
 进入docker容器：docker exec -it gitlab-ce[容器名] bash
 创建备份：gitlab-rake gitlab:backup:create
 将备份移动到容器外面：注意这里的docker-compose配置的volumes是 /data文件夹软链接到外面，所以将备份移动到/data里面，mv /gitlab-ce/data/backups/备份名称 /data/
 
恢复备份：
 进入docker容器：docker exec -it gitlab-ce[容器名] bash
 恢复备份：
 将上面备份的文件，mv到 /gitlab-ce/data/backups/里面，然后运行命令
 gitlab-rake gitlab:backup:restore
 
修改git clone的地址配置，
 /gitlab-ce/conf/gitlab.rb 配置修改 external_url ‘git.wyuyung.com（您的ngnix配置域名）’ 和 gitlab_rails[‘gitlab_shell_ssh_port’] = 9086（对应docker-compose文件的port）
 external_url是您外部访问的域名链接，例如我搭建了服务器，并将域名git.wyuyung.com指向为我的git代码库UI管理域名127.0.0.1:9086.
 
安装文件分布式系统weed-fs
 自行去github下载weed运行程序，可以不用源码。
 启动服务 nohup ./weed master -port=9333 &
 启动读文件服务 nohup ./weed volume -port=8080 -dir=./data -ip=img.wyuyung.com[您的文件域名，ngnix搭配proxy_pass http://127.0.0.1:8080;] -mserver=localhost:9333 &
 
nginx 的conf文件编写
 这里举个最简单的例子：
 一般不要改默认端口，不然您会发现搭建工程的时候，很多默认配置都要重新配置，大牛随意。
 
server {
    listen       80;  //http默认访问端口
    listen 443 ssl;   //https默认访问端口
    server_name  www.wyuyung.com;  //域名
    
    //[参考如何生成您的ssl证书](https://github.com/Neilpang/acme.sh/blob/master/dnsapi/README.md#1-use-cloudflare-domain-api-to-automatically-issue-cert)
    ssl_certificate /etc/nginx/ssl/wyuyung.com.cert;  //您的ssl证书，
    ssl_certificate_key /etc/nginx/ssl/wyuyung.com.key;  //您的ssl证书，
    
    location / {   //这是入口，一般都在location /中配置前端项目入口。
        index index.html index.htm index.php;
        root /data/www/;
    }
    location ~ \.php$ {   //这里是适配php的项目，有兴趣的自行去拓展阅读，默认直接copy使用就可以了。
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include        fastcgi_params;
    }
}
 
*使用 location /yung/ { //这是入口，一般都在location /中配置前端项目入口。
 index index.html index.htm index.php;
 root /data/w/;
 }
 这种配置的要注意，这里的入口是/data/w/yung/index.html 而不是/data/w/index.html location匹配虽然匹配了location /yung/，但是/yung/依然有效。很多人认为www.wyuyung.com/yung/ 匹配 location /yung/ ，对应 root /data/w/; 实则不然。真正应该这么理解：www.wyuyung.com/yung/ 匹配 location /yung/，所以www.wyuyung.com对应的root地址是/data/w/。后面的yung需要再解释，而不是解释域名的时候就消耗掉了。
 
安装php支持环境
 yum install php可能会安装很老的版本，建议使用：
 yum install php70w php70w-devel php70w-cli php70w-common php70w-gd php70w-ldap php70w-mbstring php70w-mcrypt php70w-pdo php70w-mysql php70w-fpm
 如果报错没找到源，那么请更新一下yum安装包：
 rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
 rpm -Uvh https://mirror.webtatic.com/yum/el7/webtatic-release.rpm
 然后再运行
 yum install php70w php70w-devel php70w-cli php70w-common php70w-gd php70w-ldap php70w-mbstring php70w-mcrypt php70w-pdo php70w-mysql php70w-fpm
 
域名nginx配置要加上：
 location ~ .php$ {
 fastcgi_pass 127.0.0.1:9000;
 fastcgi_index index.php;
 fastcgi_param SCRIPT_FILENAME $documen{t}_{r}oot$fastcgi_script_name;
 include fastcgi_params;
 }
 
备份禅道
 第一步：备份禅道的sql ,例：
 mysqldump -u root -p zentao > zentao.sql
 
第二步：到新服务器的mysql中，恢复sql。mysql -u root -p zentao < zentao.sql
 这里可能会报错，因为您要先到mysql中创建一个空的zentao数据库，然后再将旧数据导入进新建的数据库中。例外如果您不想zentao使用root用户登录，可以新建一个sql用户，然后将zentao数据库授权给该用户。
 create database zentao;
 CREATE USER ‘zentao’@’%’ IDENTIFIED BY ‘用户密码’;
 GRANT ALL ON zentao[数据库名].* TO ‘zentao’【用户名】@’%’;
 %是允许外部访问，localhost是只允许内部访问
 
第三步：下载一个同版本的zentaopms，修改zentaopms/config/my.php配置sql的用户名、密码、数据库名

应用系统适配迁移是一个艰巨、繁杂的过程，需要在充分调研的基础上统筹规划推动，在长期的项目适配过程中总结出一套行之有效的方法论，简单归纳如下：
 
1、 系统现状评估
 
2、 系统适配
 
3、测试验证、迁移
 
1、系统现状评估
 
系统现状的评估包含三个方面的内容：硬件评估、基础软件评估和应用软件调研。
 
1.1 硬件评估
 
硬件包括整机和关键元器件。整机主要是PC终端、服务器、交换机、存储设备；关键元器件有CPU、磁盘、显卡等。其中的核心是CPU，它是计算机系统的心脏。而国产化对于CPU的设计、代工、生产、封测各环节都有相应的要求。在PC机和服务器CPU中，x86架构占据了绝对优势地位。
 
1.2 基础软件评估
 
基础软件评估对象主要有操作系统、数据库、中间件。
 
1.3 操作系统
 
操作系统是计算机系统的内核与基石，主要管理硬件与软件资源，对于上层软件的架构、开发等有决定性影响，可以说操作系统决定了整个软件生态。由于历史的原因，目前PC机领域几乎被windows垄断，服务器领域主要是linux或其他类unix系统。
 
1.4 数据库
 
数据库主要提供了数据存储和管理功能，是现代信息系统的核心组成部分，为其提供数据支撑服务。数据库的配置（cpu/内存/存储）、并发度、主备架构、读写分离等功能特性对于整个信息系统的功能、性能有着决定性的影响。目前信息系统中最常用的数据库主要有Oracle、SQL Server、MySQL。
 
1.5 中间件
 
中间件是介于应用程序和操作系统之间的一类软件，它屏蔽了底层操作系统的复杂性，使程序开发人员面对一个简单而统一的开发环境，将注意力集中在自己的业务上，减少了程序设计的复杂性。中间件种类繁多，最常用的主要有消息中间件和应用服务器中间件。
 
1）消息中间件
 
消息中间件利用高效可靠的消息传递机制进行平台无关的数据交流，并给予数据通信来进行分布式系统的集成。其最突出的特点是提供数据传输的可靠性与高效性，主要解决分布式系统的数据传输需求。其主要作用如下：
 
应用解耦——将传统的紧耦合（如函数调用）方式用松耦合（消息发布/订阅）方式代替，确保服务调用方的问题不会扩散到服务提供方（或反之），最大限度提升系统整体可用性。
 
异步调用——尽量用异步掉头代替同步调用，提高效率。
 
流量削峰——在访问量急剧增加的情况下，利用消息中间件的缓存能力，保证程序不会因为突发的超负荷请求而崩溃。
 
2）应用服务器中间件
 
应用服务器又称为应用服务器软件平台，是为应用程序提供业务逻辑的代码，通常基于组件，位于以服务器为中心的架构的中间层，该架构主要基于web，与应用服务器相对应的还有web服务器。简单来说，web服务器只负责处理http协议，只能发送静态 页面的内容；而jsp、asp、php等动态内容需要通过CGI等接口交给其他程序去处理，这个其他程序就是应用服务器，也就是能实现动态网页技术的服务器。
 
1.6应用软件调研
 
应用软件调研主要是了解软件的架构、插件、开发语言等，以便对应用软件适配难度进行初步评估。应用软件调研结果可记录如下表：
 
 
序号
 
 
应用名称及版本
 
 
应用用途
 
 
应用使用范围
 
 
B/S、C/S或单机应用
 
 
浏览器控件
 
 
配套外设（品牌、型号）
 
 
应用来源
 
 
应用开发商
 
 
开发语言
 
 
所需环境（数据库、）
 
 
1
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
2
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
3
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
4
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
5
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
注：
 
1）B/S模式：终端用浏览器方式打开；C/S模式：终端用客户端软件打开
 
2）控件（或插件、组件）：使用过程中浏览器需要加载的程序
 
3）配套外设：使用过程中需要用到的打印机、扫描仪、扫码枪等外设
 
4）应用来源：本单位应用/上级单位应用/平行单位应用
 
1.7 应用架构
 
通常应用架构主要分为C/S、B/S两种架构，简要介绍如下：
 
1） C/S架构
 
C/S架构即客户机-服务器（Client-Server）架构。C/S为两层结构，服务器负责数据的存储和管理，客户机负责完成与用户的交互。客户机通过网络与服务器相连，接受用户的请求，并通过网络向服务器提出请求，对数据库进行操作；服务器接受客户机的请求，将数据提交给客户机，客户机将数据进行计算并将结果呈现给用户。
 
2） B/S架构
 
B/S架构即浏览器-服务器（Browser-Server）架构，是从C/S架构改进而来，可以说是三层C/S架构。
 
第一层是浏览器，相当于客户端，只有简单的输入输出功能，处理极少部分的事务逻辑。由于客户不需要安装客户端，只需浏览器就能上网流量，所以它面向的是大范围的用户，界面设计简单、通用。
 
第二层是web服务器，扮演着信息传送的角色。当用户想要访问数据库时，就会首先向web服务器发送请求，web服务器同意请求后会向数据库服务器发送访问数据库的请求，这个请求是以SQL语句实现的。
 
第三层是数据库服务器，它存放着大量的数据。当数据库服务器收到了web服务器的请求后，会对SQL语句进行处理，并将返回的结果发送给web服务器，接下来web服务器将收到的数据结果转换为html格式发送给浏览器，于是呈现我们打开浏览器看到的界面。
 
B/S架构浏览器请求、服务器响应的工作模式。用户可以通过浏览器去访问Internet上由web服务器产生的温备、数据、图片、动画、声音和视频等信息，而每一个web服务器有可以通过各种方式与数据库服务器连接，大量的数据实际存放在数据库服务器中。
 
B/S架构下，应用的主要事务逻辑在Server端实现，极少部分事务逻辑在Browser实现，其最大的优点是总体 拥有成本低、维护方便、分布性强、开发简单，无需安装任何专门的软件就能实现在任何地方进行操作，客户端零维护，系统扩展性非常强。随着web技术的飞速发展以及人们对网络的依赖程度加深，B/S一举成为当今最流行的应用架构。
 
1.8 插件
 
在B/S架构下，浏览器基本只承担最基本的输入输出功能，总会出现一些web端解决不了的情况，比如操纵硬件或本地文件，浏览器插件是上述情况下一种有效的解决手段。即使html5的出现增强了web端的功能，但是就目前技术和发展趋势来看，浏览器插件技术无法被替代。
 
插件是一种遵循一定规范的应用程序接口编写出来的程序。很多软件都有插件，插件有无数种。例如在浏览器中安装相关插件后，web浏览器能够直接调用插件程序，用于处理特定类型的文件。浏览器插件，是基于浏览器的原有功能，另外增加新功能的工具，常见的插件有flash插件、RealPlayer插件、MMS插件、ActiveX插件等。
 
插件的定位是开发一个实现原有纯净系统平台、应用软件平台不具备的功能的程序，其只能运行在程序规定的系统平台下（可能同时支持多个平台），而不能脱离指定的平台单独运行，因为插件需要调用原有纯净系统提供的库函数或者数据。
 
2、 系统适配
 
2.1 终端适配
 
终端作为日常办公的载体，除了常用的办公软件之外，还需要访问一些后台应用，或者连接打印机等一些外设。因此终端的适配可分为终端常用工具软件适配、应用系统客户端适配和外设适配。
 
2.2 常用工具软件适配
 
PC终端经过多年发展，已经拥有了种类繁多的通用工具软件，要实现终端的国产化，必须做到常用工具软件的国产化，为此需要对工具软件一一进行适配。终端上工具软件的适配本质上是对操作系统的适配，目前PC终端的操作系统基本上被windows占据，所以需要相关的软件厂商针对国产类linux操作系统重新开发、编译并打包发布相应的国产化软件包。
 
经过多年的发展，目前大致完成了以下对多种工具类软件的适配工作：
 
Ø 办公软件
 
Ø 输入法
 
Ø 安卓兼容
 
Ø 网络软件
 
Ø 邮件
 
Ø 即时通讯软件
 
Ø 图片类软件
 
Ø 影音软件
 
Ø 光盘刻录
 
Ø 扫描工具
 
Ø 杀毒软件
 
Ø 压缩/解压缩
 
Ø 文件管理类
 
Ø 远程工具
 
Ø 开发工具
 
Ø 备份还原
 
Ø 文档处理
 
Ø 安全类软件
 
2.3应用系统客户端适配
 
终端访问后台应用主要可分为以下几种方式：
 
1）客户端访问——应用为C/S架构，以往x86平台上，操作系统绝大部分为windows系统，替换为国产化终端后，CPU架构和操作系统都发生了变化，应用客户端软件的适配需要应用开发厂商深度参与，通常需要修改远吗并重新编译打包，适配成本较大。
 
2）浏览器访问——应用为含插件的B/S架构，适配主要考虑插件的适配，如果采用的是商业插件，还需支付插件的购买费用，同时需要应用开发厂商参与，可能需要修改远吗，难度相对较小，适配成本不大。
 
3）浏览器访问——应用为不含插件的B/S架构，基本可以直接跨平台迁移，适配较少需要应用开发厂商参与，适配成本小。
 
2.4外设适配
 
外设适配主要进行外设硬件驱动程序和操作系统的适配。以往x86平台上，windows驱动程序居多，而linux驱动程序较少。终端国产化以后，在PK体系下，CPU采用arm架构，操作系统为类linux系统，驱动程序需要厂家深度参与，修改并重新编译，适配成本较大。
 
2.5服务端适配
 
 适配内容
 
服务端适配指应用系统在国产平台上的部署适配，涉及CPU架构、操作系统、数据库、中间件和应用软件的适配。
 
目前，针对国产CPU平台、国产操作系统、国产数据库、国产中间件已经完成了三类基础软件的适配。另外，开源软件在许多业务系统中广泛使用，国产CPU平台也完成了业界主流基础软件的适配，比如开源操作系统Debian、Ubuntu、Fedora、CentOS、开源数据库MySQL、开源中间件tomcat等。
 
服务端适配的关键取决于应用的跨平台移植性，而移植性主要与开发框架、编程语言有关：
 
1）.Net架构
 
.Net是微软开发并主推的软件开发平台，主要应用在windows操作系统上而且未使用虚拟机机制，强烈依赖于windows操作系统。由于国产CPU平台上的操作系统都是类linux系统，.net应用程序的适配基本上要重新开发，适配成本较高。
 
2）C/C++语言
 
C/C++语言具有较高的可移植性，基于C/C++开发的应用程序，可以少量修改源代码，编译后平滑移植到国产CPU及国产操作系统上，适配成本较低。
 
3）Java语言
 
使用Java语言开发的应用程序是运行在Java虚拟机上的，不论什么操作系统，只要有java虚拟机都是可以运行的，与操作系统无关，因此java开发的应用程序具有良好的平台移植性，无需修改（或少量修改代码）就可以直接运行在国产化CPU平台上。除java外，还有其他跨平台开发语言，比如python、perl、ruby等，这些跨平台开发语言开发的应用软件，可以平滑移植到国产化CPU和国产操作系统上，适配成本低。
 
适配模式
 
服务端适配根据规模和预算情况可以分为物理机模式和云模式。
 
1、物理机模式
 
IT基础资源采用物理服务器承载的优点是部署简单，运维技术难度低，在规模比较小的时候投入成本小；缺点是系统可靠性不高，后续系统扩容困难，在规模比较大的时候资源浪费严重。所以IT基础资源采用物理服务器承载的方式适用于规模小预算有限的情况。
 
2、云模式
 
IT基础资源采用私有云平台承载的优点是系统可靠性高，后续扩容简单，随着规模的扩大，资源利用率高；缺点是初始投入成本高，初期运维技术难度大。所以IT基础资源采用私有云平台承载的方式适用于规模较大、预算充足的情况。
 
考虑到很多用户当前已经部署了基于x86的私有云或是vmware的虚拟化集群，为了降低运维管理的复杂度，可以采用国产PK云与现有x86云融合部署的方式。PK云具备纳管x86异构资源池和vmware虚拟化集群的能力，随着业务系统的适配迁移逐渐完成，x86云最终被PK云替换。
 
2.6 应用适配
 
应用系统软件架构可分为C/S架构和B/S架构，无论何种架构，适配内容都可分为终端适配和服务端适配。
 
用户可根据应用系统技术栈的实际情况结合自身技术、预算等综合规划考虑采用何种方式推进适配进程。通常的适配方式有：1）终端适配现行，服务端适配暂缓；2）终端适配和服务端适配同步进行。
 
3、 测试验证、迁移
 
适配完成后，按照生产环境要求搭建验证环境，将现有应用系统的数据导入验证环境进行高仿验证。
 
高仿验证完成后，导入业务流量试运行，试运行后将验证环境转为生产环境。
 
 
 
作者：申志超

无论你是移动开发者，还是桌面端开发者，或者正在IoT领域探索的技术人员，那么应该更加关注 iDev 全平台开发者大会，也许是后半年 iOS 开发者最盛大的技术盛宴。既有知名公司带来专业视野，又有从 Swift 到函数式编程、HomeKit， watchOS 开发、 macOS 内核探索等技术分享，非常值得去听一听。PS：fir.im 为大家争取了当前票价款额外 8 折优惠，感兴趣的朋友去这里购买.
 
除此之外，本期 fir.im Weekly 重点整理了关于 swift3 适配、开发、迁移的实战经验和 iOS/Android 相关的技术干货，一起来看看。
 
『 Swift3 适配、开发、迁移 』
 
Swift 3 改动总结
 
no-computer 花了近 3 天时间，12956 行增改，9817 行删减，把近 360 个文件 的Swift 项目的代码全部迁移，并把整个实战过程分享出来。这篇文章也从语言使用的角度上，Swift 3 到底有哪些改变和新特性。
 
文章传送门。
 
Swift 3 迁移工作总结
 
Swift 3.0 正式版发布了差不多快一个月了，@王浙剑 把手上的项目都迁移到了 Swift 3.0，并写出了些总结，详情见链接。
 
适配 Swift 3 的一点小经验和坑
 
图拉鼎 前段时间发布了基于 Swift 3.0 的奇点 2.1.1 版本，主要是适配了 Swift 3.0 + 一些 Bug 修复。分享了一些小经验和坑，相信有同学也会遇到这些问题，链接在这里。
 
《Swift 3必看》系列
 
没故事的卓同学的这一系列篇文章，总结了学习 Swift 3 的整笔记，如果想看其他相关文章可前往《Swift 3必看》系列目录感兴趣的点击这里。
 
Swift 3.0 Unsafe World
 
@图拉鼎 推荐了一篇如何用 Swift 3 来操作 C 指针的文章—— Swift 3.0 Unsafe World，如果你既想用 Swift 的高效、安全和灵活，又要与 C 库打交道，这篇文章一定要看。
 
使用 RxSwift 进行响应式编程
 
@RealmChina分享了在 AltConf 2016的Scott Gardner关于如何使用RxSwift 的进行响应式编程，详情点击这里。
 
 
 
@靛青K 也分享了自己研究出一个 Demo 供大家学习，见这里.
 
 
 
iOS 应用架构现状分析
 
@iOS大全 分享的这篇文章围绕 iOS 架构这一主题，结合几种主流方式，再配以自己的理解，做下现状分析。希望为大家带来新的思考。 
 
iOS开发中的HTTPS
 
@_TongJZ分享的这篇文章，基于SSL/TLS协议的HTTPS通信运行机制，实践iOS端到服务器端的安全通信，文章传送门。
 
IGListKit - Instagram 开源UICollectionView框架
 
南峰子_老驴 在微博上分享的，Instagram出品的 UICollectionView框架，GitHub 地址: IGListKit。
 
『Android 相关』
 
Android事件分发机制详解
 
@GcsSloop的这篇文章将带领大家从应用的角度理解事件分发值得一看！文章链接。
 
 
Android App优化之网络优化
 
网络优化，App 优化中不可缺少的一个优化项 。anly-jun 分享了自己在这方面的经验，干货十足，有需求的同学可以来这里看看。
 
项目组件化之遇到的坑
 
来自泥阿布_Abner的分享。
 
“ 需要做的事情很简单，就是将业务解耦模块化，让这个模块在debug下作为application单独运行，而在release下就作为library。”全文浏览，点击这里.
 
FreshDownloadView - Download 动画
 
来自于@Pitt_eat_Pizz分享的一个下载动画，下载完成和失败的时候会有酷酷的动画，GitHub 地址: FreshDownloadView.
 
 
 
这期的 fir.im Weekly 就到这里，投稿请联系 dm[at]fir.im.
 
欢迎分享更多的内容。
 
fir.im