服务器常用基本框架
框架体系知识点总结
框架体系知识点总结一、框架概述1.1 框架定义1.2 框架特点1.3 框架分类二、框架体系结构2.1 框架组成2.2 框架层次2.3 框架模式三、框架设计原则3.1 抽象原则3.2 封装原则3.3 继承原则3.4 多态原则四、常用框架介绍4.1 Spring框架4.2 Hibernate框架4.3 Struts框架4.4 框架4.5 Django框架五、框架应用实例5.1 Web开发框架应用5.2 移动端应用框架实践5.3 大数据框架应用案例5.4 人工智能框架应用场景六、框架技术发展趋势6.1 微服务框架6.2 前端框架发展趋势6.3 容器化框架6.4 人工智能开发框架七、框架体系的扩展7.1 插件化框架7.2 模块化框架7.3 可扩展性框架八、框架体系实践经验8.1 项目选择框架考虑因素8.2 框架组件选择与适配8.3 框架应用性能优化8.4 框架升级与维护以上是框架体系知识点总结的框架，接下来对每个部分进行详细的介绍。
一、框架概述1.1 框架定义框架是一种软件体系结构，它提供了开发应用程序所需的基础结构。
框架通常包括设计模式、类库、工具和其他组件，以及规定了开发过程中使用的约定和标准。
1.2 框架特点- 通用性：框架是通用的，可以用于不同领域的应用开发。
- 可重用性：框架中的组件和设计模式可以被多次使用。
- 优化性能：框架提供了经过优化的设计模式和算法。
- 易维护性：框架提供了模块化的设计，易于维护和扩展。
- 标准化：框架约定了开发过程中的标准和规范。
1.3 框架分类- 按应用领域分类：Web框架、移动端框架、大数据框架、人工智能框架等。
- 按语言分类：Java框架、.NET框架、Python框架、JavaScript框架等。
- 按设计模式分类：MVC框架、RESTful框架、ORM框架等。
二、框架体系结构2.1 框架组成一个完整的框架通常包括以下组成部分：- 核心组件：框架的基本组件和核心功能。
服务器架构方案
服务器架构方案服务器架构方案1·概述服务器架构方案是设计和规划企业服务器系统的文档，旨在确保服务器系统具有可靠性、高性能、可扩展性和安全性。
本文档将详细说明服务器架构的各个方面，并提供相应附件供参考。
2·服务器硬件2·1 主机需求：所需的服务器主机类型、规格和数量。
2·2 存储需求：说明对于数据存储的要求，包括存储容量、磁盘类型和冗余备份策略。
2·3 网络需求：描述服务器之间的网络拓扑结构，包括交换机、路由器和防火墙的配置。
3·服务器软件3·1 操作系统：指定所需的操作系统类型和版本。
3·2 应用软件：详细列出需要部署在服务器上的应用软件及其版本信息。
4·服务器架构4·1 主机集群：描述服务器集群的架构，如采用负载均衡和故障转移技术。
4·2 数据库架构：说明数据库的架构设计，包括主从复制、分布式架构等。
4·3 缓存架构：介绍缓存系统的架构设计，如使用分布式缓存技术。
4·4 备份和恢复策略：提供数据备份和系统恢复的策略和流程。
5·安全性5·1 身份验证和访问控制：详细描述用户身份验证和访问控制的措施，例如使用强密码、双因素认证等。
5·2 数据加密：说明数据在传输和存储过程中的加密机制。
5·3 防火墙和入侵检测系统：介绍防火墙和入侵检测系统的配置和运行原理。
6·可扩展性6·1 系统容量规划：预测系统使用情况并提供相应的扩展计划。
6·2 水平扩展：描述如何通过增加服务器数量来提高系统的扩展性。
6·3 垂直扩展：说明如何通过升级服务器硬件来提高系统的扩展性。
7·性能优化7·1 资源优化：指定如何合理分配和管理服务器的资源，包括CPU、内存和磁盘空间。
7·2 缓存优化：优化缓存系统以减少数据库和网络访问。
四种常见的系统架构
软件架构（software architecture）就是软件的基本结构。
合适的架构是软件成功的最重要因素之一。
大型软件公司通常有专门的架构师职位（architect），只有资深程序员才可以担任。
如果一个软件开发人员，不了解软件架构的演进，会制约技术的选型和开发人员的生存、晋升空间。
这里我列举了目前主要的4种软件架构以及他们的优缺点，希望能够帮助软件开发人员拓展知识面。
一、单体架构单体架构比较初级，典型的三级架构，前端(Web/手机端)+中间业务逻辑层+数据库层。
这是一种典型的Java Spring mvc或者Python Drango框架的应用。
其架构图如下所示：单体架构单体架构的应用比较容易部署、测试，在项目的初期，单体应用可以很好地运行。
然而，随着需求的不断增加，越来越多的人加入开发团队，代码库也在飞速地膨胀。
慢慢地，单体应用变得越来越臃肿，可维护性、灵活性逐渐降低，维护成本越来越高。
下面是单体架构应用的一些缺点：复杂性高：以一个百万行级别的单体应用为例，整个项目包含的模块非常多、模块的边界模糊、依赖关系不清晰、代码质量参差不齐、混乱地堆砌在一起。
可想而知整个项目非常复杂。
每次修改代码都心惊胆战，甚至添加一个简单的功能，或者修改一个Bug都会带来隐含的缺陷。
技术债务：随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越积越多。
“ 不坏不修”，这在软件开发中非常常见，在单体应用中这种思想更甚。
已使用的系统设计或代码难以被修改，因为应用程序中的其他模块可能会以意料之外的方式使用它。
部署频率低：随着代码的增多，构建和部署的时间也会增加。
而在单体应用中，每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。
全量部署的方式耗时长、影响范围大、风险高，这使得单体应用项目上线部署的频率较低。
而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复，出错率比较高。
可靠性差：某个应用Bug，例如死循环、内存溢出等，可能会导致整个应用的崩溃。
服务器的架构和组成
一．服务器概述服务器是指在局域网中，一种运行管理软件以控制对网络或网络资源（磁盘驱动器、打印机等）进行访问的计算机，并能够为在网络上的计算机提供资源使其犹如工作站那样地进行操作。
从广义上讲，服务器是指网络中能对其它机器提供某些服务的计算机系统（如果一个PC对外提供ftp服务，也可以叫服务器）。
从狭义上讲，服务器是专指某些高性能计算机，能通过网络，对外提供服务。
相对于普通PC来说，稳定性、安全性、性能等方面都要求更高，因此在CPU、芯片组、内存、磁盘系统、网络等硬件和普通PC 有所不同。
服务器作为网络的节点，存储、处理网络上80％的数据、信息，因此也被称为网络的灵魂。
做一个形象的比喻：服务器就像是邮局的交换机，而微机、笔记本、PDA、手机等固定或移动的网络终端，就如散落在家庭、各种办公场所、公共场所等处的电话机。
日常的生活、工作中的电话交流、沟通，必须经过交换机，才能到达目标电话；同样如此，网络终端设备如家庭、企业中的微机上网，获取资讯，与外界沟通、娱乐等，也必须经过服务器，因此也可以说是服务器在“组织”和“领导”这些设备。
服务器的构成与微机基本相似，有处理器、硬盘、内存、系统总线等，它们是针对具体的网络应用特别制定的，因而服务器与微机在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面存在差异很大。
服务器的功能：提供服务 - IP 地址将一种资源共享给多个请求者 - 数据库将一种设备共享给多个请求者 - 打印机为其他系统开放网关 - Web提供处理能力 - 数字存储内容 - 数据二．服务器的主要分类服务器往往被用于运行企业或个人的关键业务，所以对其性能与可靠性方面的要求会远远高于桌面电脑。
一般来说服务器的CPU、内存、网络、存储都会使用企业级部件。
譬如相比桌面电脑常用的Intel 酷睿系列CPU，服务器的CPU往往会采用性能更稳定强大的Intel至强（Xeon）系列或者IBM的Power系列。
选择合适的开发框架与工具
选择合适的开发框架与工具在选择开发框架和工具时，我们需要考虑多个因素，包括项目需求、技术要求、生态环境等。
下面将介绍一些常用的开发框架和工具，并讨论如何选择合适的框架和工具。
一、框架的选择1.前端框架：前端框架用于开发用户界面，常用的框架有React、Angular和Vue.js等。
选择框架时，需要考虑项目规模、开发团队的技术栈以及框架的性能和功能。
如果项目规模大且需要高度可定制的界面，可以选择React；如果项目需要高度集成和易用性，可以选择Angular；如果项目需要快速开发和轻量级框架，可以选择Vue.js。
2.后端框架：后端框架用于开发服务器端应用程序，常用的框架有Spring、Django和Express等。
选择框架时，需要考虑项目需求、开发语言和生态环境。
如果项目需要大量的企业级功能和对接各类企业系统，可以选择Spring；如果项目需要快速开发和强大的管理后台功能，可以选择Django；如果项目需要高性能和灵活性，可以选择Express。
3.移动端框架：移动端框架用于开发移动应用程序，常用的框架有Flutter、React Native和Ionic等。
选择框架时，需要考虑项目需求、开发技术和性能要求。
如果项目需要同时支持iOS和Android平台，并且开发团队熟悉Dart语言，可以选择Flutter；如果项目需要高度定制化和性能优化，可以选择React Native；如果项目需要快速开发和跨平台功能，可以选择Ionic。
二、工具的选择1.版本控制工具：版本控制工具用于管理代码的版本，常用的工具有Git和SVN等。
选择工具时，需要考虑开发团队的规模、分布和开发流程。
如果开发团队分布广泛或经常需要协作，可以选择Git；如果开发团队较小或需要集中管理代码，可以选择SVN。
2.集成开发环境（IDE）：IDE用于开发和调试代码，常用的工具有Visual Studio Code、IntelliJ IDEA和Eclipse等。
三层架构详解范文
三层架构详解范文
三层架构是由客户端（终端）-服务器端（网络）-数据库服务器（数
据库）组成的三层结构，主要应用于客户端和服务器之间的应用架构，为
客户端和服务器之间的通信和数据存储提供一种简单、高效、可靠的解决
方案。
一、客户端：客户端是三层架构的直接参与者，它完成了用户的信息
执行功能。
它容易被用户认可，用户可以快速完成基本的操作。
客户端可
以有各种形式，如PC，移动端，Web应用等。
二、服务器端：服务器端是三层架构的核心，它充当着客户端和数据
库服务器之间数据传输的桥梁或中介。
它收到客户端的请求，然后向数据
库服务器发出信息查询请求，从而获得需要的数据。
它把客户端发来的请
求和服务端自身的其他功能结合起来，完成客户端的数据查询和处理功能，进而把处理好的数据回传给客户端，实现数据的快速查找和处理。
三、数据库服务器：数据库服务器是三层架构的最后一层，它是全部
信息源的中心，它负责存储、管理和维护系统各种信息，如文件、数据等。
从性能方面来看，这一层是最重要的，因为它负责处理最多的数据，而且
这些数据经过其他层处理后，最后都要以其中一种形式存储在数据库服务
器上。
了解云服务器架构及其优势
了解云服务器架构及其优势云服务器架构是一种基于云计算技术的新型网络架构，它采用虚拟化技术，将多个服务器资源组合在一起，并通过网络进行连接和管理。
云服务器架构具有许多优势，包括高可靠性、高可扩展性、灵活性、成本效益等。
本文将深入探讨云服务器架构及其优势。
一、云服务器架构概述1.1 云服务器的定义和作用云服务器是一种基于云计算技术的虚拟服务器，它能够在云端进行部署和管理，提供各种计算资源和服务。
云服务器通过虚拟化技术将物理服务器划分为多个虚拟服务器，利用资源池化的方式实现对资源的共享和高效利用。
1.2 云服务器架构的组成云服务器架构主要包括前端服务器、后端服务器和存储系统。
前端服务器负责接收用户请求并进行负载均衡，后端服务器负责处理用户请求并提供相应的计算资源和服务，存储系统用于存储用户的数据。
二、云服务器架构的优势2.1 高可靠性云服务器采用分布式架构，将计算资源分散在多个物理服务器上，即使某台服务器发生故障，其他服务器仍可继续工作，提供可靠的服务。
同时，云服务器还具备数据备份和容灾功能，能够确保数据的安全性和可用性。
2.2 高可扩展性云服务器采用横向扩展的方式，可以动态地增加或减少计算资源，以满足需求的变化。
用户可以根据实际需求进行弹性扩展，无需预留额外的资源。
这种可扩展性使得云服务器能够快速适应不同规模和负载的应用场景。
2.3 灵活性云服务器提供灵活的云计算服务，用户可以根据自身需求选择不同的计算资源和服务，按需分配和管理。
用户可以根据实际情况进行资源的调整和配置，提高了资源的利用率和灵活性。
2.4 成本效益云服务器采用按需付费的模式，用户只需按实际使用的资源量付费，无需投资于基础设施和硬件设备。
这种弹性的付费方式能够有效降低成本，并提供灵活的资金预算，使企业更加专注于核心业务的发展。
2.5 其他优势除了以上几个方面的优势外，云服务器还具有易于管理、快速部署和升级、环境友好等特点。
云服务器能够提供统一的管理接口和自动化的管理工具，简化了运维管理的工作。
服务器概念、组成和架构详解
服务器概念、组成和架构详解目录前言：1、服务器是什么？2、服务器的构成？3、服务器的分类？4、X86/ARM之争？一、服务器是什么？二、服务器的构成？2.1 服务器的逻辑架构2.2 服务器的硬件2.3 服务器的固件和OS三、服务器的分类？3.1 按产品形态3.2 按指令集架构3.3 按处理器数量3.4 按应用类型四、 X86/ARM之争？4.1 X86服务器：市占率高4.2 ARM服务器：潜力很大前言：服务器是构建云计算的最核心基础设备，在“新基建”加快推进、公有云持续放量的背景下，服务器行业正迎来景气拐点。
本文围绕4个核心问题，由浅入深对服务器进行深入剖析：1、服务器是什么？2、服务器的构成？3、服务器的分类？4、X86/ARM之争？服务器的英文名称为“ Server”，是指在网络上提供各种服务的高性能计算机。
作为网络的节点，存储、处理网络上80％的数据、信息，因此也被称为网络的灵魂。
服务器和普通计算机的功能是类似的。
只是相对于普通计算机，服务器在稳定性、安全性、性能等方面都要求更高，因此CPU、芯片组、内存、磁盘系统、网络等硬件和普通计算机有所不同。
具体来说，服务器与普通计算机的主要区别包括：1）通信方式为一对多：PC、平板、手机等固定或移动的网络终端，上网、获取资讯、与外界沟通、娱乐等，必然要经过服务器，服务器通过“一对多”来组织和领导这些设备。
2）资源通过网络共享：服务器通过侦听网络上其它终端（Client）提交的服务请求，在网络操作系统的控制下，将与其相连的硬盘、打印机、Modem及各种专用通讯设备提供给网络上的客户站点共享，也能为网络用户提供集中计算、信息发表及数据管理等服务。
3）硬件性能更加强大：服务器的高性能主要体现在高速度的运算能力、长时间的可靠运行、强大的外部数据吞吐能力等方面。
服务器厂商会根据不同的应用场景，对服务器进行差异化设计，目前主要的应用场景包括文件交互、数据存储和查询、应用程序应答与运行等。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
转自知乎类型1：卡牌、跑酷等弱交互服务端卡牌跑酷类因为交互弱，玩家和玩家之间不需要实时面对面PK，打一下对方的离线数据，计算下排行榜，买卖下道具即可，所以实现往往使用简单的 HTTP服务器：<img src="https:///b82310466e1546e288b02b8664afd843_b.jpg" data-rawwidth="438" data-rawheight="186" class="origin_image zh-lightbox-thumb" width="438" data-original="https:///b82310466e1546e288b02b8664afd843_r.jpg">登录时可以使用非对称加密（RSA, DH），服务器根据客户端uid，当前时间戳还有服务端私钥，计算哈希得到的加密 key 并发送给客户端。
之后双方都用 HTTP通信，并用那个key进行RC4加密。
客户端收到key和时间戳后保存在内存，用于之后通信，服务端不需要保存 key，因为每次都可以根据客户端传上来的 uid 和时间戳以及服务端自己的私钥计算得到。
用模仿 TLS的行为，来保证多次HTTP请求间的客户端身份，并通过时间戳保证同一人两次登录密钥不同。
登录时可以使用非对称加密（RSA, DH），服务器根据客户端uid，当前时间戳还有服务端私钥，计算哈希得到的加密 key 并发送给客户端。
之后双方都用 HTTP通信，并用那个key进行RC4加密。
客户端收到key和时间戳后保存在内存，用于之后通信，服务端不需要保存 key，因为每次都可以根据客户端传上来的 uid 和时间戳以及服务端自己的私钥计算得到。
用模仿 TLS的行为，来保证多次 HTTP请求间的客户端身份，并通过时间戳保证同一人两次登录密钥不同。
每局开始时，访问一下，请求一下关卡数据，玩完了又提交一下，验算一下是否合法，获得什么奖励，数据库用单台 MySQL或者 MongoDB即可，后端的 Redis做缓存（可选）。
如果要实现通知，那么让客户端定时15秒轮询一下服务器，如果有消息就取下来，如果没消息可以逐步放长轮询时间，比如30秒；如果有消息，就缩短轮询时间到10秒，5秒，即便两人聊天，延迟也能自适应。
此类服务器用来实现一款三国类策略或者卡牌及酷跑的游戏已经绰绰有余，这类游戏因为逻辑简单，玩家之间交互不强，使用 HTTP来开发的话，开发速度快，调试只需要一个浏览器就可以把逻辑调试清楚了。
类型2：第一代游戏服务器 19781978年，英国著名的财经学校University of Essex的学生 Roy Trubshaw编写了世界上第一个MUD程序《MUD1》，在University of Essex于1980年接入 ARPANET之后加入了不少外部的玩家，甚至包括国外的玩家。
《MUD1》程序的源代码在 ARPANET共享之后出现了众多的改编版本，至此MUD才在全世界广泛流行起来。
不断完善的 MUD1的基础上产生了开源的MudOS（1991），成为众多网游的鼻祖：<img src="https:///b647b152f0352f239d9840c29b29e2c9_b.jpg" data-rawwidth="368" data-rawheight="225" class="content_image" width="368">MUDOS采用 C语言开发，因为玩家和玩家之间有比较强的交互（聊天，交易，PK），MUDOS使用单线程无阻塞套接字来服务所有玩家，所有玩家的请求都发到同一个线程去处理，主线程每隔1秒钟更新一次所有对象（网络收发，更新对象状态机，处理超时，刷新地图，刷新NPC）。
MUDOS采用 C语言开发，因为玩家和玩家之间有比较强的交互（聊天，交易，PK），MUDOS使用单线程无阻塞套接字来服务所有玩家，所有玩家的请求都发到同一个线程去处理，主线程每隔1秒钟更新一次所有对象（网络收发，更新对象状态机，处理超时，刷新地图，刷新NPC）。
游戏世界采用房间的形式组织起来，每个房间有东南西北四个方向可以移动到下一个房间，由于欧美最早的网游都是地牢迷宫形式的，因此场景的基本单位被成为“房间”。
MUDOS使用一门称为LPC的脚本语言来描述整个世界（包括房间拓扑，配置，NPC，以及各种剧情）。
游戏里面的高级玩家（巫师），可以不断的通过修改脚本来为游戏添加房间以及增加剧情。
早年MUD1上线时只有17个房间，Roy Trubshaw毕业以后交给他的师弟 Richard Battle，在Richard Battle手上，不断的添加各种玩法到一百多个房间，终于让 MUD发扬光大。
用户使用 Telnet之类的客户端用 Tcp协议连接到 MUDOS上，使用纯文字进行游戏，每条指令用回车进行分割。
比如 1995年国内第一款 MUD游戏《侠客行》，你敲入："go east"，游戏就会提示你：“后花园 - 这里是归云庄的后花园，种满了花草，几个庄丁正在浇花。
此地乃是含羞草生长之地。
这里唯一的出口是 north。
这里有：花待阿牧（A mu），还有二位庄丁（Zhuang Ding）”，然后你继续用文字操作，查看阿牧的信息：“look a mu”，系统提示：“花待阿牧（A mu）他是陆乘风的弟子，受命在此看管含羞草。
他看起来三十多岁，生得眉清目秀，端正大方，一表人才。
他的武艺看上去【不是很高】，出手似乎【极轻】”。
然后你可以选择击败他获得含羞草，但是你吃了含羞草却又可能会中毒死亡。
在早期网上资源贫乏的时候，这样的游戏有很强的代入感。
用户数据保存在文件中，每个用户登录时，从文本文件里把用户的数据全部加载进来，操作全部在内存里面进行，无需马上刷回磁盘。
用户退出了，或者每隔5分钟检查到数据改动了，都会保存会磁盘。
这样的系统在当时每台服务器承载个4000人同时游戏，不是特别大的问题。
从1991年的 MUDOS发布后，全球各地都在为他改进，扩充，退出新版本，随着 Windows图形机能的增强。
1997游戏《UO》在 MUDOS的基础上为角色增加的x,y坐标，为每个房间增加了地图，并且为每个角色增加了动画，形成了第一代的图形网络游戏。
因为游戏内容基本可以通过 LPC脚本进行定制，所以MUDOS也成为名副其实的第一款服务端引擎，引擎一次性开发出来，然后制作不同游戏内容。
后续国内的《万王之王》等游戏，很多都是跟《UO》一样，直接在 MUDOS上进行二次开发，加入房间的地图还有角色的坐标等要素，该架构一直为国内的第一代 MMORPG提供了稳固的支持，直到 2003年，还有游戏基于 MUDOS开发。
虽然后面图形化增加了很多东西，但是这些MMORPG后端的本质还是 MUDOS。
随着游戏内容的越来越复杂，架构变得越来越吃不消了，各种负载问题慢慢浮上水面，于是有了我们的第二代游戏服务器。
类型3：第二代游戏服务器 20032000年后，网游已经脱离最初的文字MUD，进入全面图形化年代。
最先承受不住的其实是很多小文件，用户上下线，频繁的读取写入用户数据，导致负载越来越大。
随着在线人数的增加和游戏数据的增加，服务器变得不抗重负。
同时早期 EXT磁盘分区比较脆弱，稍微停电，容易发生大面积数据丢失。
因此第一步就是拆分文件存储到数据库去。
<img src="https:///984d43af31dcbb20bfbdf6c22cce4947_b.jpg" data-rawwidth="439" data-rawheight="159" class="origin_image zh-lightbox-thumb" width="439" data-original="https:///984d43af31dcbb20bfbdf6c22cce4947_r.jpg">此时游戏服务端已经脱离陈旧的 MUDOS体系，各个公司在参考 MUDOS结构的情况下，开始自己用 C在重新开发自己的游戏服务端。
并且脚本也抛弃了 LPC，采用扩展性更好的 Python 或者 Lua来代替。
由于主逻辑使用单线程模型，随着游戏内容的增加，传统单服务器的结构进一步成为瓶颈。
于是有人开始拆分游戏世界，变为下面的模型：<img src="https:///68a2d231c4e2c1b70753135350a2fb37_b.jpg" data-rawwidth="404" data-rawheight="163" class="content_image" width="404">游戏服务器压力拆分后得意缓解，但是两台游戏服务器同时访问数据库，大量重复访问，大量数据交换，使得数据库成为下一个瓶颈。
于是形成了数据库前端代理（DB Proxy），游戏服务器不直接访问数据库而是访问代理，再有代理访问数据库，同时提供内存级别的cache。
早年 MySQL4之前没有提供存储过程，这个前端代理一般和 MySQL跑在同一台上，它转化游戏服务器发过来的高级数据操作指令，拆分成具体的数据库操作，一定程度上代替了存储过程：游戏服务器压力拆分后得意缓解，但是两台游戏服务器同时访问数据库，大量重复访问，大量数据交换，使得数据库成为下一个瓶颈。
于是形成了数据库前端代理（DB Proxy），游戏服务器不直接访问数据库而是访问代理，再有代理访问数据库，同时提供内存级别的cache。
早年 MySQL4之前没有提供存储过程，这个前端代理一般和 MySQL跑在同一台上，它转化游戏服务器发过来的高级数据操作指令，拆分成具体的数据库操作，一定程度上代替了存储过程：<img src="https:///cf87922d9cff5e0a6490abc5d396c4fe_b.jpg" data-rawwidth="466" data-rawheight="162" class="origin_image zh-lightbox-thumb" width="466" data-original="https:///cf87922d9cff5e0a6490abc5d396c4fe_r.jpg">但是这样的结构并没有持续太长时间，因为玩家切换场景经常要切换连接，中间的状态容易错乱。