1.本技术涉及计算机
技术领域：
：，尤其涉及一种切换系统架构的方法与装置。
背景技术：
：：2.不同的应用场景对计算机系统的安全与通信性能的要求不同。例如，在系统与用户交互的场景下，需要防范异常的输入或攻击，即这种应用场景对系统安全的要求较高，这时的系统架构应该为高安全架构；在系统与用户交互完成后，需要进行大量计算，即这种应用场景对通信效率的要求较高，这时的系统架构应该为高性能架构。因此，面对不同的应用需求，需要设计不同的系统架构。3.现有技术提出一种方案，是在计算机系统内设计多种系统架构，根据应用场景使能所需的系统架构。但是，多实现一套系统架构就需要多一倍的代码，这导致代码开销较大，在物联网(internetofthings，iot)这类资源紧张的场景下，这是不可接受的。技术实现要素：4.本技术提供一种切换系统架构的方法与装置，通过可变形的系统架构实现系统架构的动态切换，使得可以只需一个系统架构即可实现不同架构的切换，因此只需用于实现这一个系统架构的代码，相对于现有技术，可以减小代码开销。5.第一方面，提供一种切换系统架构的方法，所述方法包括：将第一系统架构变形为第二系统架构，所述第二系统架构表示切换之前的系统架构，所述第一系统架构表示切换之后的系统架构；使用所述第二系统架构，为用户提供服务。6.所述第一系统架构与所述第二系统架构之间可互相变形，其中，所述第一系统架构与所述第二系统架构之间的关系为下列情况中的任一种或多种：所述第一系统架构中服务进程的特权级与所述第二系统架构中服务进程的特权级不同，所述第一系统架构中服务进程的数量与所述第二系统架构中服务进程的数量不同。7.应理解，通过可变形的系统架构实现系统架构的动态切换，使得可以只需实现一个系统架构即可实现不同架构的切换，因此只需用于实现这一个系统架构的代码，相对于现有技术，可以减小代码开销。8.可选地，可以根据应用场景对系统架构的需求，确定是否需要切换系统架构，在需要切换系统的情况下，使能系统架构的变形，即实现动态切换系统架构。这样可以在系统运行时动态满足应用场景对不同的系统架构的需求。9.由第一系统架构到第二系统架构的变形方式可以有多种。10.结合第一方面，在一种可能的实现方式中，所述第一系统架构包括第一服务进程；其中，所述将第一系统架构变形为第二系统架构，包括：改变所述第一服务进程的特权级。11.特权表示在计算机中执行与安全相关的功能的能力。具有执行安全相关功能特权的进程，被认为运行于特权态。不具有执行安全相关功能特权的进程，被认为运行于非特权态。特权态与非特权态是不同的特权级，不同级别的特权态也是不同的特权级。12.改变所述第一服务进程的特权级包括提权处理与降权处理。提权处理表示提升服务进程的特权级。降权处理表示降低服务进程的特权级。13.在本实现方式中，通过改变第一服务进程的特权级，实现了将所述第一系统架构切换为所述第二系统架构。其中，第一系统架构中第一服务进程的特权级与第二系统架构中第一服务进程的特权级不同。14.应理解，通过改变服务进程的特权级，实现了系统架构的动态切换。15.可选地，在本实现方式中，在不同特权级的地址不同的情况下，所述第一服务进程是采用数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制创建的。16.代码段支持地址无关的重定位的机制表示，无论服务进程的代码段的地址是否发生变化，都可以保证服务进程的运行。换句话说，服务进程的运行与代码段的地址无关。17.数据段支持地址无关的重定位的机制表示，表示，无论服务进程的数据段的地址是否发生变化，都可以保证服务进程的运行。换句话说，服务进程的运行与数据段的地址无关。18.可选地，所述第一服务进程的特权级包括第一特权级态与第二特权级态，其中，所述第一特权级态使用低地址，所述第二特权级态使用高地址；其中，所述数据段支持地址无关的重定位的机制包括，将所述第一服务进程的数据段始终映射在所述低地址。19.可选地，第一特权级态与第二特征级态中的一个表示非特权态，另一个表示特权态。20.可选地，第一特权级态与第二特征级态均为特权态，其中一个的特权级高于另一个的特权级。21.高地址、低地址是计算机领域里通用的概念。高地址与低地址是相对而言的，即相对地址编码的大小而言。22.所述将所述第一服务进程的数据段始终映射在所述低地址的操作包括：静态配置与动态维持。静态配置指的是，在所述第一服务进程运行之前，通过静态配置将所述第一服务进程的数据段映射在低地址。动态维护指的是，当在运行过程中所述第一服务进程的特权级发生变化(即引起数据段地址变化)，动态维持数据段仍然映射在低地址。23.可选地，所述数据段支持地址无关的重定位的机制包括对所述第一服务进程的数据段进行地址翻译处理，使得所述第一服务进程在特权级改变之后的数据段与在特权级改变之前的数据段映射至相同的地址；所述代码段支持地址无关的重定位的机制包括对所述第一服务进程的代码段进行地址翻译处理，使得所述第一服务进程在特权级改变之后的代码段与在特权级改变之前的代码段映射至相同的地址。24.可以采用硬件或软件的方式，对所述第一服务进程的代码段与数据段进行地址翻译处理。25.现有技术中，改变进程的特权级的方式为，先销毁旧的进程，再重新生效新的进程。即现有技术无法实现在服务进程运行过程中改变服务进程的特权级。26.在本技术中，通过采用数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制来创建服务进程，可以支持在服务进程的运行过程中动态改变服务进程的特权级，从而可以通过动态改变服务进程的特权级实现系统架构的动态切换。27.可选地，在通过动态改变服务进程的特权级来实现系统架构的动态切换的实现方式中，可以配置系统架构本身允许不同特权级使用相同的地址空间。28.应理解，通过服务进程的特权级的动态变化实现了服务进程的动态变形，从而实现了系统架构的动态变形，因此，可以实现系统架构的动态切换。29.结合第一方面，在一种可能的实现方式中，所述第一系统架构包括第一服务进程，所述第一服务进程被预先划分为多个组件，所述多个组件之间的数据不耦合；其中，所述将第一系统架构变形为第二系统架构，包括：基于所述多个组件，将所述第一服务进程拆分为多个子服务进程，其中，每个子服务进程包括所述多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。30.第一服务进程被预先划分为的多个组件之间的数据不耦合，表示，这多个组件之间进行访问时，通过函数接口进行成员访问，而不是对资源进行直接访问，或者对共享变量进行直接访问。31.基于所述多个组件，将所述第一服务进程拆分为多个子服务进程，可以视为，所述多个组件作为一个整体被拆分为多个子集，每个子集可隔离为一个新的服务进程(即由第一服务进程拆分得到的子服务进程)。32.在本实现方式中，通过将所述第一服务进程拆分为多个子服务进程，实现了将所述第一系统架构切换为所述第二系统架构。其中，第一系统架构中服务进程的数量不同于第二系统架构中服务进程的数量。33.应理解，通过服务进程的拆分变形，实现了系统架构的动态切换。34.结合第一方面，在一种可能的实现方式中，第一系统架构包括第二服务进程与第三服务进程，所述将第一系统架构变形为第二系统架构，包括：将第二服务进程与第三服务进程合并为第一服务进程。其中，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；且第二服务进程与第三服务进程分别是由该多个组件中的部分组件构成的，第二服务进程与第三服务进程所包括的组件不同。35.将第二服务进程与第三服务进程合并为第一服务进程，可以视为，所述第二服务进程中的组件与所述第三服务进程中的组件合并为所述第一服务进程。36.在本实现方式中，通过将所述第二服务进程与所述第三服务进程合并为所述第一服务进程，实现了将所述第一系统架构切换为所述第二系统架构。其中，第一系统架构中服务进程的数量不同于第二系统架构中服务进程的数量。37.应理解，通过服务进程的合并变形，实现了系统架构的动态切换。38.还应理解，通过服务进程的数量的动态变化实现了服务进程的动态变形，从而实现了系统架构的动态变形，因此，可以实现系统架构的动态切换。39.结合第一方面，在一种可能的实现方式中，所述第一系统架构包括第一服务进程，所述第一服务进程被预先划分为多个组件，所述多个组件之间的数据不耦合；其中，所述将第一系统架构变形为第二系统架构，包括：基于所述多个组件，将所述第一服务进程拆分为多个子服务进程，并改变所述多个子服务进程中一个或多个子服务进程的特权级，使得所述一个或多个子服务进程的特权级与所述第一服务进程的特权级不同，其中，每个子服务进程包括所述多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。40.所述一个或多个子服务进程的特权级与所述第一服务进程的特权级不同，也属于第一服务进程的特权级发生变化的情形。在不同特权级的地址不同的情况下，所述第一服务进程是采用数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制创建的。关于数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制，参见前文描述，这里不再赘述。41.在本实现方式中，通过将第一服务进程拆分为所述多个子服务进程，并改变所述多个子服务进程中一个或多个子服务进程的特权级，实现了将所述第一系统架构切换为所述第二系统架构。其中，第一系统架构中服务进程的数量与第二系统架构中服务进程的数量不同，并且，第一系统架构中服务进程的特权级与第二系统架构中服务进程的特权级也不同。42.应理解，通过服务进程的数量与特权级的动态变化，实现了服务进程的动态变形，从而实现了系统架构的动态变形，因此，可以实现系统架构的动态切换。43.实际应用中，采取上述哪一种或多种变形方式进行系统架构的切换，可以根据应用场景而确定。44.在本技术中，服务进程在运行时能够动态变形，例如，拆分变形、合并变形、提权变形或降权变形，这可以实现系统架构的动态变形。因此，本技术可以根据应用场景的变化自适应调整系统架构，从而可以在运行时动态满足应用场景对不同系统架构的需求。45.此外，在本技术中，一个系统架构能够支持不同种架构的变形，因此只需用于实现这一个系统架构的一份代码即可，从而可以减小代码开销。应理解，一份代码能够在服务不中断、业务不下线的前提下，针对应用场景较细粒度地调整系统架构，从而使得系统架构的切换更加灵活，底噪更小。46.结合第一方面，在一种可能的实现方式中，涉及到变形的服务进程的所有通信接口的参数传递规范(可简称为，传参规范)统一。该通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。47.函数调用通信接口表示函数调用对应的通信接口。特权级间通信接口表示特权级之间进行通信的通信接口。进程间通信接口表示进程之间进行通信的通信接口。48.涉及到变形的服务进程的所有通信接口的参数传递规范统一表示，所述服务进程的所有通信接口进行请求调用的传参规范统一，所有通信接口进行结果返回的传参规范也统一。或者，涉及到变形的服务进程的所有通信接口的参数传递规范统一还可以表述为，所述服务进程的各个通信接口的请求调用与结果返回的传参规范统一。49.本文提及的“传参规范统一”也可以表述为“传参规范一致”。50.在现有的在系统内实现多种系统架构的方案中，当切换系统架构时，原先的服务会先被停掉，新的服务重复重新启动。从业务侧来看，原先的服务请求会被打断，需要重新发起新的服务请求，服务也会有短暂的中断以同步之前的状态，即，现有技术在切换系统架构时无法做到业务的无感知。51.在本技术中，通过设置传参规范统一的通信接口，可以使得不同通信接口(不同通信接口的传参参数规范一致)的请求调用与结果返回可以相互替换，且这种替换不会造成服务中断，从而可以实现在系统架构动态切换时业务无感知。52.还应理解，通过设计参数传递规范统一的通信接口(例如，函数调用通信接口、特权级间通信接口、进程间通信接口)，这样可以摆脱在服务进程发生改变(即系统架构发生改变)后，通信上下文需要同步的问题。因为无需同步通信上下文，因此，可以实现业务无感知。53.此外，在系统架构切换时，因为无需进行状态同步，也可以避免引入额外的状态拷贝开销。54.可选地，在通过服务进程的拆分变形或合并变形实现系统架构动态切换的实现方式中，所述第一服务进程的所有通信接口、所述多个子服务进程中每个子服务进程的所有通信接口的参数传递规范统一；其中，所述通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。55.可选地，在通过服务进程的特权级变化实现系统架构动态切换的实现方式中，所述第一服务进程的所有通信接口的参数传递规范统一；其中，所述通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。56.结合第一方面，在一种可能的实现方式中，所述第一系统架构中所有通信接口以及所述第二系统架构中所有通信接口的参数传递规范统一；其中，所述通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。57.第二方面，提供一种切换系统架构的装置，所述装置包括切换单元与处理单元。所述切换单元，用于将第一系统架构变形为第二系统架构，所述第一系统架构表示切换之前的系统架构，所述第二系统架构表示切换之后的系统架构。所述处理单元，用于使用所述第二系统架构，为用户提供服务。其中，所述第一系统架构与所述第二系统架构之间的关系为下列情况中的任一种或多种：所述第一系统架构中服务进程的特权级与所述第二系统架构中服务进程的特权级不同，所述第一系统架构中服务进程的数量与所述第二系统架构中服务进程的数量不同。58.结合第二方面，在一种可能的实现方式中，所述第一系统架构包括第一服务进程；其中，所述切换单元用于，改变所述第一服务进程的特权级。59.可选地，在本实现方式中，在不同特权级的地址不同的情况下，所述第一服务进程是采用数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制创建的。60.可选地，所述第一服务进程的特权级包括第一特权级态与第二特权级态，其中，所述第一特权级态使用低地址，所述第二特权级态使用高地址；其中，所述数据段支持地址无关的重定位的机制包括，将所述第一服务进程的数据段始终映射在所述低地址。61.可选地，所述数据段支持地址无关的重定位的机制包括对所述第一服务进程的数据段进行地址翻译处理，使得所述第一服务进程在特权级改变之后的数据段与在特权级改变之前的数据段映射至相同的地址；所述代码段支持地址无关的重定位的机制包括对所述第一服务进程的代码段进行地址翻译处理，使得所述第一服务进程在特权级改变之后的代码段与在特权级改变之前的代码段映射至相同的地址。62.可选地，在通过动态改变服务进程的特权级来实现系统架构的动态切换的实现方式中，可以配置系统架构本身允许不同特权级使用相同的地址空间。63.结合第二方面，在一种可能的实现方式中，所述第一系统架构包括第一服务进程，所述第一服务进程被预先划分为多个组件，所述多个组件之间的数据不耦合；其中，所述切换单元用于，基于所述多个组件，将所述第一服务进程拆分为多个子服务进程，其中，每个子服务进程包括所述多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。64.结合第二方面，在一种可能的实现方式中，所述第一系统架构包括第一服务进程，所述第一服务进程被预先划分为多个组件，所述多个组件之间的数据不耦合；其中，所述切换单元用于，基于所述多个组件，将所述第一服务进程拆分为多个子服务进程，并改变所述多个子服务进程中一个或多个子服务进程的特权级，使得所述一个或多个子服务进程的特权级与所述第一服务进程的特权级不同，其中，每个子服务进程包括所述多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。65.结合第二方面，在一种可能的实现方式中，所述第一系统架构包括第一服务进程；其中，所述切换单元用于，改变所述第一服务进程的特权级；其中，所述第一服务进程的所有通信接口的参数传递规范统一；其中，所述通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。66.结合第二方面，在一种可能的实现方式中，所述第一系统架构包括第一服务进程，所述第一服务进程被预先划分为多个组件，所述多个组件之间的数据不耦合；所述切换单元用于，基于所述多个组件，将所述第一服务进程拆分为多个子服务进程，其中，每个子服务进程包括所述多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。其中，所述第一服务进程的所有通信接口、所述多个子服务进程中每个子服务进程的所有通信接口的参数传递规范统一；其中，所述通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。67.结合第二方面，在一种可能的实现方式中，所述第一系统架构中所有通信接口以及所述第二系统架构中所有通信接口的参数传递规范统一；其中，所述通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。68.第三方面，提供一种计算机系统，所述计算系统包括：系统架构，所述系统架构可变形为多种架构；处理器，用于控制所述系统架构的变形，并使用所述系统架构的一种变形架构提供服务。69.结合第三方面，在一种可能的实现方式中，所述处理器用于：将第一系统架构变形为第二系统架构，所述第一系统架构表示切换之前的系统架构，所述第二系统架构表示切换之后的系统架构；使用所述第二系统架构，为用户提供服务。其中，所述第一系统架构与所述第二系统架构之间的关系为下列情况中的任一种或多种：所述第一系统架构中服务进程的特权级与所述第二系统架构中服务进程的特权级不同，所述第一系统架构中服务进程的数量与所述第二系统架构中服务进程的数量不同。70.所述处理器用于执行第一方面提供的方法，具体描述详见第一方面的描述，这里不再赘述。71.第四方面，提供一种数据处理的装置，该装置包括：存储器，用于存储程序；处理器，用于执行存储器存储的程序，当存储器存储的程序被执行时，处理器用于执行上述第一方面中的方法。72.第五方面，提供一种计算机可读介质，该计算机可读介质存储用于设备执行的程序代码，该程序代码包括用于执行上述第一方面中的方法。73.第六方面，提供一种包含指令的计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述第一方面中的方法。74.第七方面，提供一种芯片，所述芯片包括处理器与数据接口，所述处理器通过所述数据接口读取存储器上存储的指令，执行上述第一方面中的方法。75.可选地，作为一种实现方式，所述芯片还可以包括存储器，所述存储器中存储有指令，所述处理器用于执行所述存储器上存储的指令，当所述指令被执行时，所述处理器用于执行上述第一方面中的方法。76.基于上述描述可知，通过可变形的系统架构实现系统架构的动态切换，使得可以只需实现一个系统架构即可实现不同架构的切换，因此只需用于实现这一个系统架构的代码，相对于现有技术，可以减小代码开销。77.此外，通过设置传参规范统一的通信接口，可以使得不同通信接口(不同通信接口的传参参数规范一致)的请求调用与结果返回可以相互替换，且这种替换不会造成服务中断，从而可以实现在系统架构动态切换时业务无感知。附图说明78.图1为高安全系统架构的示意图。79.图2为高性能系统架构的示意图。80.图3为本技术实施例提供的切换系统架构的方法的示意性流程图。81.图4为本技术实施例中通过服务进程的拆分变形或合并变形实现系统架构切换的示意图。82.图5为本技术实施例中通过服务进程的特权级的变化实现系统架构切换的示意图。83.图6为本技术实施例提供的支持地址无关的重定位的机制的示意图。84.图7为本技术实施例中通过服务进程的拆分变形或合并变形，以及服务进程的特权级的变化来实现系统架构切换的示意图。85.图8为本技术实施例中设置传参规范统一的通信接口的示意图。86.图9为本技术实施例提供的一个切换系统架构的例子的示意图。87.图10为本技术实施例提供的切换系统架构的方法的另一示意性流程图。88.图11为本技术实施例应用于文件系统的架构动态切换的示意图。89.图12为本技术实施例提供的切换系统架构的装置的示意性框图。90.图13为本技术实施例提供的切换系统架构的装置的另一示意性框图。91.图14为本技术实施例提供的计算机系统的示意图。92.图15为本技术实施例提供的计算机系统的另一示意图。具体实施方式93.不同的应用场景对计算机系统(下文简称为系统)的安全与通信性能的要求不同。例如，在系统与用户交互的场景下，需要防范异常的输入或攻击，即这种应用场景对计算机系统的安全的要求较高；在系统与用户交互完成后，需要进行大量计算，即这种应用场景对通信效率的要求较高。94.为了满足高安全的要求，系统架构需要保证较细粒度的错误隔离，目的是，当异常发生时，异常的服务进程行为不会影响到其他服务进程，或者，系统架构需要保证服务进程运行在非特权态。为了满足高通信性能的要求，系统架构需要保证服务进程之间具有一定的耦合，或者将服务进程运行在特权态，目的是，提高通信效率，和/或降低通信开销。因此，面对不同的应用需求，需要设计不同的系统架构。95.传统技术中，系统架构通常是静态的，即系统架构确定后，在系统运行时系统架构便不再改变。例如，系统架构固定为图1所示的高安全系统架构，或者，系统架构固定为图2所示的高性能系统架构。96.图1为高安全系统架构的示意图。在图1中，每个实线部分拥有独立的地址空间，相互隔离。该高安全系统架构包括微内核、内存、驱动、文件系统(filesystem，fs)、系统服务、其他服务与应用程序(application，app)，其中，微内核运行在特权态，内存、驱动、文件系统、系统服务与其他服务与app运行在非特权态。内存、文件系统、系统服务与其他服务均可以为服务进程。因为服务进程运行在非特权态，则可以保障系统安全。在图1所示系统架构中，内存、文件系统、系统服务与其他服务具有独立的地址空间，互相隔离。即在图1所示系统架构中，各个服务进程之间隔离(或称为解耦)，当异常发生时，异常的服务进程行为不会影响到其他服务进程，这可以保障系统安全。但是，隔离的各个服务进程之间的通信方式为进程间通信(inter-processcall，ipc)，这会增大通信开销，降低通信性能。97.图2为高性能系统架构的示意图。在图2中，每个实线部分拥有独立的地址空间，相互隔离。该系统架构包括为微内核、内存、文件系统、系统服务、其他服务与app，其中，微内核、内存、文件系统、系统服务、其他服务运行在特权态，app运行在非特权态。内存、文件系统、系统服务与其他服务均可以为服务进程。服务进程运行在特权态，使得服务进程可以直接访问某些硬件寄存器，这可以降低通信开销。在图2所示系统架构中，内存、文件系统、系统服务与其他服务位于相同地址空间中。即在图2所示系统架构中，服务进程之间是耦合的，这可以提高通信性能。但是，因为服务进程之间是耦合的，当某一服务进程行为出错时，与之耦合的其他服务进程都会受到影响，从而造成系统崩溃，降低安全韧性。98.固定的系统架构可以应对单一的应用场景，但是随着应用场景的复杂多变，可能会出现固定的系统架构无法满足应用场景的变化的问题。99.例如，在系统与用户交互(记为应用场景1)时，需要防范异常的输入或攻击，因此需要交互的服务进程之间解耦或隔离；当交互完成后，需要使用服务进程的数据进行大量计算(记为应用场景2)，这时需要尽可能提高与该服务进程的通信效率。若系统架构固定为图1所示的高安全系统架构，该系统架构可以满足应用场景1的需求，但是，不能满足应用场景2的需求。若系统架构固定为图2所示的高性能系统架构，该系统架构可以满足应用场景2的需求，但是不能满足应用场景1的需求。100.为了满足复杂多变的应用场景对系统架构的要求，一种在系统内实现多种系统架构的方案被提出来。具体为，在计算机系统内设计多种系统架构，根据应用场景使能所需的系统架构。但是，多实现一套系统架构就需要多一倍的代码，这导致代码开销较大，在物联网(internetofthings，iot)这类资源紧张的场景下，这是不可接受的。101.本技术提供一种切换系统架构的方案，通过可变形的系统架构实现系统架构的动态切换，使得可以只需一个系统架构即可实现不同架构的切换，因此只需用于实现这一个系统架构的代码，相对于现有技术，可以减小代码开销。102.为了更好地理解本技术实施例，先描述一些本技术实施例相关的术语。103.1、进程(process)104.计算机的核心是中央处理器(centralprocessingunit，cpu)，它承担了所有的计算任务，而操作系统是计算机的管理者，它负责任务的调度，资源的分配和管理，统领整个计算机硬件。应用程序(application，app)是具有某种功能的程序，程序是运行于操作系统之上的。105.进程是一个具有一定独立功能的程序在一个数据集上的一次动态执行的过程，是操作系统进行资源分配和调度的一个独立单位，是应用程序运行的载体。106.进程具有如下特征：107.动态性：进程是程序的一次执行过程，是临时的，有生命期的，是动态产生，动态消亡的；108.并发性：任何进程都可以同其他进程一起并发执行；109.独立性：进程是系统进行资源分配和调度的一个独立单位；110.结构性：进程由程序，数据和进程控制块三部分组成。111.2、进程上下文112.如前文对进程的概念介绍，进程运行是动态的。进程上下文是，进程运行这一动态过程中某一时刻的静态描述。例如，某一时刻的静态描述包括这一时刻与进程相关的cpu所有状态，例如，通常包括这一时刻该进程的通用寄存器、状态寄存器(savedprogramstatusregister，spsr)的状态等。spsr表示arm中保存程序状态(含特权级)的寄存器/程序状态寄存器。113.换句话说，进程运行这一动态若被暂定，则进程上下文为这一时刻与该进程相关的cpu所有状态。114.进程上下文被恢复时，cpu可以继续从被暂定的状态继续执行。115.3、服务116.传统技术中，一个进程对应一个服务。117.服务对应的进程可以称为服务进程。应理解，服务进程区别于应用程序(app)对应的进程。118.本技术实施例涉及的是服务对应的进程，因此，在本文中将进程记为“服务进程”。也就是说，本技术实施例中提及的服务进程表示服务对应的进程。119.4、组件120.本技术实施例中提及的组件表示，进程中最小粒度的处理单元。组件是代码和数据的集合。121.在本技术的一些实施例中，一个服务进程可以被划分为多个组件，这多个组件中的部分组件可以形成一个新的服务进程，其余的组件可以形成另一个新的服务进程。换言之，通过将一个服务进程划分为多个组件，可以实现将该服务进程变形(拆分)为多个新的服务进程，反之，拆分出来的多个服务进程也可以逆变(合并)为原服务进程。即一个服务进程内的组件的拆分与合并是可逆的。122.假设一个服务进程1被划分为组件1.1、组件1.2、组件1.3、组件1.4。一种变形过程为，组件1.1与组件1.2形成服务进程1.1，组件1.3与组件1.4形成服务进程1.2，即服务进程1被拆分为服务进程1.1与服务进程1.2。逆变形过程为，组件1.1、组件1.2、组件1.3、组件1.4可以重新合并为服务进程1，即服务进程1.1与服务进程1.2合并为服务进程1。具体参加下文中关于实施方式一的描述。123.应理解，服务是逻辑概念，服务进程与组件是实体概念。124.5、特权级、特权态与非特权态125.特权表示在计算机中执行与安全相关的功能的能力。具有执行安全相关功能特权的进程，被认为运行于特权态。不具有执行安全相关功能特权的进程，被认为运行于非特权态。特权态与非特权态是不同的特权级。126.在不同操作系统中，特权级的划分与定义不同，特权态与非特权态的含义不同。127.例如，在arm系统中，特权级包括用户态(exceptionlevel0，el0)与内核态(exceptionlevel1，el1)，或者，可信执行环境(trustedexecutionenvironment，tee)与通用执行环境(richexecutionenvironment，ree)。128.又例如，在x86系统中，特权级包括或用户模式权限(ring3)与特权模式权限(ring0)，intel系统的还可以划分特权级为根模式(rootmode)与非根模式(non-rootmode)等。129.再例如，amd系统的特权级可以包括访客模式(guestmode)与主机模式(hostmode)。130.需要说明的是，对于一个操作系统，其特权级、特权态与非特权态的定义与规范为现有技术，本文对此不作详述。131.根据操作系统的不同，特权级间通信的命令也不同。例如，arm系统中的特权级间通信的命令为可以为svc(supervisorcall)、hvc(hypervisorcall)或smc(securemonitorcall)；x86系统中的特权级间通信的命令为int80或系统调用(syscall)指令等。132.svc为arm架构下的用户内(el0)与内核态(el1)的通信方式，例如，系统调用的通信方式。hvc为arm架构下el0、el1与el2的通信方式。smc为arm架构下el0、el1与el3的通信方式。el表示arm架构下的权限级别的限制，其中，el0表示用户态，el1、el2与el3表示内核态下的不同权限的限制。133.6、进程间通信(inter-processcall，ipc)134.进程间通信表示，计算机系统中不同进程间传播或交换消息的方式。135.由于进程之间地址空间隔离，内核需要提供进程间通信的实现。136.进程之间进行通信的通信接口可以称为进程间通信接口(可以简称为ipc接口)。137.7、特权级间通信138.特权级间通信表示，特权态与非特权态之间的通信。139.特权级之间进行通信的通信接口可以称为特权级间通信接口。140.8、函数调用141.函数调用，表示计算机编译或运行时，使用某个函数来完成相关命令。142.函数调用对应的通信接口可以称为函数调用通信接口。143.下面将结合附图，对本技术中的技术方案进行描述。144.图3为本技术实施例提供的切换系统架构的方法的示意性流程图。例如，该方法的执行主体为处理器。该方法包括步骤s310与步骤s320。145.s310，将第一系统架构变形为第二系统架构，所述第一系统架构表示切换之前的系统架构，所述第二系统架构表示切换之后的系统架构。146.第一系统架构与第二系统架构之间可互相变形，其中，第一系统架构与第二系统架构之间的关系为下列情况中的任一种或多种：第一系统架构中服务进程的特权级与第二系统架构中服务进程的特权级不同，第一系统架构中服务进程的数量与第二系统架构中服务进程的数量不同。147.在当前系统架构为第一系统架构的情况下，当需要由第一系统架构切换为第二系统架构时，将第一系统架构变形为第二系统架构，从而实现由第一系统架构到第二系统架构的切换。这种情况下，第一系统架构表示切换之前的系统架构，第二系统架构表示切换之后的系统架构。148.应理解，在当前系统架构为第二系统架构的情况下，当需要由第二系统架构切换为第一系统架构时，将第二系统架构变形为第一系统架构，从而实现由第二系统架构到第一系统架构的切换。这种情况下，第二系统架构表示切换之前的系统架构，第一系统架构表示切换之后的系统架构。149.本文中以将第一系统架构变形为第二系统架构为例进行描述。150.将第一系统架构变形为第二系统架构，表示，第二系统架构是在第一系统架构的基础上变形得到的。第一系统架构与第二系统架构可以视为是同一个系统架构的不同变形。151.应理解，在本技术实施例中，只需实现一个系统架构，该系统架构可以支持多种变形。152.需要说明的是，在本技术实施例中，一个系统架构可以支持多种变形，例如两种或两种以上的变形。为了便于描述与理解，本技术实施例中以第一系统架构与第二系统架构这两种变形为例进行描述。153.还需要说明的是，第一系统架构与第二系统架构的命名仅为区分切换之前与之后的系统架构，没有特殊限定。例如，第一系统架构表示高安全系统架构，第二系统架构表示高性能系统架构，或者，反过来。实际应用中，可以根据应用需求确定系统架构的切换方式。154.s320，使用第二系统架构，为用户提供服务。155.本文提及的为用户提供服务，也可以表述为向应用程序(app)提供服务。156.应理解，在系统架构切换之前，是第一系统架构中的服务进程(记为服务进程1)提供服务，在系统架构切换之后，是第二系统架构中的服务进程(记为服务进程2)提供服务。服务进程1提供的服务与服务进程2提供的服务对应逻辑上的同一个服务。例如，系统架构切换之前，由服务进程1向app1提供服务，系统架构切换之后，由服务进程2向该app1提供服务。这里提及的服务进程1与服务进程2之间可互相变形，下文将描述。157.在本技术实施例中，通过可变形的系统架构实现系统架构的动态切换，使得可以只需实现一个系统架构即可实现不同架构的切换，因此只需用于实现这一个系统架构的代码，相对于现有技术，可以减小代码开销。158.应理解，本技术实施例相对于现有技术，不仅可以实现系统架构的动态切换，还可以降低代码开销。159.可选地，在步骤s310中，可以根据应用场景，确定是否需要切换系统架构，在需要切换系统的情况下，使能系统架构的变形。160.例如，在当前系统架构为第一系统架构的情况下，根据应用场景确定需要由第一系统架构切换为第二系统架构，则将第一系统架构变形为第二系统架构。161.作为一个示例。假设第一系统架构(即当前系统架构)表示高安全系统架构，第二系统架构表示高性能系统架构。若当前应用场景对系统的通信效率要求较高，则当前需要切换系统架构，即由第一系统架构变形为第二系统架构。应理解，若当前应用场景对系统的安全的要求较高，这种情况下无需切换系统架构。162.应理解，本技术可以在系统运行时动态满足应用场景对不同的系统架构的需求。163.第二系统架构为第一系统架构的变形，也就是说，第二系统架构与第一系统架构不同。第二系统架构与第一系统架构之间的不同之处可以包括下列情况中的任一种或多种：服务进程的数量不同，服务进程的特权级不同。164.由第一系统架构到第二系统架构的变形方式可以有多种。例如，可以包括下列任一种或多种：服务进程的拆分或合并，服务进程的特权级的改变(提权或降权)。具体如下文将描述的实施方式一、实施方式二与实施方式三。165.实施方式一：服务进程的拆分变形或合并变形166.可选地，在一些实施例中，第一系统架构包括第一服务进程，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；步骤s310包括：基于该多个组件，将第一服务进程拆分为多个子服务进程，其中，每个子服务进程包括多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。167.第一服务进程被预先划分为的多个组件之间的数据不耦合，表示，这多个组件之间进行调用时，通过函数接口进行成员访问，而不是对资源进行直接访问，或者对共享变量进行直接访问。168.基于该多个组件，将第一服务进程拆分为多个子服务进程，可以视为，该多个组件作为一个整体被拆分为多个子集，每个子集可隔离为一个新的服务进程(即由第一服务进程拆分得到的子服务进程)。169.需要说明的是，为了区分而非限定，将第一服务进程拆分得到的多个服务进程记为多个子服务进程。170.作为示例，如图4所示。服务进程1预先被划分为3个组件：组件1、组件2与组件3，其中，组件1、组件2与组件3之间的数据不耦合。组件1与组件2可以形成一个新的服务进程：服务进程1.1，组件3可以形成一个新的服务进程：服务进程1.2。因为不同进程的地址不同，即进程之间是隔离的，因此，可以视为，组件1与组件2隔离为服务进程1.1，组件3隔离为服务进程1.2。如图4所示，服务进程1可以拆分变形为服务进程1.1与服务进程1.2。服务进程1到服务进程1.1与服务进程1.2的变形是可逆的，即服务进程1.1与服务进程1.2也可逆变形为服务进程1。如图4所示，服务进程1.1与服务进程1.2可以合并变形为服务进程1。171.图4中的服务进程1可以对应第一服务进程，图4中的服务进程1.1与服务进程1.2可以对应由第一服务进程拆分成的多个子服务进程。172.应理解，服务进程的数量增加，必然导致系统架构发生变化。173.在本实施例中，将第一服务进程未拆分变形时的系统架构视为第一系统架构，将第一服务进程进行拆分变形后的系统架构视为第二系统架构。也就是说，通过服务进程的拆分变形，实现了系统架构的切换(由第一系统架构切换为第二系统架构)。174.在本实施例中，通过将所述第一服务进程拆分为多个子服务进程，实现了将所述第一系统架构切换为所述第二系统架构。其中，第一系统架构中服务进程的数量不同于第二系统架构中服务进程的数量。175.应理解，通过服务进程的拆分变形，实现了系统架构的动态切换。176.如前文描述，服务进程之间的变形是可逆的，即可以拆分变形，也可以合并变形。177.可选地，在一些实施例中，第一系统架构包括第二服务进程与第三服务进程，步骤s310包括：将第二服务进程与第三服务进程合并为第一服务进程，以将第一系统架构变形为第二系统架构。其中，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；且第二服务进程与第三服务进程分别是由该多个组件中的部分组件构成的，第二服务进程与第三服务进程所包括的组件不同。178.将第二服务进程与第三服务进程合并为第一服务进程，可以视为，所述第二服务进程中的组件与所述第三服务进程中的组件合并为所述第一服务进程。179.继续参见图4，图4中的服务进程1.1可以对应第二服务进程，图4中的服务进程1.2可以对应第三服务进程，图4中的服务进程1可以对应第一服务进程。也就是说，第二服务进程与第三服务进程合并变形为第一服务进程。180.应理解，服务进程的数量减少，必然导致系统架构发生变化。181.在本实施例中，将第二服务进程与第三服务进程未合并变形时的系统架构视为第一系统架构，将第二服务进程与第三服务进程进行合并变形后的系统架构视为第二系统架构。也就是说，通过服务进程的合并变形，实现了系统架构的切换(由第一系统架构切换为第二系统架构)。182.在本实施例中，通过将所述第二服务进程与所述第三服务进程合并为所述第一服务进程，实现了将所述第一系统架构切换为所述第二系统架构。其中，第一系统架构中服务进程的数量不同于第二系统架构中服务进程的数量。183.应理解，通过服务进程的合并变形，实现了系统架构的动态切换。184.因此，在本技术实施例中，通过服务进程的数量的动态变化实现了服务进程的动态变形，从而实现了系统架构的动态变形，因此，可以实现系统架构的动态切换。185.还应理解，一个服务进程被预先划分为彼此之间数据不耦合的多个组件，且基于这些多个组件，服务进程可以进行拆分变形与合并变形，这为一个系统架构既可以变形为高安全系统架构，又可以变形为高性能系统架构，提供了可能性。186.实施方式二：服务进程的特权级的改变(提权变形或降权变形)187.可选地，在一些实施例中，第一系统架构包括第一服务进程；步骤s310包括：改变第一服务进程的特权级。188.改变所述第一服务进程的特权级包括提权处理与降权处理。提权处理表示提升服务进程的特权级。降权处理表示降低服务进程的特权级。189.假设第一服务进程初始的特权级为非特权态，在需要切换系统架构时，可以将第一服务进程的特权级改为特权态。第一服务进程的这种变形可以称为提权变形。190.假设第一服务进程初始的特权级为特权态，在需要切换系统架构时，可以将第一服务进程的特权级改为非特权态。第一服务进程的这种变形可以称为降权变形。191.作为示例，如图5所示。在图5中，为了区分而非限定，将位于特权态的服务进程2记为服务进程2，将位于非特权态的服务进程2记为服务进程2'。如图5所示，服务进程2可以进行提权变形，即服务进程2的特权级由非特权态变为特权态；服务进程2也可以进行降权变形，即服务进程2的特权级由特权态变为非特权态。192.应理解，服务进程的特权级发生变化，必然导致系统架构发生变化。193.在本实施例中，将第一服务进程的特权级未发生变化时的系统架构视为第一系统架构，将第一服务进程的特权级发生变化后的系统架构视为第二系统架构。也就是说，通过服务进程的提权变形或降权变形，实现了系统架构的切换(由第一系统架构切换为第二系统架构)。194.在实施方式二中，通过改变第一服务进程的特权级，实现了将所述第一系统架构切换为所述第二系统架构。其中，第一系统架构中第一服务进程的特权级与第二系统架构中第一服务进程的特权级不同。195.在本技术实施例中，通过改变服务进程的特权级，实现了系统架构的动态切换。196.在某些系统架构下，不同特权级的地址不同，这种情况下，服务进程的特权级改变(降权变形或提权变形)，引起服务进程的地址(包括代码地址与数据地址)发生改变，因此会涉及到服务进程的重新加载与重定向的问题。例如，在arm架构下，内核态(el1)运行在高地址，用户态(el0)运行在低地址，当服务进程的特权级由内核态降权至用户态，其地址发生改变，即由高地址变为低地址。197.高地址、低地址是计算机领域里通用的概念。高地址与低地址是相对而言的，即相对地址编码的大小而言。本文对此不作详述。198.可选地，在涉及服务进程的特权级发生变化的实施例(例如，在上文描述的实施方式二或实施例方式三)中，在不同特权级的地址不同的情况下，第一服务进程是采用数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制创建的。199.代码段支持地址无关的重定位的机制表示，无论服务进程的代码段的地址是否发生变化，都可以保证服务进程的运行。换句话说，服务进程的运行与代码段的地址无关。200.数据段支持地址无关的重定位的机制表示，表示，无论服务进程的数据段的地址是否发生变化，都可以保证服务进程的运行。换句话说，服务进程的运行与数据段的地址无关。201.例如，可以根据系统架构，选择合适的地址无关的重定位的机制来创建服务进程。202.可选地，第一服务进程的特权级包括第一特权级态与第二特权级态，其中，第一特权级态使用低地址，第二特权级态使用高地址；其中，数据段支持地址无关的重定位的机制包括，将第一服务进程的数据段始终映射在低地址。203.可选地，第一特权级态与第二特征级态中的一个表示非特权态，另一个表示特权态。204.可选地，第一特权级态与第二特征级态均为特权态，其中一个的特权级高于另一个的特权级。205.将第一服务进程的数据段始终映射在低地址的操作包括：静态配置与动态维持。静态配置指的是，在第一服务进程运行之前，通过静态配置将第一服务进程的数据段映射在低地址。动态维护指的是，当在运行过程中第一服务进程的特权级发生变化(即引起数据段地址变化)，动态维持数据段仍然映射在低地址。206.作为示例，如图6中(b)所示。配置mmu，使得el0使用低地址的页表0，el1使用高地址的页表1。对于代码段，利用类似位置无关可执行程序(positionindependentexecutable，pie)的手段生成地址无关的代码段。对于数据段，则始终保持映射在低地址的页表0中。在arm架构中，当服务进程运行时，高地址页表1中的代码可以直接访问低地址页表0中的数据，反之则会被阻止。通过利用这一点，在本技术实施例中，通过保持数据段在低地址，并设置代码段地址无关，则可以在运行时对服务进程进行动态降权与提权，且不会影响程序执行。207.换句话说，在图6中的(b)所示的方法中，使用pie技术生成地址无关可执行文件时，数据段始终映射为低地址。当进程运行在不同特权级el1/el0时，仅代码段发生地址改变，数据段始终映射为低地址。208.因此，通过图6中(b)所示方法，能够保证在进程运行时改变进程的特权级，对代码和数据的访问不受影响。209.可选地，数据段支持地址无关的重定位的机制包括对第一服务进程的数据段进行地址翻译处理，使得第一服务进程在特权级改变之后的数据段与在特权级改变之前的数据段映射至相同的地址；代码段支持地址无关的重定位的机制包括对第一服务进程的代码段进行地址翻译处理，使得第一服务进程在特权级改变之后的代码段与在特权级改变之前的代码段映射至相同的地址。210.可以采用硬件或软件的方式，对所述第一服务进程的代码段与数据段进行地址翻译处理。211.作为示例，如图6中(c)与(d)所示。212.如图6中(c)所示，在非特权态使用低地址，特权态使用高地址的情况下，在硬件中引入地址处理模块(如图6中(c)所示的地址处理的方框)，使得高地址的代码段经过地址处理模块的处理后能够与低地址的代码段映射到同样的物理页中，使得高地址的数据段经过地址处理模块的处理后能够与低地址的数据段映射到同样的物理页中。这样，在第一服务进程运行时，第一服务进程地址的改变不会对硬件产生影响。213.因此，通过图6中(c)所示方法，能够保证在进程运行时改变进程的特权级，对代码和数据的访问不受影响。214.应理解，图6中(c)所示方法为采用硬件的方式对所述第一服务进程的代码段与数据段进行地址翻译处理。215.如图6中(d)所示，通过对代码和数据进行软件层面的翻译(对应于，图6(d)中所示的“中间翻译/地址处理”为中间翻译)，使得服务进程运行在不同特权级时，代码段与地地址段的地址经过软件层面的翻译，处理为正确的高地址与低地址，再利用翻译后的地址访问硬件的mmu。216.例如，对代码和数据进行软件层面的翻译的手段包括但不限于，利用虚拟化技术的影子页表、二级页表、或直接利用软件实现翻译表等手段。217.继续参见图6中的(d)，也可以通过对代码与数据进行硬件层面的翻译(对应于，图6(d)中所示的“中间翻译/地址处理”为地址处理)，使得服务进程运行在不同特权级时，代码段与地地址段的地址经过硬件层面的翻译，处理为正确的高地址与低地址，再利用翻译后的地址访问硬件的mmu。218.应理解，在图6中(d)中，若通过对代码和数据进行软件层面的翻译，则该方法为采用软件的方式对所述第一服务进程的代码段与数据段进行地址翻译处理；若通过硬件模块对代码和数据的地址进行处理，以到达翻译地址的目的，则该方法为采用硬件的方式对所述第一服务进程的代码段与数据段进行地址翻译处理。219.因此，通过图6中(d)所示方法，能够保证在进程运行时改变进程的特权级，对代码和数据的访问不受影响。220.现有技术中，改变进程的特权级的方式为，先销毁旧的进程，再重新生效新的进程。即现有技术无法实现在服务进程运行过程中改变服务进程的特权级。221.在本技术中，通过采用数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制来创建服务进程，可以支持在服务进程的运行过程中动态改变服务进程的特权级，从而可以通过动态改变服务进程的特权级实现系统架构的动态切换。222.可选地，在通过动态改变服务进程的特权级来实现系统架构的动态切换的实施方式中，可以配置系统架构本身允许不同特权级使用相同的地址空间。223.支持地址无关的重定位的机制包括：通过系统配置，使得系统架构本身允许不同特权级使用相同的地址空间。224.如图6中(a)所示，配置内存管理单元(memorymanagementunit，mmu)，使得用户态(el0)与内核态(el1)均使用同样的页表和基址寄存器。在这种方案下，不需要对编译的二进制进行特殊处理，改变进程的特权级不会产生异常影响。225.因此，通过图6中(a)所示方法，能够保证在进程运行时改变进程的特权级，对代码和数据的访问不受影响。226.应理解，图6中(a)所示的方案，使得用户态(el0)与内核态(el1)均使用同样的页表和基址寄存器，该方案可能会牺牲硬件提供的安全特性。227.应理解，可以采用图6中(a)、(b)、(c)、(d)所示的四种方法中的任一种方法来创建第一服务进程，这样可以支持在第一服务进程运行过程中动态改变第一服务进程的特权级。228.通过支持地址无关的重定位的机制，可以支持在运行时调整服务进程的特权级，即可以支持通过调整服务进程的特权级来切换系统架构。229.因此，在本实施例中，通过服务进程的特权级的动态变化实现了服务进程的动态变形，从而实现了系统架构的动态变形，因此，可以实现系统架构的动态切换。例如，根据应用场景的变化，在进程运行时对进程进行提权处理或降权处理。230.实施方式三，实施方式一与实施方式二的组合231.可选地，在一些实施例中，第一系统架构包括第一服务进程，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；步骤s310包括：基于多个组件，将第一服务进程拆分为多个子服务进程，并改变多个子服务进程中一个或多个子服务进程的特权级，使得该一个或多个子服务进程的特权级与第一服务进程的特权级不同，其中，每个子服务进程包括多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。232.作为示例，如图7所示。服务进程3预先被划分为3个组件：组件1、组件2与组件3，其中，组件1、组件2与组件3之间的数据不耦合。服务进程3的特权级为特权态。如图7所示，服务进程3可变形为服务进程3.1与服务进程3.2，其中，服务进程3.1的特权级为特权态，服务进程3.2的特权级为非特权态。服务进程3.1由组件1与组件2形成，服务进程3.2由组件3形成。因为不同进程的地址不同，即进程之间是隔离的，因此，可以视为，组件1与组件2隔离为服务进程3.1，组件3隔离为服务进程3.2。可以理解到，关于服务进程3.2，不仅进行了拆分变形，还进行了降权变形。即，在图7的示例中，服务进程的变形既包括服务进程数量的变化，还包括特权级的变化。233.在图7中，服务进程3到服务进程3.1与服务进程3.2的变形是可逆的，即服务进程3.1与服务进程3.2也可逆变形为服务进程3。该逆变形过程包括服务进程的合并变形与提权变形。234.应理解，本文中提及的逆变形是个相对概念。例如，在图7中，也可以将服务进程3.1与服务进程3.2的变形视为正变形，相应地，将服务进程3到服务进程3.1与服务进程3.2的变形视为逆变形。235.还应理解，服务进程的数量以及特权级发生变化，必然导致系统架构发生变化。236.在实施方式三中，第一服务进程拆分得到的一个或多个子服务进程的特权级与所述第一服务进程的特权级不同，也属于第一服务进程的特权级发生变化的情形。在不同特权级的地址不同的情况下，所述第一服务进程是采用数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制创建的。关于数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制，参见前文相关描述，这里不再赘述。237.在本实施例中，通过将第一服务进程拆分为所述多个子服务进程，并改变所述多个子服务进程中一个或多个子服务进程的特权级，实现了将所述第一系统架构切换为所述第二系统架构。其中，第一系统架构中服务进程的数量与第二系统架构中服务进程的数量不同，并且，第一系统架构中服务进程的特权级与第二系统架构中服务进程的特权级也不同。238.因此，在本实施例中，通过服务进程的数量与特权级的动态变化，实现了服务进程的动态变形，从而实现了系统架构的动态变形，因此，可以实现系统架构的动态切换。239.应理解，图4、图5与图7仅为示例而非限定。240.实际应用中，采取上述实施方式一、实施方式二与实施方式三中的哪一种方式进行系统架构的切换，可以根据应用场景确定。241.例如，应用场景对系统架构的安全的要求较高，而当前系统架构为高性能系统架构，这种情形下，可以采用如下操作中的任一种进行系统架构的切换。242.1)采用实施方式一进行服务进程的拆分变形，以保证更细粒度的错误隔离，例如，当异常发生时，出错的服务进程行为不会影响到其他服务进程。243.2)采用实施方式二进行服务进程的降权变形，使得服务进程运行在非特权态。244.3)采用实施方式三进行服务进程的拆分变形与降权变形(或二者之一)。245.又例如，应用场景对系统架构的通信效率的要求较高，而当前系统架构为高安全系统架构，这种情形下，可以采用如下操作中的任一种进行系统架构的切换。246.1)采用实施方式一进行服务进程的合并变形，可以实现服务进程之间具有耦合，减小通信开销，使得系统达到较好的性能。247.2)采用实施方式二进行服务进程的提权变形，使得服务进程运行在特权态。例如，使服务进程可以直接访问某些硬件寄存器，以降低通信的开销，248.3)采用实施方式三进行服务进程的合并变形与提权变形(或二者之一)。249.基于上述描述可知，在本技术实施例中，服务进程在运行时能够动态变形，例如，拆分变形、合并变形、提权变形或降权变形，这可以实现系统架构的动态变形。因此，本技术可以根据应用场景的变化自适应调整系统架构，从而可以在运行时动态满足应用场景对不同系统架构的需求。250.此外，在本技术实施例中，一个系统架构能够支持不同种架构的变形，因此只需用于实现这一个系统架构的一份代码即可，从而可以减小代码开销。应理解，一份代码能够在服务不中断、业务不下线的前提下，针对应用场景较细粒度地调整系统架构，从而使得系统架构的切换更加灵活，底噪更小。251.在现有的在系统内实现多种系统架构的方案中，当切换系统架构时，原先的服务会先被停掉，新的服务重复重新启动。从业务侧来看，原先的服务请求会被打断，需要重新发起新的服务请求，服务也会有短暂的中断以同步之前的状态，即，现有技术在切换系统架构时无法做到业务的无感知。252.针对该问题，本技术实施例提出，通过设置通信接口的参数传递规范(callingconvention)统一来解决。下面将进行描述。下文中，将参数传递规范简称为传参规范。本文提及的“传参规范统一”也可以表述为“传参规范一致”。253.可选地，在上述一些实施例中，涉及到变形的服务进程的所有通信接口的传参规范统一。该通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。254.函数调用通信接口表示函数调用对应的通信接口。特权级间通信接口表示特权级之间进行通信的通信接口。进程间通信接口表示进程之间进行通信的通信接口。255.涉及到变形的服务进程的所有通信接口的参数传递规范统一表示，服务进程的所有通信接口进行请求调用的传参规范统一，所有通信接口进行结果返回的传参规范也统一。或者，涉及到变形的服务进程的所有通信接口的参数传递规范统一还可以表述为，服务进程的各个通信接口的请求调用与结果返回的传参规范统一。256.通过设置传参规范统一的通信接口，可以使得不同通信接口(不同通信接口的传参参数规范一致)的请求调用与结果返回可以相互替换，且这种替换不会造成服务中断，从而可以实现在系统架构动态切换时业务无感知。下面参照图8进行说明。257.如图8中的(a)所示，当服务进程1在内核态(kernel态，如图8中的el1)时，服务进程1中的组件1与组件2之间通过函数调用进行通信。例如，组件1通过函数调用的方式向组件2调度请求，组件2通过函数调用的方式向组件1返回结果。当函数调用发起后，参数传递依据arm函数调用标准(armprocedurecallstandard，apcs)规范进行传递，被调用者根据调用信息开始进行计算。258.作为一个示例。当发生系统架构调整时，如图8中的(b)所示，服务进程1被拆分为服务进程1.1与服务进程1.2，其中，服务进程1.1由组件1形成，服务进程1.2由组件2形成，并且，服务进程1.2(例如，可以视为服务进程1中的组件2部分)被降权到用户态(el0)。当服务进程1.2完成计算后需要返回结果时，无法通过函数调用直接将返回结果返回到组件1(如图8中(b)所示的“结果返回受阻”)。259.如果设置进程间调用通信接口、特权级间调用通信接口、函数调用通信接口的参数传递规范统一(或称为参数传递规范统一)，则服务进程1.2的返回结果可以通过特权级间调用的形式返回到服务进程1.1，如图8中的(c.1)所示。260.作为另一个示例。当发生系统架构调整时，如图8中的(c.2)所示，服务进程1被拆分为服务进程1.1与服务进程1.2，其中，服务进程1.1由组件1形成，服务进程1.2由组件2形成，并且，服务进程1.1(例如，可以视为服务进程1中的组件1部分)与服务进程1.2(例如，可以视为服务进程1中的组件2部分)均被降权到用户态(el0)。在现有技术中，若发生如图8中的(c.2)所示的系统架构动态切换，服务进程1.2完成计算后是无法直接通过函数调用将结果返回到组件1的。但是，如果设置进程间调用通信接口、特权级间调用通信接口、函数调用通信接口的参数传递规范统一(或称为参数传递规范统一)，则服务进程1.2的返回结果可以通过进程间调用(ipc)的形式返回到服务进程1.1，如图8中的(c.2)所示。261.从上文结合图8的描述可知，通过设置传参规范统一的通信接口，可以使得不同通信接口(不同通信接口的传参参数规范一致)的请求调用与结果返回可以相互替换，且这种替换不会造成服务中断，因此，针对应用程序(app)的服务请求，可以使用不同的通信方式进行请求调用与结果返回，从而可以实现在系统架构动态切换时业务无感知。262.还应理解，通过设计参数传递规范统一的通信接口(例如，函数调用通信接口、特权级间通信接口、进程间通信接口)，这样可以摆脱在服务进程发生改变(即系统架构发生改变)后，通信上下文需要同步的问题。因为无需同步通信上下文，因此，可以实现业务无感知。263.例如，在系统架构切换时已经处理到一半的请求，可以在系统架构切换后继续处理。264.此外，在系统架构切换时，因为无需进行状态同步，也可以避免引入额外的状态拷贝开销。265.服务进程的通信接口的传参规范统一的实施例可以应用于上述的实施方式一、实施方式二与实施方式三。266.可选地，在上述实施方式一中，第一服务进程的所有通信接口、多个子服务进程中每个子服务进程的所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。267.在本实施例中，第一服务进程预先被划分为多个独立的组件，且各个组件之间的通信接口的传参规范统一(即各个组件之间使用统一传参规范的通信接口进行通信)。多个独立的组件表示，各个组件之间的数据不耦合，互相之间不直接访问资源，而是通过通信接口进行成员访问。268.应理解，在本实施例中，在通过服务进程的拆分变形或合并变形实现系统架构的动态切换时，可以实现业务无感知。269.可选地，在上述实施方式二中，第一服务进程的所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。270.应理解，在本实施例中，在通过服务进程的特权级的变化实现系统架构的动态切换时，可以实现业务无感知。271.可选地，在上述实施方式三中，第一服务进程的所有通信接口、多个服务进程中每个服务进程的所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。272.作为示例，如图9所示。图9中示出两种互相可变形的系统架构：第一系统架构与第二系统架构。图9中的a1、a4、b4表示特权级间调用；a2、a3、b3、b5表示进程间调用。在图9中，以app向服务进程2请求服务为例。服务进程2预先被划分为组件1与组件2，其中，组件1与组件2之间的数据不耦合(即解耦)。在图9中，通信接口a1、a4、b4、a2、a3、b3、b5以及服务进程2在未拆分变形之前所包括的组件1与组件2之间的函数调用通信接口的传参规范统一。273.参见图9中左图。在第一系统架构中，app通过特权级间调用a1向服务进程2请求服务；服务进程2通过进程间调用a2请求服务进程1；服务进程1在完成app所请的服务后，通过进程间调用a3将服务响应结果返回给服务进程2，服务进程2通过特权级间调用a4将服务响应结果返回给app。274.参见图9中左图与右图可知，第一系统架构到第二系统架构的变形方式为，服务进程2拆分变形为服务进程2.1与服务进程2.2，其中，服务进程2.1由组件1构成，服务进程2.2由组件2构成，服务进程2.1继续运行在内核态(el1)，服务进程2.2被进行了降权处理，运行在用户态(el0)。275.假设在服务进程2中，是由组件2负责处理app的请求。在第一系统架构下，在app通过特权级间调用a1向服务进程2请求服务后，组件2通过函数调用(图9中未画出)请求组件1，组件1通过进程间调用a2请求服务进程1。假设在此时，动态发生由图9中左图所示第一系统架构变形为图9中右图所示第二系统架构的架构调整。由于函数调用通信接口(组件1与组件2的通信接口，图9中未示出)、进程间调用通信接口(a2、a3、b3、b5)、特权级间调用通信接口(a1、a4、b4)的传参规范统一，因此，在系统架构调整结束时，服务进程1可以直接通过进程间调用b3将服务响应结果返回给服务进程2.1，服务进程2.1通过特权级间调用b4将服务响应结果返回给服务进程2.2，服务进程2.2可以直接通过进程间调用b5将服务响应结果最终返回给app。对于app来说，虽然特权级间调用a1与进程间调用b5所使用的通信接口的实现不同(应理解，这是由系统架构的动态调整引起的)，但这对app来说，是无感知的。也就是说，由图9中左图所示第一系统架构变形为图9中右图所示第二系统架构的架构调整，是业务无感知的。276.可知，在图9的示例中，服务进程2中的组件1与组件2之间通过函数调用互相访问，当服务进程2拆分变形为服务进程2.1与服务进程2.2后，服务进程2.1与服务进程2.2之间的通信方式为特权级间调用，可以理解为，服务进程2中的组件1与组件2之间的通信方式由函数调用切换为了特权级间调用。277.需要说明的是，在第二系统架构中，app也可以直接通过进程间调用访问服务进程2.2。278.在图9的示例中，系统架构调整之前，即在第一系统架构中，服务进程2中的组件1与组件2运行在内核态(el1)的同一地址空间中，相互之间使用函数调用进行访问，此时通信开销最小，仅为一个函数调用的时间开销。在系统架构调整之后，即在第二系统架构中，组件1与组件2之间的通信方式由函数调用变为特权级间通信，此时通信开销会略微增大，但是，组件1与组件2分别隔离为服务进程2.1与服务进程2.2，且服务进程2.2被降权至用户态，这样可以有效提升系统整体的安全韧性。279.例如，图9中所示的第一系统架构可以视为高性能系统架构，图9中所示的第二系统架构可以视为高安全系统架构。280.从图9的示例可知，通过将通信接口的传参规范设置为一致，可以实现，针对同一个服务请求，可以使用不同的通信方式进行请求调用与结果返回，并且这个过程是业务无感知的。281.应理解，在本实施例中，在通过服务进程的拆分变形或合并变形，以及特权级的变化来实现系统架构的动态切换时，可以实现业务无感知。282.可选地，在上述一些实施例中，第一系统架构中所有通信接口以及第二系统架构中所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。283.基于上述描述，在本技术实施例中，通过设置传参规范统一的通信接口，可以使得不同通信接口(不同通信接口的传参参数规范一致)的请求调用与结果返回可以相互替换，且这种替换不会造成服务中断，从而可以实现在系统架构动态切换时业务无感知。284.例如，本技术实施例提供的系统架构可以应用于iot等资源受限的应用场景。285.为了更好地理解本技术实施例，下面结合图10描述一个本技术实施例中实现系统架构动态切换的例子。如图10所示，实现系统架构动态切换的过程可以包括线下的静态部分与运行时的动态部分，其中线下的静态部分是运行时进行动态切换的基础。286.线下的静态部分包括：传参规范统一的通信接口设计实现、组件资源划分、地址无关方案选型与对应实现。287.运行时的动态部分主要包括：服务进程进行拆分变形或合并变形时对资源映射的调整，服务进程进行降权变形或提权变形时对服务进程的特权级的调整，以及调整前后通信接口的切换。288.s1010，设计传参规范统一的通信接口。289.以arm系统为例。arm现有的函数调用规范apcs或aapcs(procedurecallstandardforthearmarchitecture)规定了函数传参与返回的顺序，同时规定了调用者(caller)与被调用(callee)分别负责保存的寄存器。aapcs为arm架构新的函数调用标准，用于arm64。290.类似地，本技术实施例设计了相同参数传递规范的特权级间调用与进程间调用。291.例如，设计使得涉及到变形的服务进程的所有通信接口的参数传递规范统一，其中，该通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。292.又例如，设计使得系统中所有的函数调用通信接口、特权级通信接口与进程间通信接口的参数传递规范统一。293.当保证进程间调用、特权级间调用、函数调用的函数传递规范一致时，调用者的调用和被调用者的返回可以使用不同的接口。294.具体描述，详见前文结合图8的描述，这里不再赘述。295.s1020，划分进程资源。296.为了满足运行时的动态拆分，进程资源需要提前划分为各个组件。各个组件之间的数据不耦合，调用时统一通过暴露的函数接口进行成员访问(即取消对共享变量的直接访问)。在编译时各组件的代码和数据各自集中映射。297.例如，图4中的服务进程1的资源被静态划分为3个组件：组件1、组件2与组件3。各个组件的代码数据各自集中映射。298.s1030，实现地址无关。299.在某些架构下，当服务进程的特权级改变时会进行重定位加载，其地址会发生改变。例如，在arm架构下，内核态(el1)运行在高地址，用户态(el0)运行在低地址。例如，当服务进程的特权级由内核态降权至用户态，其地址由高地址变为低地址。300.为了应对运行时服务进程的特权级发生动态变化，需要结合系统架构选择合适的地址无关方案来编译生成对应的可执行文件。301.例如，可以采用图6中(a)、(b)、(c)、(d)所示的四种方法中的任一种来编译生成对应的可执行文件。具体描述详见前文描述，为了简洁，这里不再赘述。302.s1050，替换通信接口状态。303.拆分变形前，服务进程可能已处于服务app的状态中，假设该服务进程中正在服务的组件为图4中的组件3；当步骤s1040完成后，组件3位于服务进程1.2中。服务进程1.1由于已不再需要服务app，因此，进程上下文被重新初始化为等待服务状态。服务进程1.2则依照拆分变形前的进程上下文继续进行服务处理，处理结束后，服务进程1.2负责将结果返回给用户态app。304.s1060，服务进程在变形时，对特权级的调整。305.当内核决定对服务进程进行提权处理或降权处理时，需要修改对应服务进程的状态寄存器调整对应的特权级。由于经过步骤s10300，进程可以直接运行在el0或el1，因此当进程的特权级被调整后，可以继续运行而不受影响。306.s1070，切换服务进程的特权级。307.由于一般各特权级使用各自的页表寄存器、上下文寄存器，因此，当进程的特权级被修改后，调度器在调度到不同特权级的进程时，需要更换使用对应特权级的上下文寄存器与页表寄存器。例如当服务进程被从el1调整为el0时，在下次调度器调度到该进程时，会选择切换el1的页表基址寄存器，切换上下文时，选择对应特权级的栈寄存器等。308.s1080，替换通信接口状态。309.该步骤类似步骤s1050，在调整特权级前，进程可能已处于服务app状态中，假设要调整特权级的进程为图8中(c.1)与(c.2)中的服务进程1.1。在调整特权级前，服务运行在el1，用户态app或其他服务通过特权级间调用访问服务进程1.1。此时，服务进程1.1被调整到了el0，如图8中(c.2)，由于原有服务为特权级间调用(例如，系统调用)，调整为el0之后内核需要修改服务进程1.1的上下文状态，当服务进程1.1完成服务后会利用进程间调用(ipc)将返回结果传入内核，然后，返回结果会继续通过进程间调用(ipc)返回给调用者app。310.s1090，切换通信接口。311.当通信接口的状态被替换完成后，系统会依据调整后的架构切换后续服务的通信接口。不同特权级间、进程间与进程内的通信方式如图8所示，详见前文描述。312.需要说明的是，图10仅为示例。313.例如，图10中的步骤s1030、s1060、s1070与s1080是可选的。例如，仅通过服务进程的拆分变形或合并变形来实现系统架构的动态切换。314.又例如，图10中的步骤s1020、s1040与s1050是可选的。例如，仅通过服务进程的特权级的改变(提权变形或降权变形)来实现系统架构的动态切换。315.实际应用中，可以根据应用需求灵活设计一个可变形的系统架构。只要是通过一个可变形的系统架构实现系统架构的动态切换的方案，都落入本技术的保护范围。316.本技术实施例可以应用于各种计算机系统的架构调整。317.下面以本技术实施例应用于无线rru场景rtosv3版本中文件系统的架构调整为例，进行说明。318.在无线rru场景rtosv3版本中，采用的是微内核架构。微内核提供ipc、中断和最基础的调度功能，其中内核管理、进程管理、文件系统、驱动均以单独的进程形式独立运行。通过将各个服务进程隔离为单独的进程，服务进程之间的错误会被隔离而不会影响到系统的其它部分。而微内核本身经过了形式化验证，其稳定性与安全性是远高于其它服务进程的，通过这种方式可以保证系统能够稳定运行。319.在业务运行过程中，一个常见的流程是用户态的应用程序(app)需要写日志(log)或请求驱动服务进程(drivers)的功能，其路径如图11所示。app将文件描述符号(filedescriptor，fd)发送给dev文件系统服务进程(devfs)，请求向该fd中写入日志，devfs会根据自身的知识解析fd并找到drivers，调用drivers的功能，drivers本身再调用fat文件系统服务进程(fatfs)的接口请求向闪存(flash)中写入文件。320.如图11所示，fatfs为闪存(flash)文件系统，devfs为驱动文件系统(filesystem，fs)，微内核为验证过的安全可信的内核，drivers为运行在用户态的驱动，app为rru业务软件。321.当业务需要进行大量日志读写时，为了提高效率，系统可以使用文件系统耦合的系统架构(fsmerged架构)，如图11中左图所示。通过将devfs与fatfs合并，两者可以协同使用文件系统中的缓存页，提高缓存利用率；通过将devfs提权到内核态，devfs可以直接访问app的数据，在fsmerged架构下，应用请求方向为特权级间调用a1→特权级间调用a2→特权级间调用a3。在arm架构下，该过程只需要3次特权级间通信即可完成。322.当业务不需要集中进行大量文件写入时，系统架构可在运行时调整为文件系统解耦的系统架构(fssplit架构)，如图11中右图所示。在此场景下，devfs被降权到用户态，调用过程为进程间调用b1→进程间调用b2→特权级间调用b3。可知，在fssplit架构下，需要2次ipc和一次特权级间通信，其中，2次ipc的开销要高于特权级间通信的开销，且fatfs与devfs无法通过函数调用进行协作。虽然牺牲了些许性能，但fssplit架构能够避免devfs中发生错误时影响整个文件系统。例如，在此场景下，即使devfs出错，写错数据也丝毫不会影响flash中文件的正确性。323.在rtosv2版本中，内核使用的是linux宏内核，linux宏内核架构与图11所示的fsmerge架构、fssplit架构在系统安全方面的对比结果如表1所示。324.表1merge架构更符合业务场景的大文件写(log大量写入)与随机读写(各模块log打点)。本技术实施例提供的方案，在运行时可以随时调整系统架构，从而可以更细致的对产品业务场景进行自适应，例如，可以在业务性能不下降的前提下大大提升产品的安全韧性。333.基于上文描述，本技术实施例通过可变形的系统架构实现系统架构的动态切换，使得可以只需实现一个系统架构即可实现不同架构的切换，因此只需用于实现这一个系统架构的代码，相对于现有技术，可以减小代码开销。334.此外，通过设置传参规范统一的通信接口，可以使得不同通信接口(不同通信接口的传参参数规范一致)的请求调用与结果返回可以相互替换，且这种替换不会造成服务中断，从而可以实现在系统架构动态切换时业务无感知。335.本文中描述的各个实施例可以为独立的方案，也可以根据内在逻辑进行组合，这些方案都落入本技术的保护范围中。336.上文描述了本技术提供的方法实施例，下文将描述本技术提供的装置实施例。应理解，装置实施例的描述与方法实施例的描述相互对应，因此，未详细描述的内容可以参见上文方法实施例，为了简洁，这里不再赘述。337.如图12所示，本技术实施例提供一种切换系统架构的装置1200，该装置1200包括：切换单元1210与处理单元1220。338.切换单元1210，用于将第一系统架构变形为第二系统架构，第一系统架构表示切换之前的系统架构，第二系统架构表示切换之后的系统架构。其中，第一系统架构与第二系统架构之间的关系为下列情况中的任一种或多种：第一系统架构中服务进程的特权级与第二系统架构中服务进程的特权级不同，第一系统架构中服务进程的数量与第二系统架构中服务进程的数量不同。339.处理单元1220，用于使用第二系统架构，为用户提供服务。340.可选地，作为一个实施例，第一系统架构包括第一服务进程；其中，切换单元1210用于，改变第一服务进程的特权级。341.可选地，在本实施例中，在不同特权级的地址不同的情况下，第一服务进程是采用数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制创建的。342.可选地，第一服务进程的特权级包括第一特权级态与第二特权级态，其中，第一特权级态使用低地址，第二特权级态使用高地址；其中，数据段支持地址无关的重定位的机制包括，将第一服务进程的数据段始终映射在低地址。343.可选地，数据段支持地址无关的重定位的机制包括对第一服务进程的数据段进行地址翻译处理，使得第一服务进程在特权级改变之后的数据段与在特权级改变之前的数据段映射至相同的地址；代码段支持地址无关的重定位的机制包括对第一服务进程的代码段进行地址翻译处理，使得第一服务进程在特权级改变之后的代码段与在特权级改变之前的代码段映射至相同的地址。344.可选地，在通过动态改变服务进程的特权级来实现系统架构的动态切换的实施例中，可以配置系统架构本身允许不同特权级使用相同的地址空间。345.可选地，作为另一个实施例，第一系统架构包括第一服务进程，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；其中，切换单元1210用于，基于多个组件，将第一服务进程拆分为多个子服务进程，其中，每个子服务进程包括多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。346.可选地，作为又一个实施例，第一系统架构包括第一服务进程，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；其中，切换单元1210用于，基于多个组件，将第一服务进程拆分为多个子服务进程，并改变多个子服务进程中一个或多个子服务进程的特权级，使得一个或多个子服务进程的特权级与第一服务进程的特权级不同，其中，每个子服务进程包括多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。347.可选地，作为又一个实施例，第一系统架构包括第一服务进程；其中，切换单元1210用于，改变第一服务进程的特权级；其中，第一服务进程的所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。348.可选地，作为又一个实施例，第一系统架构包括第一服务进程，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；切换单元1210用于，基于多个组件，将第一服务进程拆分为多个子服务进程，其中，每个子服务进程包括多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。其中，第一服务进程的所有通信接口、多个子服务进程中每个子服务进程的所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。349.可选地，作为又一个实施例，第一系统架构中所有通信接口以及第二系统架构中所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。350.例如，本技术实施例提供的切换系统架构的装置1200可以为计算机系统中的内核。351.如图13所示，本技术实施例还提供一种数据处理的装置1300。该装置1300包括处理器1310，处理器1310与存储器1320耦合，存储器1320用于存储计算机程序或指令，处理器1310用于执行存储器1320存储的计算机程序或指令，使得上文方法实施例中的方法被执行。352.可选地，如图13所示，该装置1300还可以包括存储器1320。353.可选地，如图13所示，该装置1300还可以包括数据接口1330，数据接口1330用于与外界进行数据的传输。354.如图14所示，本技术实施例还提供一种计算机系统1400，该计算机系统1400包括系统架构1410与处理器1420。系统架构1410可以支持多种架构的变形。本实施例中以系统架构1410的两种变形第一系统架构1411与第二系统架构1412为例进行描述。系统架构1411与第二系统架构1412可互相变形。355.处理器1420，用于控制系统架构1410的变形，并使用系统架构1410的一种变形架构提供服务。356.可选地，处理器1420用于，将第一系统架构1411变形为第二系统架构1412，第一系统架构1411表示切换之前的系统架构，第二系统架构1412表示切换之后的系统架构；使用第二系统架构1412，为用户提供服务。其中，第一系统架构1411与第二系统架构1412之间的关系为下列情况中的任一种或多种：第二系统架构1412中服务进程的特权级与第二系统架构1412中服务进程的特权级不同，第二系统架构1412中服务进程的数量与第二系统架构1412中服务进程的数量不同。357.可选地，处理器1420可以采用上文方法实施例中的方法300，将第一系统架构1411变形为第二系统架构1412。358.可选地，作为一个实施例，第一系统架构1411包括第一服务进程，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；其中，处理器1420用于，基于该多个组件，将第一服务进程拆分为多个子服务进程，从而将第一系统架构1411切换为第二系统架构1412，其中，每个子服务进程包括多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。359.具体参见上文对实施方式一的描述，这里不再赘述。360.可选地，作为另一个实施例，第一系统架构1411包括第一服务进程；其中，处理器1420用于，改变第一服务进程的特权级，从而将第一系统架构1411切换为第二系统架构1412。361.具体参见上文对实施方式二的描述，这里不再赘述。362.可选地，作为又一个实施例，第一系统架构1411包括第一服务进程，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；其中，处理器1420用于，基于该多个组件，将第一服务进程拆分为多个子服务进程，并改变多个子服务进程中一个或多个子服务进程的特权级，使得该一个或多个子服务进程的特权级与第一服务进程的特权级不同，从而将第一系统架构1411切换为第二系统架构1412，其中，每个子服务进程包括多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。363.具体参见上文对实施方式三的描述，这里不再赘述。364.可选地，第一服务进程的所有通信接口、多个服务进程中每个服务进程的所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。365.可选地，第一系统架构1411中所有通信接口以及第二系统架构1412中所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。366.具体参见前文相关描述，这里不再赘述。367.可选地，处理器1420可以采用图10所示的方法，将第一系统架构1411变形为第二系统架构1412。具体描述，详见上文，这里不在赘述。368.如图15所示，本技术实施例还提供一种计算机系统1500，该计算机系统1500包括处理器1510、策略库1520、服务进程1530、应用程序(app)1540。服务进程可以为内核功能的一部分，例如，为文件系统、内存管理、系统服务或其他服务等。369.策略库1520，用于存储切换系统架构的策略。370.例如，策略库1520存储的切换系统架构的策略，包括如上文实施例提及的服务进程拆分变形、服务进程合并变形、服务进程提权变形与服务进程降权变形。371.服务进程1530被预先划分为多个独立的组件，各个组件之间的数据不耦合。372.处理器1510，根据输入与策略库1520存储的策略，选择合适的系统架构切换策略，并根据选出的系统架构切换策略控制服务进程1530的变形，以实现系统架构的动态切换(或称为动态调整)。这里的输入可以为应用场景对系统架构的要求。373.处理器1510也可以称为内核。374.例如，处理器1510用于执行上文实施例中的方法，例如，图3所示的方法或图10所示的方法。375.可选地，服务进程1530的通信接口，以及服务进程1530中预先划分的多个独立组件之间的通信接口传参规范统一。例如，这些通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。376.可选地，计算机系统1500内的所有通信接口的传参规范统一。377.本技术实施例还提供一种计算机可读介质，该计算机可读介质存储用于设备执行的程序代码，该程序代码包括用于执行上述实施例的方法。378.本技术实施例还提供一种包含指令的计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述实施例的方法。379.本技术实施例还提供一种芯片，该芯片包括处理器与数据接口，处理器通过数据接口读取存储器上存储的指令，执行上述实施例的方法。380.可选地，作为一种实现方式，该芯片还可以包括存储器，存储器中存储有指令，处理器用于执行存储器上存储的指令，当指令被执行时，处理器用于执行上述实施例中的方法。381.除非另有定义，本文所使用的所有的技术和科学术语与属于本技术的
技术领域：
：的技术人员通常理解的含义相同。本文中在本技术的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本技术。382.需要说明的是，本文中涉及的第一、第二、第三或第四等各种数字编号仅为描述方便进行的区分，并不用来限制本技术实施例的范围。383.本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的范围。384.所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。385.在本技术所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。386.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。387.另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。388.所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：通用串行总线闪存盘(usbflashdisk，ufd)(ufd也可以简称为u盘或者优盘)、移动硬盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。389.以上所述，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何熟悉本
技术领域：
：的技术人员在本技术揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以所述权利要求的保护范围为准。当前第1页12当前第1页12
技术领域：
：，尤其涉及一种切换系统架构的方法与装置。
背景技术：
：：2.不同的应用场景对计算机系统的安全与通信性能的要求不同。例如，在系统与用户交互的场景下，需要防范异常的输入或攻击，即这种应用场景对系统安全的要求较高，这时的系统架构应该为高安全架构；在系统与用户交互完成后，需要进行大量计算，即这种应用场景对通信效率的要求较高，这时的系统架构应该为高性能架构。因此，面对不同的应用需求，需要设计不同的系统架构。3.现有技术提出一种方案，是在计算机系统内设计多种系统架构，根据应用场景使能所需的系统架构。但是，多实现一套系统架构就需要多一倍的代码，这导致代码开销较大，在物联网(internetofthings，iot)这类资源紧张的场景下，这是不可接受的。技术实现要素：4.本技术提供一种切换系统架构的方法与装置，通过可变形的系统架构实现系统架构的动态切换，使得可以只需一个系统架构即可实现不同架构的切换，因此只需用于实现这一个系统架构的代码，相对于现有技术，可以减小代码开销。5.第一方面，提供一种切换系统架构的方法，所述方法包括：将第一系统架构变形为第二系统架构，所述第二系统架构表示切换之前的系统架构，所述第一系统架构表示切换之后的系统架构；使用所述第二系统架构，为用户提供服务。6.所述第一系统架构与所述第二系统架构之间可互相变形，其中，所述第一系统架构与所述第二系统架构之间的关系为下列情况中的任一种或多种：所述第一系统架构中服务进程的特权级与所述第二系统架构中服务进程的特权级不同，所述第一系统架构中服务进程的数量与所述第二系统架构中服务进程的数量不同。7.应理解，通过可变形的系统架构实现系统架构的动态切换，使得可以只需实现一个系统架构即可实现不同架构的切换，因此只需用于实现这一个系统架构的代码，相对于现有技术，可以减小代码开销。8.可选地，可以根据应用场景对系统架构的需求，确定是否需要切换系统架构，在需要切换系统的情况下，使能系统架构的变形，即实现动态切换系统架构。这样可以在系统运行时动态满足应用场景对不同的系统架构的需求。9.由第一系统架构到第二系统架构的变形方式可以有多种。10.结合第一方面，在一种可能的实现方式中，所述第一系统架构包括第一服务进程；其中，所述将第一系统架构变形为第二系统架构，包括：改变所述第一服务进程的特权级。11.特权表示在计算机中执行与安全相关的功能的能力。具有执行安全相关功能特权的进程，被认为运行于特权态。不具有执行安全相关功能特权的进程，被认为运行于非特权态。特权态与非特权态是不同的特权级，不同级别的特权态也是不同的特权级。12.改变所述第一服务进程的特权级包括提权处理与降权处理。提权处理表示提升服务进程的特权级。降权处理表示降低服务进程的特权级。13.在本实现方式中，通过改变第一服务进程的特权级，实现了将所述第一系统架构切换为所述第二系统架构。其中，第一系统架构中第一服务进程的特权级与第二系统架构中第一服务进程的特权级不同。14.应理解，通过改变服务进程的特权级，实现了系统架构的动态切换。15.可选地，在本实现方式中，在不同特权级的地址不同的情况下，所述第一服务进程是采用数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制创建的。16.代码段支持地址无关的重定位的机制表示，无论服务进程的代码段的地址是否发生变化，都可以保证服务进程的运行。换句话说，服务进程的运行与代码段的地址无关。17.数据段支持地址无关的重定位的机制表示，表示，无论服务进程的数据段的地址是否发生变化，都可以保证服务进程的运行。换句话说，服务进程的运行与数据段的地址无关。18.可选地，所述第一服务进程的特权级包括第一特权级态与第二特权级态，其中，所述第一特权级态使用低地址，所述第二特权级态使用高地址；其中，所述数据段支持地址无关的重定位的机制包括，将所述第一服务进程的数据段始终映射在所述低地址。19.可选地，第一特权级态与第二特征级态中的一个表示非特权态，另一个表示特权态。20.可选地，第一特权级态与第二特征级态均为特权态，其中一个的特权级高于另一个的特权级。21.高地址、低地址是计算机领域里通用的概念。高地址与低地址是相对而言的，即相对地址编码的大小而言。22.所述将所述第一服务进程的数据段始终映射在所述低地址的操作包括：静态配置与动态维持。静态配置指的是，在所述第一服务进程运行之前，通过静态配置将所述第一服务进程的数据段映射在低地址。动态维护指的是，当在运行过程中所述第一服务进程的特权级发生变化(即引起数据段地址变化)，动态维持数据段仍然映射在低地址。23.可选地，所述数据段支持地址无关的重定位的机制包括对所述第一服务进程的数据段进行地址翻译处理，使得所述第一服务进程在特权级改变之后的数据段与在特权级改变之前的数据段映射至相同的地址；所述代码段支持地址无关的重定位的机制包括对所述第一服务进程的代码段进行地址翻译处理，使得所述第一服务进程在特权级改变之后的代码段与在特权级改变之前的代码段映射至相同的地址。24.可以采用硬件或软件的方式，对所述第一服务进程的代码段与数据段进行地址翻译处理。25.现有技术中，改变进程的特权级的方式为，先销毁旧的进程，再重新生效新的进程。即现有技术无法实现在服务进程运行过程中改变服务进程的特权级。26.在本技术中，通过采用数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制来创建服务进程，可以支持在服务进程的运行过程中动态改变服务进程的特权级，从而可以通过动态改变服务进程的特权级实现系统架构的动态切换。27.可选地，在通过动态改变服务进程的特权级来实现系统架构的动态切换的实现方式中，可以配置系统架构本身允许不同特权级使用相同的地址空间。28.应理解，通过服务进程的特权级的动态变化实现了服务进程的动态变形，从而实现了系统架构的动态变形，因此，可以实现系统架构的动态切换。29.结合第一方面，在一种可能的实现方式中，所述第一系统架构包括第一服务进程，所述第一服务进程被预先划分为多个组件，所述多个组件之间的数据不耦合；其中，所述将第一系统架构变形为第二系统架构，包括：基于所述多个组件，将所述第一服务进程拆分为多个子服务进程，其中，每个子服务进程包括所述多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。30.第一服务进程被预先划分为的多个组件之间的数据不耦合，表示，这多个组件之间进行访问时，通过函数接口进行成员访问，而不是对资源进行直接访问，或者对共享变量进行直接访问。31.基于所述多个组件，将所述第一服务进程拆分为多个子服务进程，可以视为，所述多个组件作为一个整体被拆分为多个子集，每个子集可隔离为一个新的服务进程(即由第一服务进程拆分得到的子服务进程)。32.在本实现方式中，通过将所述第一服务进程拆分为多个子服务进程，实现了将所述第一系统架构切换为所述第二系统架构。其中，第一系统架构中服务进程的数量不同于第二系统架构中服务进程的数量。33.应理解，通过服务进程的拆分变形，实现了系统架构的动态切换。34.结合第一方面，在一种可能的实现方式中，第一系统架构包括第二服务进程与第三服务进程，所述将第一系统架构变形为第二系统架构，包括：将第二服务进程与第三服务进程合并为第一服务进程。其中，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；且第二服务进程与第三服务进程分别是由该多个组件中的部分组件构成的，第二服务进程与第三服务进程所包括的组件不同。35.将第二服务进程与第三服务进程合并为第一服务进程，可以视为，所述第二服务进程中的组件与所述第三服务进程中的组件合并为所述第一服务进程。36.在本实现方式中，通过将所述第二服务进程与所述第三服务进程合并为所述第一服务进程，实现了将所述第一系统架构切换为所述第二系统架构。其中，第一系统架构中服务进程的数量不同于第二系统架构中服务进程的数量。37.应理解，通过服务进程的合并变形，实现了系统架构的动态切换。38.还应理解，通过服务进程的数量的动态变化实现了服务进程的动态变形，从而实现了系统架构的动态变形，因此，可以实现系统架构的动态切换。39.结合第一方面，在一种可能的实现方式中，所述第一系统架构包括第一服务进程，所述第一服务进程被预先划分为多个组件，所述多个组件之间的数据不耦合；其中，所述将第一系统架构变形为第二系统架构，包括：基于所述多个组件，将所述第一服务进程拆分为多个子服务进程，并改变所述多个子服务进程中一个或多个子服务进程的特权级，使得所述一个或多个子服务进程的特权级与所述第一服务进程的特权级不同，其中，每个子服务进程包括所述多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。40.所述一个或多个子服务进程的特权级与所述第一服务进程的特权级不同，也属于第一服务进程的特权级发生变化的情形。在不同特权级的地址不同的情况下，所述第一服务进程是采用数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制创建的。关于数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制，参见前文描述，这里不再赘述。41.在本实现方式中，通过将第一服务进程拆分为所述多个子服务进程，并改变所述多个子服务进程中一个或多个子服务进程的特权级，实现了将所述第一系统架构切换为所述第二系统架构。其中，第一系统架构中服务进程的数量与第二系统架构中服务进程的数量不同，并且，第一系统架构中服务进程的特权级与第二系统架构中服务进程的特权级也不同。42.应理解，通过服务进程的数量与特权级的动态变化，实现了服务进程的动态变形，从而实现了系统架构的动态变形，因此，可以实现系统架构的动态切换。43.实际应用中，采取上述哪一种或多种变形方式进行系统架构的切换，可以根据应用场景而确定。44.在本技术中，服务进程在运行时能够动态变形，例如，拆分变形、合并变形、提权变形或降权变形，这可以实现系统架构的动态变形。因此，本技术可以根据应用场景的变化自适应调整系统架构，从而可以在运行时动态满足应用场景对不同系统架构的需求。45.此外，在本技术中，一个系统架构能够支持不同种架构的变形，因此只需用于实现这一个系统架构的一份代码即可，从而可以减小代码开销。应理解，一份代码能够在服务不中断、业务不下线的前提下，针对应用场景较细粒度地调整系统架构，从而使得系统架构的切换更加灵活，底噪更小。46.结合第一方面，在一种可能的实现方式中，涉及到变形的服务进程的所有通信接口的参数传递规范(可简称为，传参规范)统一。该通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。47.函数调用通信接口表示函数调用对应的通信接口。特权级间通信接口表示特权级之间进行通信的通信接口。进程间通信接口表示进程之间进行通信的通信接口。48.涉及到变形的服务进程的所有通信接口的参数传递规范统一表示，所述服务进程的所有通信接口进行请求调用的传参规范统一，所有通信接口进行结果返回的传参规范也统一。或者，涉及到变形的服务进程的所有通信接口的参数传递规范统一还可以表述为，所述服务进程的各个通信接口的请求调用与结果返回的传参规范统一。49.本文提及的“传参规范统一”也可以表述为“传参规范一致”。50.在现有的在系统内实现多种系统架构的方案中，当切换系统架构时，原先的服务会先被停掉，新的服务重复重新启动。从业务侧来看，原先的服务请求会被打断，需要重新发起新的服务请求，服务也会有短暂的中断以同步之前的状态，即，现有技术在切换系统架构时无法做到业务的无感知。51.在本技术中，通过设置传参规范统一的通信接口，可以使得不同通信接口(不同通信接口的传参参数规范一致)的请求调用与结果返回可以相互替换，且这种替换不会造成服务中断，从而可以实现在系统架构动态切换时业务无感知。52.还应理解，通过设计参数传递规范统一的通信接口(例如，函数调用通信接口、特权级间通信接口、进程间通信接口)，这样可以摆脱在服务进程发生改变(即系统架构发生改变)后，通信上下文需要同步的问题。因为无需同步通信上下文，因此，可以实现业务无感知。53.此外，在系统架构切换时，因为无需进行状态同步，也可以避免引入额外的状态拷贝开销。54.可选地，在通过服务进程的拆分变形或合并变形实现系统架构动态切换的实现方式中，所述第一服务进程的所有通信接口、所述多个子服务进程中每个子服务进程的所有通信接口的参数传递规范统一；其中，所述通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。55.可选地，在通过服务进程的特权级变化实现系统架构动态切换的实现方式中，所述第一服务进程的所有通信接口的参数传递规范统一；其中，所述通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。56.结合第一方面，在一种可能的实现方式中，所述第一系统架构中所有通信接口以及所述第二系统架构中所有通信接口的参数传递规范统一；其中，所述通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。57.第二方面，提供一种切换系统架构的装置，所述装置包括切换单元与处理单元。所述切换单元，用于将第一系统架构变形为第二系统架构，所述第一系统架构表示切换之前的系统架构，所述第二系统架构表示切换之后的系统架构。所述处理单元，用于使用所述第二系统架构，为用户提供服务。其中，所述第一系统架构与所述第二系统架构之间的关系为下列情况中的任一种或多种：所述第一系统架构中服务进程的特权级与所述第二系统架构中服务进程的特权级不同，所述第一系统架构中服务进程的数量与所述第二系统架构中服务进程的数量不同。58.结合第二方面，在一种可能的实现方式中，所述第一系统架构包括第一服务进程；其中，所述切换单元用于，改变所述第一服务进程的特权级。59.可选地，在本实现方式中，在不同特权级的地址不同的情况下，所述第一服务进程是采用数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制创建的。60.可选地，所述第一服务进程的特权级包括第一特权级态与第二特权级态，其中，所述第一特权级态使用低地址，所述第二特权级态使用高地址；其中，所述数据段支持地址无关的重定位的机制包括，将所述第一服务进程的数据段始终映射在所述低地址。61.可选地，所述数据段支持地址无关的重定位的机制包括对所述第一服务进程的数据段进行地址翻译处理，使得所述第一服务进程在特权级改变之后的数据段与在特权级改变之前的数据段映射至相同的地址；所述代码段支持地址无关的重定位的机制包括对所述第一服务进程的代码段进行地址翻译处理，使得所述第一服务进程在特权级改变之后的代码段与在特权级改变之前的代码段映射至相同的地址。62.可选地，在通过动态改变服务进程的特权级来实现系统架构的动态切换的实现方式中，可以配置系统架构本身允许不同特权级使用相同的地址空间。63.结合第二方面，在一种可能的实现方式中，所述第一系统架构包括第一服务进程，所述第一服务进程被预先划分为多个组件，所述多个组件之间的数据不耦合；其中，所述切换单元用于，基于所述多个组件，将所述第一服务进程拆分为多个子服务进程，其中，每个子服务进程包括所述多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。64.结合第二方面，在一种可能的实现方式中，所述第一系统架构包括第一服务进程，所述第一服务进程被预先划分为多个组件，所述多个组件之间的数据不耦合；其中，所述切换单元用于，基于所述多个组件，将所述第一服务进程拆分为多个子服务进程，并改变所述多个子服务进程中一个或多个子服务进程的特权级，使得所述一个或多个子服务进程的特权级与所述第一服务进程的特权级不同，其中，每个子服务进程包括所述多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。65.结合第二方面，在一种可能的实现方式中，所述第一系统架构包括第一服务进程；其中，所述切换单元用于，改变所述第一服务进程的特权级；其中，所述第一服务进程的所有通信接口的参数传递规范统一；其中，所述通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。66.结合第二方面，在一种可能的实现方式中，所述第一系统架构包括第一服务进程，所述第一服务进程被预先划分为多个组件，所述多个组件之间的数据不耦合；所述切换单元用于，基于所述多个组件，将所述第一服务进程拆分为多个子服务进程，其中，每个子服务进程包括所述多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。其中，所述第一服务进程的所有通信接口、所述多个子服务进程中每个子服务进程的所有通信接口的参数传递规范统一；其中，所述通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。67.结合第二方面，在一种可能的实现方式中，所述第一系统架构中所有通信接口以及所述第二系统架构中所有通信接口的参数传递规范统一；其中，所述通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。68.第三方面，提供一种计算机系统，所述计算系统包括：系统架构，所述系统架构可变形为多种架构；处理器，用于控制所述系统架构的变形，并使用所述系统架构的一种变形架构提供服务。69.结合第三方面，在一种可能的实现方式中，所述处理器用于：将第一系统架构变形为第二系统架构，所述第一系统架构表示切换之前的系统架构，所述第二系统架构表示切换之后的系统架构；使用所述第二系统架构，为用户提供服务。其中，所述第一系统架构与所述第二系统架构之间的关系为下列情况中的任一种或多种：所述第一系统架构中服务进程的特权级与所述第二系统架构中服务进程的特权级不同，所述第一系统架构中服务进程的数量与所述第二系统架构中服务进程的数量不同。70.所述处理器用于执行第一方面提供的方法，具体描述详见第一方面的描述，这里不再赘述。71.第四方面，提供一种数据处理的装置，该装置包括：存储器，用于存储程序；处理器，用于执行存储器存储的程序，当存储器存储的程序被执行时，处理器用于执行上述第一方面中的方法。72.第五方面，提供一种计算机可读介质，该计算机可读介质存储用于设备执行的程序代码，该程序代码包括用于执行上述第一方面中的方法。73.第六方面，提供一种包含指令的计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述第一方面中的方法。74.第七方面，提供一种芯片，所述芯片包括处理器与数据接口，所述处理器通过所述数据接口读取存储器上存储的指令，执行上述第一方面中的方法。75.可选地，作为一种实现方式，所述芯片还可以包括存储器，所述存储器中存储有指令，所述处理器用于执行所述存储器上存储的指令，当所述指令被执行时，所述处理器用于执行上述第一方面中的方法。76.基于上述描述可知，通过可变形的系统架构实现系统架构的动态切换，使得可以只需实现一个系统架构即可实现不同架构的切换，因此只需用于实现这一个系统架构的代码，相对于现有技术，可以减小代码开销。77.此外，通过设置传参规范统一的通信接口，可以使得不同通信接口(不同通信接口的传参参数规范一致)的请求调用与结果返回可以相互替换，且这种替换不会造成服务中断，从而可以实现在系统架构动态切换时业务无感知。附图说明78.图1为高安全系统架构的示意图。79.图2为高性能系统架构的示意图。80.图3为本技术实施例提供的切换系统架构的方法的示意性流程图。81.图4为本技术实施例中通过服务进程的拆分变形或合并变形实现系统架构切换的示意图。82.图5为本技术实施例中通过服务进程的特权级的变化实现系统架构切换的示意图。83.图6为本技术实施例提供的支持地址无关的重定位的机制的示意图。84.图7为本技术实施例中通过服务进程的拆分变形或合并变形，以及服务进程的特权级的变化来实现系统架构切换的示意图。85.图8为本技术实施例中设置传参规范统一的通信接口的示意图。86.图9为本技术实施例提供的一个切换系统架构的例子的示意图。87.图10为本技术实施例提供的切换系统架构的方法的另一示意性流程图。88.图11为本技术实施例应用于文件系统的架构动态切换的示意图。89.图12为本技术实施例提供的切换系统架构的装置的示意性框图。90.图13为本技术实施例提供的切换系统架构的装置的另一示意性框图。91.图14为本技术实施例提供的计算机系统的示意图。92.图15为本技术实施例提供的计算机系统的另一示意图。具体实施方式93.不同的应用场景对计算机系统(下文简称为系统)的安全与通信性能的要求不同。例如，在系统与用户交互的场景下，需要防范异常的输入或攻击，即这种应用场景对计算机系统的安全的要求较高；在系统与用户交互完成后，需要进行大量计算，即这种应用场景对通信效率的要求较高。94.为了满足高安全的要求，系统架构需要保证较细粒度的错误隔离，目的是，当异常发生时，异常的服务进程行为不会影响到其他服务进程，或者，系统架构需要保证服务进程运行在非特权态。为了满足高通信性能的要求，系统架构需要保证服务进程之间具有一定的耦合，或者将服务进程运行在特权态，目的是，提高通信效率，和/或降低通信开销。因此，面对不同的应用需求，需要设计不同的系统架构。95.传统技术中，系统架构通常是静态的，即系统架构确定后，在系统运行时系统架构便不再改变。例如，系统架构固定为图1所示的高安全系统架构，或者，系统架构固定为图2所示的高性能系统架构。96.图1为高安全系统架构的示意图。在图1中，每个实线部分拥有独立的地址空间，相互隔离。该高安全系统架构包括微内核、内存、驱动、文件系统(filesystem，fs)、系统服务、其他服务与应用程序(application，app)，其中，微内核运行在特权态，内存、驱动、文件系统、系统服务与其他服务与app运行在非特权态。内存、文件系统、系统服务与其他服务均可以为服务进程。因为服务进程运行在非特权态，则可以保障系统安全。在图1所示系统架构中，内存、文件系统、系统服务与其他服务具有独立的地址空间，互相隔离。即在图1所示系统架构中，各个服务进程之间隔离(或称为解耦)，当异常发生时，异常的服务进程行为不会影响到其他服务进程，这可以保障系统安全。但是，隔离的各个服务进程之间的通信方式为进程间通信(inter-processcall，ipc)，这会增大通信开销，降低通信性能。97.图2为高性能系统架构的示意图。在图2中，每个实线部分拥有独立的地址空间，相互隔离。该系统架构包括为微内核、内存、文件系统、系统服务、其他服务与app，其中，微内核、内存、文件系统、系统服务、其他服务运行在特权态，app运行在非特权态。内存、文件系统、系统服务与其他服务均可以为服务进程。服务进程运行在特权态，使得服务进程可以直接访问某些硬件寄存器，这可以降低通信开销。在图2所示系统架构中，内存、文件系统、系统服务与其他服务位于相同地址空间中。即在图2所示系统架构中，服务进程之间是耦合的，这可以提高通信性能。但是，因为服务进程之间是耦合的，当某一服务进程行为出错时，与之耦合的其他服务进程都会受到影响，从而造成系统崩溃，降低安全韧性。98.固定的系统架构可以应对单一的应用场景，但是随着应用场景的复杂多变，可能会出现固定的系统架构无法满足应用场景的变化的问题。99.例如，在系统与用户交互(记为应用场景1)时，需要防范异常的输入或攻击，因此需要交互的服务进程之间解耦或隔离；当交互完成后，需要使用服务进程的数据进行大量计算(记为应用场景2)，这时需要尽可能提高与该服务进程的通信效率。若系统架构固定为图1所示的高安全系统架构，该系统架构可以满足应用场景1的需求，但是，不能满足应用场景2的需求。若系统架构固定为图2所示的高性能系统架构，该系统架构可以满足应用场景2的需求，但是不能满足应用场景1的需求。100.为了满足复杂多变的应用场景对系统架构的要求，一种在系统内实现多种系统架构的方案被提出来。具体为，在计算机系统内设计多种系统架构，根据应用场景使能所需的系统架构。但是，多实现一套系统架构就需要多一倍的代码，这导致代码开销较大，在物联网(internetofthings，iot)这类资源紧张的场景下，这是不可接受的。101.本技术提供一种切换系统架构的方案，通过可变形的系统架构实现系统架构的动态切换，使得可以只需一个系统架构即可实现不同架构的切换，因此只需用于实现这一个系统架构的代码，相对于现有技术，可以减小代码开销。102.为了更好地理解本技术实施例，先描述一些本技术实施例相关的术语。103.1、进程(process)104.计算机的核心是中央处理器(centralprocessingunit，cpu)，它承担了所有的计算任务，而操作系统是计算机的管理者，它负责任务的调度，资源的分配和管理，统领整个计算机硬件。应用程序(application，app)是具有某种功能的程序，程序是运行于操作系统之上的。105.进程是一个具有一定独立功能的程序在一个数据集上的一次动态执行的过程，是操作系统进行资源分配和调度的一个独立单位，是应用程序运行的载体。106.进程具有如下特征：107.动态性：进程是程序的一次执行过程，是临时的，有生命期的，是动态产生，动态消亡的；108.并发性：任何进程都可以同其他进程一起并发执行；109.独立性：进程是系统进行资源分配和调度的一个独立单位；110.结构性：进程由程序，数据和进程控制块三部分组成。111.2、进程上下文112.如前文对进程的概念介绍，进程运行是动态的。进程上下文是，进程运行这一动态过程中某一时刻的静态描述。例如，某一时刻的静态描述包括这一时刻与进程相关的cpu所有状态，例如，通常包括这一时刻该进程的通用寄存器、状态寄存器(savedprogramstatusregister，spsr)的状态等。spsr表示arm中保存程序状态(含特权级)的寄存器/程序状态寄存器。113.换句话说，进程运行这一动态若被暂定，则进程上下文为这一时刻与该进程相关的cpu所有状态。114.进程上下文被恢复时，cpu可以继续从被暂定的状态继续执行。115.3、服务116.传统技术中，一个进程对应一个服务。117.服务对应的进程可以称为服务进程。应理解，服务进程区别于应用程序(app)对应的进程。118.本技术实施例涉及的是服务对应的进程，因此，在本文中将进程记为“服务进程”。也就是说，本技术实施例中提及的服务进程表示服务对应的进程。119.4、组件120.本技术实施例中提及的组件表示，进程中最小粒度的处理单元。组件是代码和数据的集合。121.在本技术的一些实施例中，一个服务进程可以被划分为多个组件，这多个组件中的部分组件可以形成一个新的服务进程，其余的组件可以形成另一个新的服务进程。换言之，通过将一个服务进程划分为多个组件，可以实现将该服务进程变形(拆分)为多个新的服务进程，反之，拆分出来的多个服务进程也可以逆变(合并)为原服务进程。即一个服务进程内的组件的拆分与合并是可逆的。122.假设一个服务进程1被划分为组件1.1、组件1.2、组件1.3、组件1.4。一种变形过程为，组件1.1与组件1.2形成服务进程1.1，组件1.3与组件1.4形成服务进程1.2，即服务进程1被拆分为服务进程1.1与服务进程1.2。逆变形过程为，组件1.1、组件1.2、组件1.3、组件1.4可以重新合并为服务进程1，即服务进程1.1与服务进程1.2合并为服务进程1。具体参加下文中关于实施方式一的描述。123.应理解，服务是逻辑概念，服务进程与组件是实体概念。124.5、特权级、特权态与非特权态125.特权表示在计算机中执行与安全相关的功能的能力。具有执行安全相关功能特权的进程，被认为运行于特权态。不具有执行安全相关功能特权的进程，被认为运行于非特权态。特权态与非特权态是不同的特权级。126.在不同操作系统中，特权级的划分与定义不同，特权态与非特权态的含义不同。127.例如，在arm系统中，特权级包括用户态(exceptionlevel0，el0)与内核态(exceptionlevel1，el1)，或者，可信执行环境(trustedexecutionenvironment，tee)与通用执行环境(richexecutionenvironment，ree)。128.又例如，在x86系统中，特权级包括或用户模式权限(ring3)与特权模式权限(ring0)，intel系统的还可以划分特权级为根模式(rootmode)与非根模式(non-rootmode)等。129.再例如，amd系统的特权级可以包括访客模式(guestmode)与主机模式(hostmode)。130.需要说明的是，对于一个操作系统，其特权级、特权态与非特权态的定义与规范为现有技术，本文对此不作详述。131.根据操作系统的不同，特权级间通信的命令也不同。例如，arm系统中的特权级间通信的命令为可以为svc(supervisorcall)、hvc(hypervisorcall)或smc(securemonitorcall)；x86系统中的特权级间通信的命令为int80或系统调用(syscall)指令等。132.svc为arm架构下的用户内(el0)与内核态(el1)的通信方式，例如，系统调用的通信方式。hvc为arm架构下el0、el1与el2的通信方式。smc为arm架构下el0、el1与el3的通信方式。el表示arm架构下的权限级别的限制，其中，el0表示用户态，el1、el2与el3表示内核态下的不同权限的限制。133.6、进程间通信(inter-processcall，ipc)134.进程间通信表示，计算机系统中不同进程间传播或交换消息的方式。135.由于进程之间地址空间隔离，内核需要提供进程间通信的实现。136.进程之间进行通信的通信接口可以称为进程间通信接口(可以简称为ipc接口)。137.7、特权级间通信138.特权级间通信表示，特权态与非特权态之间的通信。139.特权级之间进行通信的通信接口可以称为特权级间通信接口。140.8、函数调用141.函数调用，表示计算机编译或运行时，使用某个函数来完成相关命令。142.函数调用对应的通信接口可以称为函数调用通信接口。143.下面将结合附图，对本技术中的技术方案进行描述。144.图3为本技术实施例提供的切换系统架构的方法的示意性流程图。例如，该方法的执行主体为处理器。该方法包括步骤s310与步骤s320。145.s310，将第一系统架构变形为第二系统架构，所述第一系统架构表示切换之前的系统架构，所述第二系统架构表示切换之后的系统架构。146.第一系统架构与第二系统架构之间可互相变形，其中，第一系统架构与第二系统架构之间的关系为下列情况中的任一种或多种：第一系统架构中服务进程的特权级与第二系统架构中服务进程的特权级不同，第一系统架构中服务进程的数量与第二系统架构中服务进程的数量不同。147.在当前系统架构为第一系统架构的情况下，当需要由第一系统架构切换为第二系统架构时，将第一系统架构变形为第二系统架构，从而实现由第一系统架构到第二系统架构的切换。这种情况下，第一系统架构表示切换之前的系统架构，第二系统架构表示切换之后的系统架构。148.应理解，在当前系统架构为第二系统架构的情况下，当需要由第二系统架构切换为第一系统架构时，将第二系统架构变形为第一系统架构，从而实现由第二系统架构到第一系统架构的切换。这种情况下，第二系统架构表示切换之前的系统架构，第一系统架构表示切换之后的系统架构。149.本文中以将第一系统架构变形为第二系统架构为例进行描述。150.将第一系统架构变形为第二系统架构，表示，第二系统架构是在第一系统架构的基础上变形得到的。第一系统架构与第二系统架构可以视为是同一个系统架构的不同变形。151.应理解，在本技术实施例中，只需实现一个系统架构，该系统架构可以支持多种变形。152.需要说明的是，在本技术实施例中，一个系统架构可以支持多种变形，例如两种或两种以上的变形。为了便于描述与理解，本技术实施例中以第一系统架构与第二系统架构这两种变形为例进行描述。153.还需要说明的是，第一系统架构与第二系统架构的命名仅为区分切换之前与之后的系统架构，没有特殊限定。例如，第一系统架构表示高安全系统架构，第二系统架构表示高性能系统架构，或者，反过来。实际应用中，可以根据应用需求确定系统架构的切换方式。154.s320，使用第二系统架构，为用户提供服务。155.本文提及的为用户提供服务，也可以表述为向应用程序(app)提供服务。156.应理解，在系统架构切换之前，是第一系统架构中的服务进程(记为服务进程1)提供服务，在系统架构切换之后，是第二系统架构中的服务进程(记为服务进程2)提供服务。服务进程1提供的服务与服务进程2提供的服务对应逻辑上的同一个服务。例如，系统架构切换之前，由服务进程1向app1提供服务，系统架构切换之后，由服务进程2向该app1提供服务。这里提及的服务进程1与服务进程2之间可互相变形，下文将描述。157.在本技术实施例中，通过可变形的系统架构实现系统架构的动态切换，使得可以只需实现一个系统架构即可实现不同架构的切换，因此只需用于实现这一个系统架构的代码，相对于现有技术，可以减小代码开销。158.应理解，本技术实施例相对于现有技术，不仅可以实现系统架构的动态切换，还可以降低代码开销。159.可选地，在步骤s310中，可以根据应用场景，确定是否需要切换系统架构，在需要切换系统的情况下，使能系统架构的变形。160.例如，在当前系统架构为第一系统架构的情况下，根据应用场景确定需要由第一系统架构切换为第二系统架构，则将第一系统架构变形为第二系统架构。161.作为一个示例。假设第一系统架构(即当前系统架构)表示高安全系统架构，第二系统架构表示高性能系统架构。若当前应用场景对系统的通信效率要求较高，则当前需要切换系统架构，即由第一系统架构变形为第二系统架构。应理解，若当前应用场景对系统的安全的要求较高，这种情况下无需切换系统架构。162.应理解，本技术可以在系统运行时动态满足应用场景对不同的系统架构的需求。163.第二系统架构为第一系统架构的变形，也就是说，第二系统架构与第一系统架构不同。第二系统架构与第一系统架构之间的不同之处可以包括下列情况中的任一种或多种：服务进程的数量不同，服务进程的特权级不同。164.由第一系统架构到第二系统架构的变形方式可以有多种。例如，可以包括下列任一种或多种：服务进程的拆分或合并，服务进程的特权级的改变(提权或降权)。具体如下文将描述的实施方式一、实施方式二与实施方式三。165.实施方式一：服务进程的拆分变形或合并变形166.可选地，在一些实施例中，第一系统架构包括第一服务进程，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；步骤s310包括：基于该多个组件，将第一服务进程拆分为多个子服务进程，其中，每个子服务进程包括多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。167.第一服务进程被预先划分为的多个组件之间的数据不耦合，表示，这多个组件之间进行调用时，通过函数接口进行成员访问，而不是对资源进行直接访问，或者对共享变量进行直接访问。168.基于该多个组件，将第一服务进程拆分为多个子服务进程，可以视为，该多个组件作为一个整体被拆分为多个子集，每个子集可隔离为一个新的服务进程(即由第一服务进程拆分得到的子服务进程)。169.需要说明的是，为了区分而非限定，将第一服务进程拆分得到的多个服务进程记为多个子服务进程。170.作为示例，如图4所示。服务进程1预先被划分为3个组件：组件1、组件2与组件3，其中，组件1、组件2与组件3之间的数据不耦合。组件1与组件2可以形成一个新的服务进程：服务进程1.1，组件3可以形成一个新的服务进程：服务进程1.2。因为不同进程的地址不同，即进程之间是隔离的，因此，可以视为，组件1与组件2隔离为服务进程1.1，组件3隔离为服务进程1.2。如图4所示，服务进程1可以拆分变形为服务进程1.1与服务进程1.2。服务进程1到服务进程1.1与服务进程1.2的变形是可逆的，即服务进程1.1与服务进程1.2也可逆变形为服务进程1。如图4所示，服务进程1.1与服务进程1.2可以合并变形为服务进程1。171.图4中的服务进程1可以对应第一服务进程，图4中的服务进程1.1与服务进程1.2可以对应由第一服务进程拆分成的多个子服务进程。172.应理解，服务进程的数量增加，必然导致系统架构发生变化。173.在本实施例中，将第一服务进程未拆分变形时的系统架构视为第一系统架构，将第一服务进程进行拆分变形后的系统架构视为第二系统架构。也就是说，通过服务进程的拆分变形，实现了系统架构的切换(由第一系统架构切换为第二系统架构)。174.在本实施例中，通过将所述第一服务进程拆分为多个子服务进程，实现了将所述第一系统架构切换为所述第二系统架构。其中，第一系统架构中服务进程的数量不同于第二系统架构中服务进程的数量。175.应理解，通过服务进程的拆分变形，实现了系统架构的动态切换。176.如前文描述，服务进程之间的变形是可逆的，即可以拆分变形，也可以合并变形。177.可选地，在一些实施例中，第一系统架构包括第二服务进程与第三服务进程，步骤s310包括：将第二服务进程与第三服务进程合并为第一服务进程，以将第一系统架构变形为第二系统架构。其中，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；且第二服务进程与第三服务进程分别是由该多个组件中的部分组件构成的，第二服务进程与第三服务进程所包括的组件不同。178.将第二服务进程与第三服务进程合并为第一服务进程，可以视为，所述第二服务进程中的组件与所述第三服务进程中的组件合并为所述第一服务进程。179.继续参见图4，图4中的服务进程1.1可以对应第二服务进程，图4中的服务进程1.2可以对应第三服务进程，图4中的服务进程1可以对应第一服务进程。也就是说，第二服务进程与第三服务进程合并变形为第一服务进程。180.应理解，服务进程的数量减少，必然导致系统架构发生变化。181.在本实施例中，将第二服务进程与第三服务进程未合并变形时的系统架构视为第一系统架构，将第二服务进程与第三服务进程进行合并变形后的系统架构视为第二系统架构。也就是说，通过服务进程的合并变形，实现了系统架构的切换(由第一系统架构切换为第二系统架构)。182.在本实施例中，通过将所述第二服务进程与所述第三服务进程合并为所述第一服务进程，实现了将所述第一系统架构切换为所述第二系统架构。其中，第一系统架构中服务进程的数量不同于第二系统架构中服务进程的数量。183.应理解，通过服务进程的合并变形，实现了系统架构的动态切换。184.因此，在本技术实施例中，通过服务进程的数量的动态变化实现了服务进程的动态变形，从而实现了系统架构的动态变形，因此，可以实现系统架构的动态切换。185.还应理解，一个服务进程被预先划分为彼此之间数据不耦合的多个组件，且基于这些多个组件，服务进程可以进行拆分变形与合并变形，这为一个系统架构既可以变形为高安全系统架构，又可以变形为高性能系统架构，提供了可能性。186.实施方式二：服务进程的特权级的改变(提权变形或降权变形)187.可选地，在一些实施例中，第一系统架构包括第一服务进程；步骤s310包括：改变第一服务进程的特权级。188.改变所述第一服务进程的特权级包括提权处理与降权处理。提权处理表示提升服务进程的特权级。降权处理表示降低服务进程的特权级。189.假设第一服务进程初始的特权级为非特权态，在需要切换系统架构时，可以将第一服务进程的特权级改为特权态。第一服务进程的这种变形可以称为提权变形。190.假设第一服务进程初始的特权级为特权态，在需要切换系统架构时，可以将第一服务进程的特权级改为非特权态。第一服务进程的这种变形可以称为降权变形。191.作为示例，如图5所示。在图5中，为了区分而非限定，将位于特权态的服务进程2记为服务进程2，将位于非特权态的服务进程2记为服务进程2'。如图5所示，服务进程2可以进行提权变形，即服务进程2的特权级由非特权态变为特权态；服务进程2也可以进行降权变形，即服务进程2的特权级由特权态变为非特权态。192.应理解，服务进程的特权级发生变化，必然导致系统架构发生变化。193.在本实施例中，将第一服务进程的特权级未发生变化时的系统架构视为第一系统架构，将第一服务进程的特权级发生变化后的系统架构视为第二系统架构。也就是说，通过服务进程的提权变形或降权变形，实现了系统架构的切换(由第一系统架构切换为第二系统架构)。194.在实施方式二中，通过改变第一服务进程的特权级，实现了将所述第一系统架构切换为所述第二系统架构。其中，第一系统架构中第一服务进程的特权级与第二系统架构中第一服务进程的特权级不同。195.在本技术实施例中，通过改变服务进程的特权级，实现了系统架构的动态切换。196.在某些系统架构下，不同特权级的地址不同，这种情况下，服务进程的特权级改变(降权变形或提权变形)，引起服务进程的地址(包括代码地址与数据地址)发生改变，因此会涉及到服务进程的重新加载与重定向的问题。例如，在arm架构下，内核态(el1)运行在高地址，用户态(el0)运行在低地址，当服务进程的特权级由内核态降权至用户态，其地址发生改变，即由高地址变为低地址。197.高地址、低地址是计算机领域里通用的概念。高地址与低地址是相对而言的，即相对地址编码的大小而言。本文对此不作详述。198.可选地，在涉及服务进程的特权级发生变化的实施例(例如，在上文描述的实施方式二或实施例方式三)中，在不同特权级的地址不同的情况下，第一服务进程是采用数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制创建的。199.代码段支持地址无关的重定位的机制表示，无论服务进程的代码段的地址是否发生变化，都可以保证服务进程的运行。换句话说，服务进程的运行与代码段的地址无关。200.数据段支持地址无关的重定位的机制表示，表示，无论服务进程的数据段的地址是否发生变化，都可以保证服务进程的运行。换句话说，服务进程的运行与数据段的地址无关。201.例如，可以根据系统架构，选择合适的地址无关的重定位的机制来创建服务进程。202.可选地，第一服务进程的特权级包括第一特权级态与第二特权级态，其中，第一特权级态使用低地址，第二特权级态使用高地址；其中，数据段支持地址无关的重定位的机制包括，将第一服务进程的数据段始终映射在低地址。203.可选地，第一特权级态与第二特征级态中的一个表示非特权态，另一个表示特权态。204.可选地，第一特权级态与第二特征级态均为特权态，其中一个的特权级高于另一个的特权级。205.将第一服务进程的数据段始终映射在低地址的操作包括：静态配置与动态维持。静态配置指的是，在第一服务进程运行之前，通过静态配置将第一服务进程的数据段映射在低地址。动态维护指的是，当在运行过程中第一服务进程的特权级发生变化(即引起数据段地址变化)，动态维持数据段仍然映射在低地址。206.作为示例，如图6中(b)所示。配置mmu，使得el0使用低地址的页表0，el1使用高地址的页表1。对于代码段，利用类似位置无关可执行程序(positionindependentexecutable，pie)的手段生成地址无关的代码段。对于数据段，则始终保持映射在低地址的页表0中。在arm架构中，当服务进程运行时，高地址页表1中的代码可以直接访问低地址页表0中的数据，反之则会被阻止。通过利用这一点，在本技术实施例中，通过保持数据段在低地址，并设置代码段地址无关，则可以在运行时对服务进程进行动态降权与提权，且不会影响程序执行。207.换句话说，在图6中的(b)所示的方法中，使用pie技术生成地址无关可执行文件时，数据段始终映射为低地址。当进程运行在不同特权级el1/el0时，仅代码段发生地址改变，数据段始终映射为低地址。208.因此，通过图6中(b)所示方法，能够保证在进程运行时改变进程的特权级，对代码和数据的访问不受影响。209.可选地，数据段支持地址无关的重定位的机制包括对第一服务进程的数据段进行地址翻译处理，使得第一服务进程在特权级改变之后的数据段与在特权级改变之前的数据段映射至相同的地址；代码段支持地址无关的重定位的机制包括对第一服务进程的代码段进行地址翻译处理，使得第一服务进程在特权级改变之后的代码段与在特权级改变之前的代码段映射至相同的地址。210.可以采用硬件或软件的方式，对所述第一服务进程的代码段与数据段进行地址翻译处理。211.作为示例，如图6中(c)与(d)所示。212.如图6中(c)所示，在非特权态使用低地址，特权态使用高地址的情况下，在硬件中引入地址处理模块(如图6中(c)所示的地址处理的方框)，使得高地址的代码段经过地址处理模块的处理后能够与低地址的代码段映射到同样的物理页中，使得高地址的数据段经过地址处理模块的处理后能够与低地址的数据段映射到同样的物理页中。这样，在第一服务进程运行时，第一服务进程地址的改变不会对硬件产生影响。213.因此，通过图6中(c)所示方法，能够保证在进程运行时改变进程的特权级，对代码和数据的访问不受影响。214.应理解，图6中(c)所示方法为采用硬件的方式对所述第一服务进程的代码段与数据段进行地址翻译处理。215.如图6中(d)所示，通过对代码和数据进行软件层面的翻译(对应于，图6(d)中所示的“中间翻译/地址处理”为中间翻译)，使得服务进程运行在不同特权级时，代码段与地地址段的地址经过软件层面的翻译，处理为正确的高地址与低地址，再利用翻译后的地址访问硬件的mmu。216.例如，对代码和数据进行软件层面的翻译的手段包括但不限于，利用虚拟化技术的影子页表、二级页表、或直接利用软件实现翻译表等手段。217.继续参见图6中的(d)，也可以通过对代码与数据进行硬件层面的翻译(对应于，图6(d)中所示的“中间翻译/地址处理”为地址处理)，使得服务进程运行在不同特权级时，代码段与地地址段的地址经过硬件层面的翻译，处理为正确的高地址与低地址，再利用翻译后的地址访问硬件的mmu。218.应理解，在图6中(d)中，若通过对代码和数据进行软件层面的翻译，则该方法为采用软件的方式对所述第一服务进程的代码段与数据段进行地址翻译处理；若通过硬件模块对代码和数据的地址进行处理，以到达翻译地址的目的，则该方法为采用硬件的方式对所述第一服务进程的代码段与数据段进行地址翻译处理。219.因此，通过图6中(d)所示方法，能够保证在进程运行时改变进程的特权级，对代码和数据的访问不受影响。220.现有技术中，改变进程的特权级的方式为，先销毁旧的进程，再重新生效新的进程。即现有技术无法实现在服务进程运行过程中改变服务进程的特权级。221.在本技术中，通过采用数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制来创建服务进程，可以支持在服务进程的运行过程中动态改变服务进程的特权级，从而可以通过动态改变服务进程的特权级实现系统架构的动态切换。222.可选地，在通过动态改变服务进程的特权级来实现系统架构的动态切换的实施方式中，可以配置系统架构本身允许不同特权级使用相同的地址空间。223.支持地址无关的重定位的机制包括：通过系统配置，使得系统架构本身允许不同特权级使用相同的地址空间。224.如图6中(a)所示，配置内存管理单元(memorymanagementunit，mmu)，使得用户态(el0)与内核态(el1)均使用同样的页表和基址寄存器。在这种方案下，不需要对编译的二进制进行特殊处理，改变进程的特权级不会产生异常影响。225.因此，通过图6中(a)所示方法，能够保证在进程运行时改变进程的特权级，对代码和数据的访问不受影响。226.应理解，图6中(a)所示的方案，使得用户态(el0)与内核态(el1)均使用同样的页表和基址寄存器，该方案可能会牺牲硬件提供的安全特性。227.应理解，可以采用图6中(a)、(b)、(c)、(d)所示的四种方法中的任一种方法来创建第一服务进程，这样可以支持在第一服务进程运行过程中动态改变第一服务进程的特权级。228.通过支持地址无关的重定位的机制，可以支持在运行时调整服务进程的特权级，即可以支持通过调整服务进程的特权级来切换系统架构。229.因此，在本实施例中，通过服务进程的特权级的动态变化实现了服务进程的动态变形，从而实现了系统架构的动态变形，因此，可以实现系统架构的动态切换。例如，根据应用场景的变化，在进程运行时对进程进行提权处理或降权处理。230.实施方式三，实施方式一与实施方式二的组合231.可选地，在一些实施例中，第一系统架构包括第一服务进程，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；步骤s310包括：基于多个组件，将第一服务进程拆分为多个子服务进程，并改变多个子服务进程中一个或多个子服务进程的特权级，使得该一个或多个子服务进程的特权级与第一服务进程的特权级不同，其中，每个子服务进程包括多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。232.作为示例，如图7所示。服务进程3预先被划分为3个组件：组件1、组件2与组件3，其中，组件1、组件2与组件3之间的数据不耦合。服务进程3的特权级为特权态。如图7所示，服务进程3可变形为服务进程3.1与服务进程3.2，其中，服务进程3.1的特权级为特权态，服务进程3.2的特权级为非特权态。服务进程3.1由组件1与组件2形成，服务进程3.2由组件3形成。因为不同进程的地址不同，即进程之间是隔离的，因此，可以视为，组件1与组件2隔离为服务进程3.1，组件3隔离为服务进程3.2。可以理解到，关于服务进程3.2，不仅进行了拆分变形，还进行了降权变形。即，在图7的示例中，服务进程的变形既包括服务进程数量的变化，还包括特权级的变化。233.在图7中，服务进程3到服务进程3.1与服务进程3.2的变形是可逆的，即服务进程3.1与服务进程3.2也可逆变形为服务进程3。该逆变形过程包括服务进程的合并变形与提权变形。234.应理解，本文中提及的逆变形是个相对概念。例如，在图7中，也可以将服务进程3.1与服务进程3.2的变形视为正变形，相应地，将服务进程3到服务进程3.1与服务进程3.2的变形视为逆变形。235.还应理解，服务进程的数量以及特权级发生变化，必然导致系统架构发生变化。236.在实施方式三中，第一服务进程拆分得到的一个或多个子服务进程的特权级与所述第一服务进程的特权级不同，也属于第一服务进程的特权级发生变化的情形。在不同特权级的地址不同的情况下，所述第一服务进程是采用数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制创建的。关于数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制，参见前文相关描述，这里不再赘述。237.在本实施例中，通过将第一服务进程拆分为所述多个子服务进程，并改变所述多个子服务进程中一个或多个子服务进程的特权级，实现了将所述第一系统架构切换为所述第二系统架构。其中，第一系统架构中服务进程的数量与第二系统架构中服务进程的数量不同，并且，第一系统架构中服务进程的特权级与第二系统架构中服务进程的特权级也不同。238.因此，在本实施例中，通过服务进程的数量与特权级的动态变化，实现了服务进程的动态变形，从而实现了系统架构的动态变形，因此，可以实现系统架构的动态切换。239.应理解，图4、图5与图7仅为示例而非限定。240.实际应用中，采取上述实施方式一、实施方式二与实施方式三中的哪一种方式进行系统架构的切换，可以根据应用场景确定。241.例如，应用场景对系统架构的安全的要求较高，而当前系统架构为高性能系统架构，这种情形下，可以采用如下操作中的任一种进行系统架构的切换。242.1)采用实施方式一进行服务进程的拆分变形，以保证更细粒度的错误隔离，例如，当异常发生时，出错的服务进程行为不会影响到其他服务进程。243.2)采用实施方式二进行服务进程的降权变形，使得服务进程运行在非特权态。244.3)采用实施方式三进行服务进程的拆分变形与降权变形(或二者之一)。245.又例如，应用场景对系统架构的通信效率的要求较高，而当前系统架构为高安全系统架构，这种情形下，可以采用如下操作中的任一种进行系统架构的切换。246.1)采用实施方式一进行服务进程的合并变形，可以实现服务进程之间具有耦合，减小通信开销，使得系统达到较好的性能。247.2)采用实施方式二进行服务进程的提权变形，使得服务进程运行在特权态。例如，使服务进程可以直接访问某些硬件寄存器，以降低通信的开销，248.3)采用实施方式三进行服务进程的合并变形与提权变形(或二者之一)。249.基于上述描述可知，在本技术实施例中，服务进程在运行时能够动态变形，例如，拆分变形、合并变形、提权变形或降权变形，这可以实现系统架构的动态变形。因此，本技术可以根据应用场景的变化自适应调整系统架构，从而可以在运行时动态满足应用场景对不同系统架构的需求。250.此外，在本技术实施例中，一个系统架构能够支持不同种架构的变形，因此只需用于实现这一个系统架构的一份代码即可，从而可以减小代码开销。应理解，一份代码能够在服务不中断、业务不下线的前提下，针对应用场景较细粒度地调整系统架构，从而使得系统架构的切换更加灵活，底噪更小。251.在现有的在系统内实现多种系统架构的方案中，当切换系统架构时，原先的服务会先被停掉，新的服务重复重新启动。从业务侧来看，原先的服务请求会被打断，需要重新发起新的服务请求，服务也会有短暂的中断以同步之前的状态，即，现有技术在切换系统架构时无法做到业务的无感知。252.针对该问题，本技术实施例提出，通过设置通信接口的参数传递规范(callingconvention)统一来解决。下面将进行描述。下文中，将参数传递规范简称为传参规范。本文提及的“传参规范统一”也可以表述为“传参规范一致”。253.可选地，在上述一些实施例中，涉及到变形的服务进程的所有通信接口的传参规范统一。该通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。254.函数调用通信接口表示函数调用对应的通信接口。特权级间通信接口表示特权级之间进行通信的通信接口。进程间通信接口表示进程之间进行通信的通信接口。255.涉及到变形的服务进程的所有通信接口的参数传递规范统一表示，服务进程的所有通信接口进行请求调用的传参规范统一，所有通信接口进行结果返回的传参规范也统一。或者，涉及到变形的服务进程的所有通信接口的参数传递规范统一还可以表述为，服务进程的各个通信接口的请求调用与结果返回的传参规范统一。256.通过设置传参规范统一的通信接口，可以使得不同通信接口(不同通信接口的传参参数规范一致)的请求调用与结果返回可以相互替换，且这种替换不会造成服务中断，从而可以实现在系统架构动态切换时业务无感知。下面参照图8进行说明。257.如图8中的(a)所示，当服务进程1在内核态(kernel态，如图8中的el1)时，服务进程1中的组件1与组件2之间通过函数调用进行通信。例如，组件1通过函数调用的方式向组件2调度请求，组件2通过函数调用的方式向组件1返回结果。当函数调用发起后，参数传递依据arm函数调用标准(armprocedurecallstandard，apcs)规范进行传递，被调用者根据调用信息开始进行计算。258.作为一个示例。当发生系统架构调整时，如图8中的(b)所示，服务进程1被拆分为服务进程1.1与服务进程1.2，其中，服务进程1.1由组件1形成，服务进程1.2由组件2形成，并且，服务进程1.2(例如，可以视为服务进程1中的组件2部分)被降权到用户态(el0)。当服务进程1.2完成计算后需要返回结果时，无法通过函数调用直接将返回结果返回到组件1(如图8中(b)所示的“结果返回受阻”)。259.如果设置进程间调用通信接口、特权级间调用通信接口、函数调用通信接口的参数传递规范统一(或称为参数传递规范统一)，则服务进程1.2的返回结果可以通过特权级间调用的形式返回到服务进程1.1，如图8中的(c.1)所示。260.作为另一个示例。当发生系统架构调整时，如图8中的(c.2)所示，服务进程1被拆分为服务进程1.1与服务进程1.2，其中，服务进程1.1由组件1形成，服务进程1.2由组件2形成，并且，服务进程1.1(例如，可以视为服务进程1中的组件1部分)与服务进程1.2(例如，可以视为服务进程1中的组件2部分)均被降权到用户态(el0)。在现有技术中，若发生如图8中的(c.2)所示的系统架构动态切换，服务进程1.2完成计算后是无法直接通过函数调用将结果返回到组件1的。但是，如果设置进程间调用通信接口、特权级间调用通信接口、函数调用通信接口的参数传递规范统一(或称为参数传递规范统一)，则服务进程1.2的返回结果可以通过进程间调用(ipc)的形式返回到服务进程1.1，如图8中的(c.2)所示。261.从上文结合图8的描述可知，通过设置传参规范统一的通信接口，可以使得不同通信接口(不同通信接口的传参参数规范一致)的请求调用与结果返回可以相互替换，且这种替换不会造成服务中断，因此，针对应用程序(app)的服务请求，可以使用不同的通信方式进行请求调用与结果返回，从而可以实现在系统架构动态切换时业务无感知。262.还应理解，通过设计参数传递规范统一的通信接口(例如，函数调用通信接口、特权级间通信接口、进程间通信接口)，这样可以摆脱在服务进程发生改变(即系统架构发生改变)后，通信上下文需要同步的问题。因为无需同步通信上下文，因此，可以实现业务无感知。263.例如，在系统架构切换时已经处理到一半的请求，可以在系统架构切换后继续处理。264.此外，在系统架构切换时，因为无需进行状态同步，也可以避免引入额外的状态拷贝开销。265.服务进程的通信接口的传参规范统一的实施例可以应用于上述的实施方式一、实施方式二与实施方式三。266.可选地，在上述实施方式一中，第一服务进程的所有通信接口、多个子服务进程中每个子服务进程的所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。267.在本实施例中，第一服务进程预先被划分为多个独立的组件，且各个组件之间的通信接口的传参规范统一(即各个组件之间使用统一传参规范的通信接口进行通信)。多个独立的组件表示，各个组件之间的数据不耦合，互相之间不直接访问资源，而是通过通信接口进行成员访问。268.应理解，在本实施例中，在通过服务进程的拆分变形或合并变形实现系统架构的动态切换时，可以实现业务无感知。269.可选地，在上述实施方式二中，第一服务进程的所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。270.应理解，在本实施例中，在通过服务进程的特权级的变化实现系统架构的动态切换时，可以实现业务无感知。271.可选地，在上述实施方式三中，第一服务进程的所有通信接口、多个服务进程中每个服务进程的所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。272.作为示例，如图9所示。图9中示出两种互相可变形的系统架构：第一系统架构与第二系统架构。图9中的a1、a4、b4表示特权级间调用；a2、a3、b3、b5表示进程间调用。在图9中，以app向服务进程2请求服务为例。服务进程2预先被划分为组件1与组件2，其中，组件1与组件2之间的数据不耦合(即解耦)。在图9中，通信接口a1、a4、b4、a2、a3、b3、b5以及服务进程2在未拆分变形之前所包括的组件1与组件2之间的函数调用通信接口的传参规范统一。273.参见图9中左图。在第一系统架构中，app通过特权级间调用a1向服务进程2请求服务；服务进程2通过进程间调用a2请求服务进程1；服务进程1在完成app所请的服务后，通过进程间调用a3将服务响应结果返回给服务进程2，服务进程2通过特权级间调用a4将服务响应结果返回给app。274.参见图9中左图与右图可知，第一系统架构到第二系统架构的变形方式为，服务进程2拆分变形为服务进程2.1与服务进程2.2，其中，服务进程2.1由组件1构成，服务进程2.2由组件2构成，服务进程2.1继续运行在内核态(el1)，服务进程2.2被进行了降权处理，运行在用户态(el0)。275.假设在服务进程2中，是由组件2负责处理app的请求。在第一系统架构下，在app通过特权级间调用a1向服务进程2请求服务后，组件2通过函数调用(图9中未画出)请求组件1，组件1通过进程间调用a2请求服务进程1。假设在此时，动态发生由图9中左图所示第一系统架构变形为图9中右图所示第二系统架构的架构调整。由于函数调用通信接口(组件1与组件2的通信接口，图9中未示出)、进程间调用通信接口(a2、a3、b3、b5)、特权级间调用通信接口(a1、a4、b4)的传参规范统一，因此，在系统架构调整结束时，服务进程1可以直接通过进程间调用b3将服务响应结果返回给服务进程2.1，服务进程2.1通过特权级间调用b4将服务响应结果返回给服务进程2.2，服务进程2.2可以直接通过进程间调用b5将服务响应结果最终返回给app。对于app来说，虽然特权级间调用a1与进程间调用b5所使用的通信接口的实现不同(应理解，这是由系统架构的动态调整引起的)，但这对app来说，是无感知的。也就是说，由图9中左图所示第一系统架构变形为图9中右图所示第二系统架构的架构调整，是业务无感知的。276.可知，在图9的示例中，服务进程2中的组件1与组件2之间通过函数调用互相访问，当服务进程2拆分变形为服务进程2.1与服务进程2.2后，服务进程2.1与服务进程2.2之间的通信方式为特权级间调用，可以理解为，服务进程2中的组件1与组件2之间的通信方式由函数调用切换为了特权级间调用。277.需要说明的是，在第二系统架构中，app也可以直接通过进程间调用访问服务进程2.2。278.在图9的示例中，系统架构调整之前，即在第一系统架构中，服务进程2中的组件1与组件2运行在内核态(el1)的同一地址空间中，相互之间使用函数调用进行访问，此时通信开销最小，仅为一个函数调用的时间开销。在系统架构调整之后，即在第二系统架构中，组件1与组件2之间的通信方式由函数调用变为特权级间通信，此时通信开销会略微增大，但是，组件1与组件2分别隔离为服务进程2.1与服务进程2.2，且服务进程2.2被降权至用户态，这样可以有效提升系统整体的安全韧性。279.例如，图9中所示的第一系统架构可以视为高性能系统架构，图9中所示的第二系统架构可以视为高安全系统架构。280.从图9的示例可知，通过将通信接口的传参规范设置为一致，可以实现，针对同一个服务请求，可以使用不同的通信方式进行请求调用与结果返回，并且这个过程是业务无感知的。281.应理解，在本实施例中，在通过服务进程的拆分变形或合并变形，以及特权级的变化来实现系统架构的动态切换时，可以实现业务无感知。282.可选地，在上述一些实施例中，第一系统架构中所有通信接口以及第二系统架构中所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。283.基于上述描述，在本技术实施例中，通过设置传参规范统一的通信接口，可以使得不同通信接口(不同通信接口的传参参数规范一致)的请求调用与结果返回可以相互替换，且这种替换不会造成服务中断，从而可以实现在系统架构动态切换时业务无感知。284.例如，本技术实施例提供的系统架构可以应用于iot等资源受限的应用场景。285.为了更好地理解本技术实施例，下面结合图10描述一个本技术实施例中实现系统架构动态切换的例子。如图10所示，实现系统架构动态切换的过程可以包括线下的静态部分与运行时的动态部分，其中线下的静态部分是运行时进行动态切换的基础。286.线下的静态部分包括：传参规范统一的通信接口设计实现、组件资源划分、地址无关方案选型与对应实现。287.运行时的动态部分主要包括：服务进程进行拆分变形或合并变形时对资源映射的调整，服务进程进行降权变形或提权变形时对服务进程的特权级的调整，以及调整前后通信接口的切换。288.s1010，设计传参规范统一的通信接口。289.以arm系统为例。arm现有的函数调用规范apcs或aapcs(procedurecallstandardforthearmarchitecture)规定了函数传参与返回的顺序，同时规定了调用者(caller)与被调用(callee)分别负责保存的寄存器。aapcs为arm架构新的函数调用标准，用于arm64。290.类似地，本技术实施例设计了相同参数传递规范的特权级间调用与进程间调用。291.例如，设计使得涉及到变形的服务进程的所有通信接口的参数传递规范统一，其中，该通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。292.又例如，设计使得系统中所有的函数调用通信接口、特权级通信接口与进程间通信接口的参数传递规范统一。293.当保证进程间调用、特权级间调用、函数调用的函数传递规范一致时，调用者的调用和被调用者的返回可以使用不同的接口。294.具体描述，详见前文结合图8的描述，这里不再赘述。295.s1020，划分进程资源。296.为了满足运行时的动态拆分，进程资源需要提前划分为各个组件。各个组件之间的数据不耦合，调用时统一通过暴露的函数接口进行成员访问(即取消对共享变量的直接访问)。在编译时各组件的代码和数据各自集中映射。297.例如，图4中的服务进程1的资源被静态划分为3个组件：组件1、组件2与组件3。各个组件的代码数据各自集中映射。298.s1030，实现地址无关。299.在某些架构下，当服务进程的特权级改变时会进行重定位加载，其地址会发生改变。例如，在arm架构下，内核态(el1)运行在高地址，用户态(el0)运行在低地址。例如，当服务进程的特权级由内核态降权至用户态，其地址由高地址变为低地址。300.为了应对运行时服务进程的特权级发生动态变化，需要结合系统架构选择合适的地址无关方案来编译生成对应的可执行文件。301.例如，可以采用图6中(a)、(b)、(c)、(d)所示的四种方法中的任一种来编译生成对应的可执行文件。具体描述详见前文描述，为了简洁，这里不再赘述。302.s1050，替换通信接口状态。303.拆分变形前，服务进程可能已处于服务app的状态中，假设该服务进程中正在服务的组件为图4中的组件3；当步骤s1040完成后，组件3位于服务进程1.2中。服务进程1.1由于已不再需要服务app，因此，进程上下文被重新初始化为等待服务状态。服务进程1.2则依照拆分变形前的进程上下文继续进行服务处理，处理结束后，服务进程1.2负责将结果返回给用户态app。304.s1060，服务进程在变形时，对特权级的调整。305.当内核决定对服务进程进行提权处理或降权处理时，需要修改对应服务进程的状态寄存器调整对应的特权级。由于经过步骤s10300，进程可以直接运行在el0或el1，因此当进程的特权级被调整后，可以继续运行而不受影响。306.s1070，切换服务进程的特权级。307.由于一般各特权级使用各自的页表寄存器、上下文寄存器，因此，当进程的特权级被修改后，调度器在调度到不同特权级的进程时，需要更换使用对应特权级的上下文寄存器与页表寄存器。例如当服务进程被从el1调整为el0时，在下次调度器调度到该进程时，会选择切换el1的页表基址寄存器，切换上下文时，选择对应特权级的栈寄存器等。308.s1080，替换通信接口状态。309.该步骤类似步骤s1050，在调整特权级前，进程可能已处于服务app状态中，假设要调整特权级的进程为图8中(c.1)与(c.2)中的服务进程1.1。在调整特权级前，服务运行在el1，用户态app或其他服务通过特权级间调用访问服务进程1.1。此时，服务进程1.1被调整到了el0，如图8中(c.2)，由于原有服务为特权级间调用(例如，系统调用)，调整为el0之后内核需要修改服务进程1.1的上下文状态，当服务进程1.1完成服务后会利用进程间调用(ipc)将返回结果传入内核，然后，返回结果会继续通过进程间调用(ipc)返回给调用者app。310.s1090，切换通信接口。311.当通信接口的状态被替换完成后，系统会依据调整后的架构切换后续服务的通信接口。不同特权级间、进程间与进程内的通信方式如图8所示，详见前文描述。312.需要说明的是，图10仅为示例。313.例如，图10中的步骤s1030、s1060、s1070与s1080是可选的。例如，仅通过服务进程的拆分变形或合并变形来实现系统架构的动态切换。314.又例如，图10中的步骤s1020、s1040与s1050是可选的。例如，仅通过服务进程的特权级的改变(提权变形或降权变形)来实现系统架构的动态切换。315.实际应用中，可以根据应用需求灵活设计一个可变形的系统架构。只要是通过一个可变形的系统架构实现系统架构的动态切换的方案，都落入本技术的保护范围。316.本技术实施例可以应用于各种计算机系统的架构调整。317.下面以本技术实施例应用于无线rru场景rtosv3版本中文件系统的架构调整为例，进行说明。318.在无线rru场景rtosv3版本中，采用的是微内核架构。微内核提供ipc、中断和最基础的调度功能，其中内核管理、进程管理、文件系统、驱动均以单独的进程形式独立运行。通过将各个服务进程隔离为单独的进程，服务进程之间的错误会被隔离而不会影响到系统的其它部分。而微内核本身经过了形式化验证，其稳定性与安全性是远高于其它服务进程的，通过这种方式可以保证系统能够稳定运行。319.在业务运行过程中，一个常见的流程是用户态的应用程序(app)需要写日志(log)或请求驱动服务进程(drivers)的功能，其路径如图11所示。app将文件描述符号(filedescriptor，fd)发送给dev文件系统服务进程(devfs)，请求向该fd中写入日志，devfs会根据自身的知识解析fd并找到drivers，调用drivers的功能，drivers本身再调用fat文件系统服务进程(fatfs)的接口请求向闪存(flash)中写入文件。320.如图11所示，fatfs为闪存(flash)文件系统，devfs为驱动文件系统(filesystem，fs)，微内核为验证过的安全可信的内核，drivers为运行在用户态的驱动，app为rru业务软件。321.当业务需要进行大量日志读写时，为了提高效率，系统可以使用文件系统耦合的系统架构(fsmerged架构)，如图11中左图所示。通过将devfs与fatfs合并，两者可以协同使用文件系统中的缓存页，提高缓存利用率；通过将devfs提权到内核态，devfs可以直接访问app的数据，在fsmerged架构下，应用请求方向为特权级间调用a1→特权级间调用a2→特权级间调用a3。在arm架构下，该过程只需要3次特权级间通信即可完成。322.当业务不需要集中进行大量文件写入时，系统架构可在运行时调整为文件系统解耦的系统架构(fssplit架构)，如图11中右图所示。在此场景下，devfs被降权到用户态，调用过程为进程间调用b1→进程间调用b2→特权级间调用b3。可知，在fssplit架构下，需要2次ipc和一次特权级间通信，其中，2次ipc的开销要高于特权级间通信的开销，且fatfs与devfs无法通过函数调用进行协作。虽然牺牲了些许性能，但fssplit架构能够避免devfs中发生错误时影响整个文件系统。例如，在此场景下，即使devfs出错，写错数据也丝毫不会影响flash中文件的正确性。323.在rtosv2版本中，内核使用的是linux宏内核，linux宏内核架构与图11所示的fsmerge架构、fssplit架构在系统安全方面的对比结果如表1所示。324.表1merge架构更符合业务场景的大文件写(log大量写入)与随机读写(各模块log打点)。本技术实施例提供的方案，在运行时可以随时调整系统架构，从而可以更细致的对产品业务场景进行自适应，例如，可以在业务性能不下降的前提下大大提升产品的安全韧性。333.基于上文描述，本技术实施例通过可变形的系统架构实现系统架构的动态切换，使得可以只需实现一个系统架构即可实现不同架构的切换，因此只需用于实现这一个系统架构的代码，相对于现有技术，可以减小代码开销。334.此外，通过设置传参规范统一的通信接口，可以使得不同通信接口(不同通信接口的传参参数规范一致)的请求调用与结果返回可以相互替换，且这种替换不会造成服务中断，从而可以实现在系统架构动态切换时业务无感知。335.本文中描述的各个实施例可以为独立的方案，也可以根据内在逻辑进行组合，这些方案都落入本技术的保护范围中。336.上文描述了本技术提供的方法实施例，下文将描述本技术提供的装置实施例。应理解，装置实施例的描述与方法实施例的描述相互对应，因此，未详细描述的内容可以参见上文方法实施例，为了简洁，这里不再赘述。337.如图12所示，本技术实施例提供一种切换系统架构的装置1200，该装置1200包括：切换单元1210与处理单元1220。338.切换单元1210，用于将第一系统架构变形为第二系统架构，第一系统架构表示切换之前的系统架构，第二系统架构表示切换之后的系统架构。其中，第一系统架构与第二系统架构之间的关系为下列情况中的任一种或多种：第一系统架构中服务进程的特权级与第二系统架构中服务进程的特权级不同，第一系统架构中服务进程的数量与第二系统架构中服务进程的数量不同。339.处理单元1220，用于使用第二系统架构，为用户提供服务。340.可选地，作为一个实施例，第一系统架构包括第一服务进程；其中，切换单元1210用于，改变第一服务进程的特权级。341.可选地，在本实施例中，在不同特权级的地址不同的情况下，第一服务进程是采用数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制创建的。342.可选地，第一服务进程的特权级包括第一特权级态与第二特权级态，其中，第一特权级态使用低地址，第二特权级态使用高地址；其中，数据段支持地址无关的重定位的机制包括，将第一服务进程的数据段始终映射在低地址。343.可选地，数据段支持地址无关的重定位的机制包括对第一服务进程的数据段进行地址翻译处理，使得第一服务进程在特权级改变之后的数据段与在特权级改变之前的数据段映射至相同的地址；代码段支持地址无关的重定位的机制包括对第一服务进程的代码段进行地址翻译处理，使得第一服务进程在特权级改变之后的代码段与在特权级改变之前的代码段映射至相同的地址。344.可选地，在通过动态改变服务进程的特权级来实现系统架构的动态切换的实施例中，可以配置系统架构本身允许不同特权级使用相同的地址空间。345.可选地，作为另一个实施例，第一系统架构包括第一服务进程，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；其中，切换单元1210用于，基于多个组件，将第一服务进程拆分为多个子服务进程，其中，每个子服务进程包括多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。346.可选地，作为又一个实施例，第一系统架构包括第一服务进程，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；其中，切换单元1210用于，基于多个组件，将第一服务进程拆分为多个子服务进程，并改变多个子服务进程中一个或多个子服务进程的特权级，使得一个或多个子服务进程的特权级与第一服务进程的特权级不同，其中，每个子服务进程包括多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。347.可选地，作为又一个实施例，第一系统架构包括第一服务进程；其中，切换单元1210用于，改变第一服务进程的特权级；其中，第一服务进程的所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。348.可选地，作为又一个实施例，第一系统架构包括第一服务进程，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；切换单元1210用于，基于多个组件，将第一服务进程拆分为多个子服务进程，其中，每个子服务进程包括多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。其中，第一服务进程的所有通信接口、多个子服务进程中每个子服务进程的所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。349.可选地，作为又一个实施例，第一系统架构中所有通信接口以及第二系统架构中所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。350.例如，本技术实施例提供的切换系统架构的装置1200可以为计算机系统中的内核。351.如图13所示，本技术实施例还提供一种数据处理的装置1300。该装置1300包括处理器1310，处理器1310与存储器1320耦合，存储器1320用于存储计算机程序或指令，处理器1310用于执行存储器1320存储的计算机程序或指令，使得上文方法实施例中的方法被执行。352.可选地，如图13所示，该装置1300还可以包括存储器1320。353.可选地，如图13所示，该装置1300还可以包括数据接口1330，数据接口1330用于与外界进行数据的传输。354.如图14所示，本技术实施例还提供一种计算机系统1400，该计算机系统1400包括系统架构1410与处理器1420。系统架构1410可以支持多种架构的变形。本实施例中以系统架构1410的两种变形第一系统架构1411与第二系统架构1412为例进行描述。系统架构1411与第二系统架构1412可互相变形。355.处理器1420，用于控制系统架构1410的变形，并使用系统架构1410的一种变形架构提供服务。356.可选地，处理器1420用于，将第一系统架构1411变形为第二系统架构1412，第一系统架构1411表示切换之前的系统架构，第二系统架构1412表示切换之后的系统架构；使用第二系统架构1412，为用户提供服务。其中，第一系统架构1411与第二系统架构1412之间的关系为下列情况中的任一种或多种：第二系统架构1412中服务进程的特权级与第二系统架构1412中服务进程的特权级不同，第二系统架构1412中服务进程的数量与第二系统架构1412中服务进程的数量不同。357.可选地，处理器1420可以采用上文方法实施例中的方法300，将第一系统架构1411变形为第二系统架构1412。358.可选地，作为一个实施例，第一系统架构1411包括第一服务进程，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；其中，处理器1420用于，基于该多个组件，将第一服务进程拆分为多个子服务进程，从而将第一系统架构1411切换为第二系统架构1412，其中，每个子服务进程包括多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。359.具体参见上文对实施方式一的描述，这里不再赘述。360.可选地，作为另一个实施例，第一系统架构1411包括第一服务进程；其中，处理器1420用于，改变第一服务进程的特权级，从而将第一系统架构1411切换为第二系统架构1412。361.具体参见上文对实施方式二的描述，这里不再赘述。362.可选地，作为又一个实施例，第一系统架构1411包括第一服务进程，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；其中，处理器1420用于，基于该多个组件，将第一服务进程拆分为多个子服务进程，并改变多个子服务进程中一个或多个子服务进程的特权级，使得该一个或多个子服务进程的特权级与第一服务进程的特权级不同，从而将第一系统架构1411切换为第二系统架构1412，其中，每个子服务进程包括多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。363.具体参见上文对实施方式三的描述，这里不再赘述。364.可选地，第一服务进程的所有通信接口、多个服务进程中每个服务进程的所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。365.可选地，第一系统架构1411中所有通信接口以及第二系统架构1412中所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。366.具体参见前文相关描述，这里不再赘述。367.可选地，处理器1420可以采用图10所示的方法，将第一系统架构1411变形为第二系统架构1412。具体描述，详见上文，这里不在赘述。368.如图15所示，本技术实施例还提供一种计算机系统1500，该计算机系统1500包括处理器1510、策略库1520、服务进程1530、应用程序(app)1540。服务进程可以为内核功能的一部分，例如，为文件系统、内存管理、系统服务或其他服务等。369.策略库1520，用于存储切换系统架构的策略。370.例如，策略库1520存储的切换系统架构的策略，包括如上文实施例提及的服务进程拆分变形、服务进程合并变形、服务进程提权变形与服务进程降权变形。371.服务进程1530被预先划分为多个独立的组件，各个组件之间的数据不耦合。372.处理器1510，根据输入与策略库1520存储的策略，选择合适的系统架构切换策略，并根据选出的系统架构切换策略控制服务进程1530的变形，以实现系统架构的动态切换(或称为动态调整)。这里的输入可以为应用场景对系统架构的要求。373.处理器1510也可以称为内核。374.例如，处理器1510用于执行上文实施例中的方法，例如，图3所示的方法或图10所示的方法。375.可选地，服务进程1530的通信接口，以及服务进程1530中预先划分的多个独立组件之间的通信接口传参规范统一。例如，这些通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。376.可选地，计算机系统1500内的所有通信接口的传参规范统一。377.本技术实施例还提供一种计算机可读介质，该计算机可读介质存储用于设备执行的程序代码，该程序代码包括用于执行上述实施例的方法。378.本技术实施例还提供一种包含指令的计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述实施例的方法。379.本技术实施例还提供一种芯片，该芯片包括处理器与数据接口，处理器通过数据接口读取存储器上存储的指令，执行上述实施例的方法。380.可选地，作为一种实现方式，该芯片还可以包括存储器，存储器中存储有指令，处理器用于执行存储器上存储的指令，当指令被执行时，处理器用于执行上述实施例中的方法。381.除非另有定义，本文所使用的所有的技术和科学术语与属于本技术的
技术领域：
：的技术人员通常理解的含义相同。本文中在本技术的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本技术。382.需要说明的是，本文中涉及的第一、第二、第三或第四等各种数字编号仅为描述方便进行的区分，并不用来限制本技术实施例的范围。383.本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的范围。384.所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。385.在本技术所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。386.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。387.另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。388.所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：通用串行总线闪存盘(usbflashdisk，ufd)(ufd也可以简称为u盘或者优盘)、移动硬盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。389.以上所述，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何熟悉本
技术领域：
：的技术人员在本技术揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以所述权利要求的保护范围为准。当前第1页12当前第1页12
再多了解一些
本文用于企业家、创业者技术爱好者查询，结果仅供参考。
