WebGame服务端架构设计
目录
WebGame服务端架构设计 (1)
1需求分析 (2)
1.1背景 (2)
1.2执行环境 (2)
1.3兼容性目标 (3)
1.4网络需求 (3)
1.5系统架构设计原则 (3)
1.6模块设计原则 (3)
1.7开源组件选择 (3)
1.8国际化原则 (3)
1.9性能目标 (4)
1.10已有的成熟方案 (4)
1.11方案简介 (4)
1.11.1服务器当机时玩家数据不回档的保证方案 (4)
1.11.2服务器不停机更新方案 (4)
1.11.3脚本引擎 (4)
1.11.4配置转表工具 (5)
1.11.5前后台协议同步方案 (5)
1.11.6内存管理方案 (5)
1.11.7网络通讯方案 (5)
1.11.8视野同步方案 (5)
1.11.9任务功能实现方案 (5)
1.11.10副本功能实现方案 (6)
2整体架构 (6)
1需求分析
1.1背景
使用C/ C++技术开发的RPG游戏，系统的方向参照《神仙道》
1.2执行环境
业务层模块：对CPU要求最高，其次是内存，对磁盘容量要求不高
存储层模块：对磁盘容量要求最高，其次是内存和CPU
1、操作系统：64位LINUX
2、mysql 5.0以上。
1.4网络需求
根据游戏设计而定，如果是分区分服的设计，普通的网络机房即可。
如果是全区全服的设计，需要三通的机房网络支持。
1.5系统架构设计原则
系统按照功能职责和安全性划分子系统和模块，参考成熟架构
异常处理
过载保护
各个子系统/模块可独立扩容
1.6模块设计原则
模块内各个层次低耦合高内聚
严格控制内存使用
严格控制所有对象资源的生存期，及时回收
逻辑验证在服务器端执行，避免客户端外挂对游戏公平性造成影响对关键算法做性能优化
1.7开源组件选择
Log4c：日志
protobuf：协议
libevent：高并发监听与连接
1.8国际化原则
所有字符串使用UTF8编码
字符串不在程序中硬编码，放入指定的资源文件以方便国际化
根据游戏设计和硬件环境而定
1.10已有的成熟方案
服务器当机时玩家数据不回档的保证方案
服务器不停机更新方案
脚本引擎
配置转表工具
前后台协议同步方案
内存管理方案
网络通讯方案
视野同步方案
任务功能实现方案
副本功能实现方案
1.11方案简介
1.11.1服务器当机时玩家数据不回档的保证方案
通过将游戏中的数据分类，保证和玩家状态相关的数据保存在共享内存或内存映射文件中。当服务器出现当机等异常状况时，可以通过重新读取共享内存或内存映射文件将玩家数据恢复，确保玩家数据不回档。
1.11.2服务器不停机更新方案
通过将游戏中的数据分类，游戏状态相关的数据及状态无关数据分离，配置及脚本相关数据分离。确保状态相关数据保存在共享内存中。当服务器需要更新时，可以选择性的跟新指定模块。同时，由于状态相关数据在共享内存中，通过特定技术的恢复，达到不停机更新的目标。
1.11.3脚本引擎
多年的游戏开发，我们积累了大量脚本开发和使用的经验。我们有成熟的脚本方案，可以保证极高效率的同时，满足各类任务，活动，副本，技能，人工智能等需要。
1.11.4配置转表工具
让策划能够使用各种工具和技能配置excel表格来控制游戏中的各类数据。而程序只需要通过转表工具将excel的数据转化为前后台能够各自高效使用的二进制数据。即满足灵活性的需要，又满足高效性的需要。
1.11.5前后台协议同步方案
前后台协议的同步使用基于开源的protobuf组件，经过仔细的约定和扩展而来的方案。
1.11.6内存管理方案
基于内存池的内存管理方案。为游戏各个模块提供各类支持。
1.11.7网络通讯方案
基于开源组件libevent实现的网络通讯方案。保证在大量客户端连接的情况下，服务器照样能够高效运转。
1.11.8视野同步方案
视野同步是很多网络游戏的性能瓶颈所在。我们经过多次的优化和总结，提取出许许多多的经验，并完成成熟的视野同步方案。确保高效准确的视野同步感受。
1.11.9任务功能实现方案
支持基于表格填写的任务实现方案，能够快速的提供大量的游戏任务，丰富游戏内容。同时，还支持基于脚本的任务实现方案，能够支持各类灵活多变的个性化任务和对话。
1.11.10副本功能实现方案
提供各类副本的实现方案。包括基于地图编辑器和配置表格的快速副本提供方案和基于脚本的个性化副本实现方案。可以大量快速的布置各类丰富多彩，玩法，特色十足的副本。
2整体架构
架构是为了游戏内容服务。不同特色的游戏选用不同类型的架构。我们对当前市场上各类主流游戏架构及其优劣有深入的了解和分析，可以根据我们游戏的特点，制定出最合适的游戏架构。充分满足稳定，高效，易维护，易扩展的需求。
3合服支持
1：合服需要保证玩家ID的唯一，我们在建立角色之初就通过特定算法，保证每个玩家角色的ID在所有服务器中唯一存在，避免了合服之后ID重复导致的各类问题出现。
2：合服玩家的名字唯一性问题。可以通过建立统一的名字服务器来保证所有服务器或者某些服务器中玩家角色名字唯一来避免合服之后玩家角色名字重复的问题。也可以简单的在合服之后给重名的玩家名字加上后缀来处理。
3: 我们会提供大量的日志和数据统计来支持合服策略的制定。通过分析日志和DB中玩家的数据，我们能够提供给运营准确和充分的数据来判定合服的策略。确保合服之后的玩家能够得到更好的游戏体验。
微服务框架的设计与实现① 张晶1, 黄小锋2, 李春阳3 1(北京中电普华信息技术有限公司, 北京100192) 2(中国电建集团国际工程有限公司, 北京100048) 3(国网信息通信产业集团有限公司, 北京100031) 摘 要: 相对于传统单块架构, 微服务框架具有技术选型灵活, 独立部署, 按需独立扩展等优点, 更适合当前互联网时代需求. 但微服务架构的使用引入了新的问题, 如服务注册发现、服务容错等. 对微服务框架引入的问题进行分析, 并给出了微服务框架的一种实现方案, 在框架层面解决服务注册发现、服务容错等共性问题, 使业务系统开发人员专注于业务逻辑实现, 简化系统开发的难度, 提高开发效率. 关键词: 微服务框架; 服务注册; 服务发现; 服务容错 Design and Implementation of Microservice Architecture ZHANG Jing1, HUANG Xiao-Feng2, LI Chun-Yang3 1(Beijing China Power Information Technology Co. Ltd., Beijing 100192, China) 2(PowerChina International Group Limited, Beijing 100048, China) 3(State Grid Information & Telecommunication Industry Group Co. Ltd., Beijing 100031, China) Abstract: Compared with traditional single block architecture, microservice architecture has many advantages, such as flexible technology selection, independent deployment, and independent scalability more suitability for the current needs of the internet age, etc. But microservice architecture also introduces new problems such as service registration, service discovery, service fault tolerance. On the basis of the analysis for problems mentioned above, this paper proposes one implementation of microservice framework, which can solve service registration, service discovery, service fault tolerance and other common problems. Based on this, developers only need to focus on the development of business functions, so that it can simplify the difficulty of system development and improve development effectiveness. Key words: microservice architecture; service registration; service discover; fault tolerance 传统信息化系统的典型架构是单块架构(Monolithic Architecture), 即将应用程序的所有功能都打包成一个应用, 每个应用是最小的交付和部署单元, 应用部署后运行在同一进程中. 单块架构应用具有IDE友好、易于测试和部署等优势, 但是, 随着互联网的迅速发展, 单块架构临着越来越多的挑战, 主要表现在维护成本高、持续交付周期长、可伸缩性差等方面[1]. 微服务架构(Microservices)的出现以及在国内外的成功应用, 成为系统架构的一种新选择. 很多大型宝等都已经从传统单块架构迁移到微服务架构[2]. 微服务架构提倡将单块架构的应用划分成一组小的服务, 互联网公司如Twitter、Netflix、Amazon 、eBay、淘服务之间互相协调、互相配合, 为用户提供最终价值. 1 微服务架构 微服务架构是一种架构模式, 采用一组服务的方式来构建一个应用, 服务独立部署在不同的进程中, 不同服务通过一些轻量级交互机制来通信, 例如RPC、HTTP等, 服务可独立扩展伸缩, 每个服务定义了明确的边界, 不同的服务甚至可以采用不同的编程语言来实现, 由独立的团队来维护[3]. 相对于传统的单体应用架构, 微服务架构具有单个服务易于开发、理解和维护; 复杂度可控; 技术选 ①收稿时间:2016-09-18;收到修改稿时间:2016-11-03 [doi: 10.15888/https://www.doczj.com/doc/3f18664149.html,ki.csa.005796]
一．服务器概述 服务器是指在局域网中，一种运行管理软件以控制对网络或网络资源（磁盘驱动器、打印机等）进行访问的计算机，并能够为在网络上的计算机提供资源使其犹如工作站那样地进行操作。从广义上讲，服务器是指网络中能对其它机器提供某些服务的计算机系统（如果一个PC对外提供ftp服务，也可以叫服务器）。从狭义上讲，服务器是专指某些高性能计算机，能通过网络，对外提供服务。相对于普通PC来说，稳定性、安全性、性能等方面都要求更高，因此在CPU、芯片组、内存、磁盘系统、网络等硬件和普通PC 有所不同。 服务器作为网络的节点，存储、处理网络上80％的数据、信息，因此也被称为网络的灵魂。做一个形象的比喻：服务器就像是邮局的交换机，而微机、笔记本、PDA、手机等固定或移动的网络终端，就如散落在家庭、各种办公场所、公共场所等处的电话机。日常的生活、工作中的电话交流、沟通，必须经过交换机，才能到达目标电话；同样如此，网络终端设备如家庭、企业中的微机上网，获取资讯，与外界沟通、娱乐等，也必须经过服务器，因此也可以说是服务器在“组织”和“领导”这些设备。 服务器的构成与微机基本相似，有处理器、硬盘、内存、系统总线等，它们是针对具体的网络应用特别制定的，因而服务器与微机在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面存在差异很大。 服务器的功能： 提供服务 - IP 地址 将一种资源共享给多个请求者 - 数据库 将一种设备共享给多个请求者 - 打印机 为其他系统开放网关 - Web 提供处理能力 - 数字 存储内容 - 数据
二．服务器的主要分类 服务器往往被用于运行企业或个人的关键业务，所以对其性能与可靠性方面的要求会远远高于桌面电脑。一般来说服务器的CPU、内存、网络、存储都会使用企业级部件。譬如相比桌面电脑常用的Intel 酷睿系列CPU，服务器的CPU往往会采用性能更稳定强大的Intel至强（Xeon）系列或者IBM的Power系列。而内存也会采用带有诸如ECC效验等自恢复功能的高速企业级内存。为了满足特定的业务需求，不同种类的服务器又会在网络、存储、内存、显卡等方面进行强化。如电信行业采用的服务器往往会配备高速网卡以配合高速交换机；数据仓库应用中的服务器往往会配备高速光纤卡以便通过光纤接口（Fabric Channel）与存储网络配合。 按照体系架构来区分，服务器主要分为两类： 非x86服务器：包括大型机、小型机和UNIX服务器，它们是使用RISC（精简指令集）或EPIC处理器，并且主要采用UNIX和其它专用操作系统的服务器，精简指令集处理器主要有IBM公司的POWER和PowerPC处理器，SUN与富士通公司合作研发的SPARC处理器、EPIC处理器主要是HP与Intel合作研发的安腾处理器等。这种服务器价格昂贵，体系封闭，但是稳定性好，性能强，主要用在金融、电信等大型企业的核心系统中。 x86服务器：又称CISC（复杂指令集）架构服务器，即通常所讲的PC服务器，它是基于PC机体系结构，使用Intel或其它兼容x86指令集的处理器芯片和Windows操作系统的服务器，如IBM的System x 系列服务器、HP的Proliant 系列服务器等。价格便宜、兼容性好、稳定性差、不安全，主要用在中小企业和非关键业务中。 CISC型CPU CISC是英文“Complex Instruction Set Computer”的缩写，中文意思是“复杂指令集”，它是指英特尔生产的x86(intel CPU的一种命名规范)系列CPU及其兼容CPU(其他厂商如AMD,VIA等生产的CPU)，它基于PC机(个人电脑)体系结构。这种CPU一般都是 32位的结构，可称为IA-32 CPU。(IA: Intel Architecture，Intel架构)。CISC型CPU目前主要有intel的服务器CPU和AMD的服务器CPU两类。 RISC型CPU RISC 是英文“Reduced Instruction Set Computing ” 的缩写，中文意思是“精简指令集”。它是在CISC(Complex Instruction Set Computer)指令系统基础上发展起来的，相对于CISC型CPU ，RISC型CPU不仅精简了指令系统，还采用了一种叫做“超标量和超流水线结构”，架构在同等频率下，采用RISC架构的CPU比CISC架构的CPU性能高很多，这是由CPU的技术特征决定的。RISC型CPU与Intel和AMD的CPU在软件和硬件上都不兼容。
2月27日在上一篇关于ARM和x86在数据中心应用的较量，已经不是一个新话题了。我们经常看到功耗、性能数字，以及应用软件和生态系统丰富程度的讨论。《华为UDS对象存储：ARM自组织硬盘满足CERN功耗》一文里面，笔者曾经提到“功耗和成本正是UDS使用ARM而不是Intel Atom等处理器的原因，据了解华为此前在这一系列的产品中使用过Atom。” 现在我想以大型用户的实际研发和部署进度为切入点，继续谈谈ARM和x86之间各自的优势，以及可能存在的不足。 本文的两个主要论点是：ARM在用于数据中心的SoC方面，目前相对于x86的功能和集成度有一定优势；另外百度与Facebook主导的Open Compute Project（开放计算项目），其存储（服务器）设计的密度和灵活性也有些差别。那为什么标题中还说两家“异曲同工”呢？先来看看百度的情况。 百度ARM云存储支持纯x86/ARM，或两者混布 ChinaByte比特网：关于百度的ARM云存储节点，是否方便透露使用了来自哪家的处理器？系统来自哪个ODM？ 以我的了解，华为UDS对象存储（云存储）也使用了ARM，在存储节点上每颗ARM （应该是单核）对应一个硬盘，而管理（元数据）节点仍然是x86。 我看到百度也是每个ARM核心对应一个硬盘，因此想了解下整套系统的组成，是否也需要x86的管理节点搭配使用？ARM在这里是什么样的角色（承担着哪些处理工作）？ 百度：我们与ARM、Marvell 等业界领导者共同设计开发了这款ARM 云存储服务器，并拥有相关专利。完整的系统架构不方便透露。可以明确的是，我们的这套系统可以支持纯X86，或者纯ARM，或者两者混布。 点评：我想这个答复还算简单清楚，下面再看看实物照片：
医院网络架构设计与实现 [摘要]随着医院信息化进程的深入，医院信息平台的运行将越来越依赖基础网络的建设。网络成为医院各种关键数据的信息进行交互和传递的重要途径。多种网络架构拥有各自的优势与不足，下面就我对其的认识作出阐述和选择一种合适的网络基础架构。 [关键字] 内外网融合，内外网分离，结合 医院的网络基础架构发展至今，主要分为三种架构，分别是内外网融合的网络架构、内外网分离的网络架构、以及最近几年刚刚兴起的基于业务的无线网络平台架构，这是和医疗信息化的发展阶段分不开的。(内网外网的概念为逻辑上的划分，两种实际的物理架构中，逻辑上均包含内网和外网两部分。划分主要根据业务系统的对内对外服务属性，医疗核心业务相关度等特性来进行。) 首先先来简单认识一下内外网融合的网络架构、内外网分离的网络架构和无线网络平台架构和基于业务的无线网络平台架构以及他们的优缺点比较。 内外网融合的物理架构:就是医院的内网业务以及办公业务都在一张基础网络上运行，在这一网络架构之上，无论是数据的类型、重要程度，还是对网络的要求，以及数据流方向都不尽相同，使得网络数据复杂度提高而可控性下降。从介绍可知，所有业务都在一张基础网上，缺点明显可知，两网仅逻辑隔离，外网对设备的攻击可能引起
内外网络全面瘫痪。优点则是:可以保护投资，并且可以根据需要让某部分终端可以同时访问两个区域，而且内外网融合所需设备相对较少，在维护和购买设备方面都很大程度上减少了成本。 内外网分离的网络架构:就是将医院的内网和外网业务分别放在一张单独建立的网络上来运行，两网物理隔离，最大限度的保障内网业务及数据的安全。内网主要承载医疗核心业务，如HIS、PACS 等。外网作为行政办公、对外发布、互联网医学资料查询的主要平台，对于稳定性和保密的性的要求低于内网，并且接入终端及数据流特点也更为复杂。优点：内外网无共用设备和链路，两网之间互不影响。此种网络架构设计，能够最大程度保证内网安全。缺点：由于内外网完全物理隔离，两张网络单独建设，投资规模增大；灵活性稍弱，一台终端只属于一张网，不能同时对两网资源进行访问，也不能自由切换；需要管理两张网络，增加管理成本 无线网络与上述两种相比大大不同，它是采用无线传输媒介的计算机网络，结合了最新的计算机网络技术和无线通信技术。首先，无线局域网是有线局域网的延伸。使用无线技术来发送和接收数据，减少了用户的连线需求。由于采用无线信号通讯，在网络接入方面就更加灵活了，只要有信号就可以通过无线网卡完成网络接入的目的；同时网络管理者也不用再担心交换机或路由器端口数量不足而无法完成扩容工作了。但是无线网络初次建设成本较高，很多条件不是很好的医院都无法实现；部署时需要改动现有网络结构，对原网络进行调整，增加初次部署复杂度，随着无线网络带宽以及传输数据
DSRC通信系统架构设计与实现 【摘要】本文通过对DSRC系统的架构分析，设计了车车与车路信息交互平台的通信软件与MFC通信显示界面，在平台架构基础上进行了实车传输车身信号数据测试，试验结果表明，所设计的通信系统平台架构合理，并且能够满足包括车辆安全所需求的通信标准。 【关键词】DSRC；MFC；socket；车路通信 0 引言 21世纪将是公路交通智能化的世纪，人们将要采用的智能交通系统，是一种先进的一体化交通综合管理系统。ITS是智能交通系统（Intelligent Transportation System）的简称，是未来交通系统的发展方向，它是将先进的信息技术、数据通讯传输技术、电子传感技术、控制技术及计算机技术等有效地集成运用于整个地面交通管理系统而建立的一种在大范围内、全方位发挥作用的，实时、准确、高效的综合交通运输管理系统[1-2]。 DSRC 采用专为车间通信的WA VE规范以及根据IEEE802.11标准修改制定的IEEE 802. 11p 标准。目前许多文献针对DSRC所进行的研究主要集中在对通信协议或者交通系统某一项参数设置不同时所得出的通信系统实时性与延迟性的研究，但是并没有针对整个ITS系统的架构角度来考虑对DSRC通信系统的实现。 本文针对DSRC在ITS环境下的系统架构，提出了智能通信平台的整个设计，对于DSRC系统的通信软件架构的编写与实车试验，揭示了DSRC在ITS 道路环境下架构设计流程与实车通信效果。 1 DSRC通信平台系统架构设计与仿真 1.1 DSRC系统架构之间的关系 DSRC系统主要包括三个部分：车载单元（OBU）、路边单元（RSU）以及专用短程通信协议。通过车载OBU收发器与路侧RSU收发器，可实现车辆与道路之间的信息交互。DSRC协议是在OSI的基础上提出的三层协议结构，即物理层、数据链路层（LLC与MAC子层）、应用层，如图1所示。 图1 调制方式系统架构的关系 Fig.1 Relationship between the modulation and system architecture 1.2 智能交互系统平台通信socket编写（物理层与数据链路层）
游戏服务器系统设计 1.1 服务器架构分类 服务器组的架构一般分为两种：第一种是带网关服务器的服务器架构；第二种是不带网关服务器的服务器架构，这两种方案各有利弊。在给出服务器架构设计之前，先对这两种设计方案进行详细的探讨。所谓网关服务器，其实是Gate 服务器，比如LoginGate、GameGate 等。网关服务器的主要职责是将客户端和游戏服务器隔离，客户端程序直接与这些网关服务器通信，并不需要知道具体的游戏服务器内部架构，包括它们的IP、端口、网络通信模型(完成端口或Epoll)等。客户端只与网关服务器相连，通过网关服务器转发数据包间接地与游戏服务器交互。同样地，游戏服务器也不直接和客户端通信，发给客户端的协议都通过网关服务器进行转发。 1.2 服务器架构设计 根据网络游戏的规模和设计的不同，每组服务器中服务器种类和数量是不尽相同的。本系统设计出的带网关服务器的服务器组架构如图1 所示。 图1 带网关服务器的服务器架构设计方案 该设计有以下几点好处： （1）作为网络通信的中转站，负责维护将内网和外网隔离开，使外部无法直接访问内部服
务器，保障内网服务器的安全，一定程度上较少外挂的攻击。 （2）网关服务器负责解析数据包、加解密、超时处理和一定逻辑处理，这样可以提前过滤掉错误包和非法数据包。 （3）客户端程序只需建立与网关服务器的连接即可进入游戏，无需与其它游戏服务器同时建立多条连接，节省了客户端和服务器程序的网络资源开销。 （4）在玩家跳服务器时，不需要断开与网关服务器的连接，玩家数据在不同游戏服务器间的切换是内网切换，切换工作瞬间完成，玩家几乎察觉不到，这保证了游戏的流畅性 和良好的用户体验。 虽然网关服务器带来上述好处，但是，还需要注意以下可能导致负面效果的两个情况：如何避免网关服务器成为高负载情况下的通讯瓶颈问题以及由于网关的单节点故障导致整组服务器无法对外提供服务的问题。上述两个问题可以采用“多网关”技术加以解决。顾名思义，“多网关”就是同时存在多个网关服务器，比如一组服务器可以配置三台GameGate。当负载较大时，可以通过增加网关服务器来增加网关的总体通讯流量，当一台网关服务器宕机时，它只会影响连接到本服务器的客户端，其它客户端不会受到任何影响。从图1 的服务器架构图可以看出，一组服务器包括LoginGate、LoginServer、GameGate、GameServer、DBServer和MServer 等多种服务器。LoginGate 和GameGate 就是网关服务器，一般一组服务器会配置3 台GameGate，因为稳定性对于网络游戏运营来说是至关重要的，而服务器宕机等突发事件是游戏运营中所面临的潜在风险，配置多台服务器可以有效地降低单个服务器宕机带来的风险。另外，配置多台网关服务器也是进行负载均衡的有效手段之一。其中，各种服务器的主要功能和彼此之间的数据交互情况如下。 （1）LoginGate LoginGate 主要负责在玩家登录时维护客户端与LoginServer 之间的网络连接与通讯，对LoginServer 和客户端的通信数据进行加解密、校验。 （2）LoginServer LoginServer 主要功能是验证玩家的账号是否合法，只有通过验证的账号才能登录游戏。从架构图可以看出，DBServer 和GameServer 会连接LoginServer。玩家登录基本流程是，客户端发送账号和密码到LoginServer 验证，如果验证通过，LoginServer 会给玩家分配一个SessionKey，LoginServer 会把这个SessionKey 发送给客户端、DBServer和GameServer，在后续的选择角色以后进入游戏过程中，DBServer 和GameServer 将验证SessionKey 合法性，如果和客户端携带的SessionKey 不一致，将无法成功获取到角色或者进入游戏。 （3）GameGate GameGate(GG)主要负责在用户游戏过程中负责维持GS与客户端之间的网络连接和通讯，对GS 和客户端的通信数据进行加解密和校验，对客户端发往GS 的用户数据进行解析，过滤错误包，对客户端发来的一些协议作简单的逻辑处理，其中包括游戏逻辑中的一些超时判断。在用户选择角色过程中负责维持DBServer 与客户端之间的网络连接和通讯，对DBServer 和客户端的通信数据进行加解密和校验，对客户端发往DBServer 的用户数据做简单的分析。维持客户端与MServer 之间的网络连接与通讯、加解密、数据转发和简单的逻辑处理等。（4）GameServer GameServer(GS)主要负责游戏逻辑处理。在软件架构层面，本系统将游戏的众多系统设计成GS 的子系统或模块，它们共同处理整个游戏世界逻辑的运算。游戏逻辑包括角色进入与退出游戏、跳GS 以及各种逻辑动作(比如行走、说话和攻击等)。由于整个游戏世界有许多游戏场景，在该架构中一组服务器有3 台GS 共同负责游戏逻辑处理，每台游戏服务器负 责一部分地图的处理，这样不仅降低了单台服务器的负载，而且降低了GS 宕机带来的风险。玩家角色信息里会保持玩家上次退出游戏时的地图编号和所在GS 编号，这样玩家再次登录
软件架构设计说明书 The final edition was revised on December 14th, 2020.
目录
1.引言 [对于由多个进程构成的复杂系统，系统设计阶段可以分为：架构设计（构架设计）、组件高层设计、组件详细设计。对于由单个进程构成的简单系统，系统设计阶段可以分为：系统概要设计、系统详细设计。本文档适用于由多个进程构成的复杂系统的构架设计。] [架构设计说明书是软件产品设计中最高层次的文档，它描述了系统最高层次上的逻辑结构、物理结构以及各种指南，相关组件（粒度最粗的子系统）的内部设计由组件高层设计提供。] [系统：指待开发产品的软件与硬件整体，其软件部分由各个子系统嵌套组成，子系统之间具有明确的接口； 组件：指粒度最粗的子系统； 模块：指组成组件的各层子系统，模块由下一层模块或函数组成；] [此文档的目的是： 1）描述产品的逻辑结构，定义系统各组件（子系统）之间的接口以及每个组件（子系统）应该实现的功能； 2）定义系统的各个进程以及进程之间的通信方式； 3）描述系统部署，说明用来部署并运行该系统的一种或多种物理网络（硬件）配置。对于每种配置，应该指出执行该系统的物理节点（计算机、网络设备）配置情况、节点之间的连 接方式、采用何种通信协议、网络带宽。另外还要包括各进程到物理节点的映射； 4）系统的整体性能、安全性、可用性、可扩展性、异常与错误处理等非功能特性设计； 5）定义该产品的各个设计人员应该遵循的设计原则以及设计指南，各个编程人员应该遵循的编码规范。 ] [建议架构设计工程师与组件设计工程师共同完成此文档。] [架构设计说明书的引言应提供整个文档的概述。它应包括此文档的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。]
各公司服务器架构 经典云计算架构包括IaaS、PaaS、SaaS三层服务。云计算平台架构细分为硬件层、虚拟层、软件平台层、能力层、应用平台以及软件服务层。 云平台的云计算架构虽然分了多个层次，但是每个层次之间都是松耦合关系，在一个具体案例中也不是每个层次的服务都使用到，而且根据具体的应用环境搭建相应的云计算架构。 （1）硬件层和虚拟层对应IaaS层（Infrastructure as a Service） 主要提供基本架构的服务，比如提供基本的计算服务、存储服务、网络服务。计算机服务是提供用户一个计算环境，用户可以在上面开发和运行自己的应用，此环境一般是包含约定CPU、内存和基本存储空间的虚拟机环境，也可以是一台物理服务器，但是对用户是透明的。 存储资源是提供用户一个存储空间，根据用户需求不同可以提供块存储服务，文件存储服务，记录存储服务，对象存储服务。 网络服务是提供用户一个网络方案，可以让用户维护自己的计算环境和存储空间，并可以利用计算环境和存储空间对外提供服务。 （2）软件平台、能力层、应用平台组成PaaS层（Platform as a Service） 软件平台层主要提供公共的平台技术，比如统一支撑操作系统，包括使用到的运行平台，对应用屏蔽了运行环境差异，应用只要关心逻辑即可；也包括统一计费、统一配置、统一报表等后台支撑，各种应用利用相应的框架进行开发后，即可做到对外统一界面、统一运维管理、统一报表展示等；也包括分布式缓存、分布式文件系统、分布式数据库等通用技术，上层应用可以根据自己的需要使用相应的API就可以使用到这些通用技术。 能力层主要提供基本业务能力，比如传统电信服务中的短信、彩信、wappush等，互联网服务中的图
广州润衡软件连锁有限公司软件架构设计文档 项目名称 软件架构设计文档 版本
修订历史记录
目录 1.简介5 1.1目的5 1.2范围5 1.3定义、首字母缩写词和缩略语5 1.4参考资料5 1.5概述5 2.整体说明5 2.1简介5 2.2构架表示方式5 2.3构架目标和约束5 3.用例视图6 3.1核心用例6 3.2用例实现6 4.逻辑视图6 4.1逻辑视图6 4.2分层6 4.2.1应用层6 4.2.2业务层7 4.2.3中间层7 4.2.4系统层7 4.3架构模式7 4.4设计机制7 4.5公用元素及服务7 5.进程视图7 6.部署视图7 7.实施视图8 7.1概述8 7.2层8 7.3部署8 8.数据视图8 9.大小和性能8
软件架构设计文档 10.质量8 11.其它说明8 12.附录A 指南8 13.附录B 规范9 14.附录C 模版9 15.附录D 示例9
软件架构设计文档 1.简介 软件构架文档的简介应提供整个软件构架文档的概述。它应包括此软件构架文档的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述 1.1目的 本文档将从构架方面对系统进行综合概述，其中会使用多种不同的构架视图来描述系统的各个方面。它用于记录并表述已对系统的构架方面作出的重要决策 本节确定此软件构架文档在整个项目文档中的作用或目的，并对此文档的结构进行简要说明。应确定此文档的特定读者，并指出他们应该如何使用此文档 1.2范围 简要说明此软件构架文档适用的范围和影响的范围 1.3定义、首字母缩写词和缩略语 本小节应提供正确理解此软件构架文档所需的全部术语的定义、首字母缩写词和缩略语。这些信息可以通过引用项目词汇表来提供 1.4参考资料 本小节应完整地列出此软件构架文档中其他部分所引用的所有文档。每个文档应标有标题、报告号（如果适用）、日期和出版单位。列出可从中获取这些参考资料的来源。这些信息可以通过引用附录或其他文档来提供 1.5概述 本小节应说明此软件构架文档中其他部分所包含的内容，并解释此软件构架文档的组织方式 2.整体说明 2.1简介 在此简单介绍软件架构的整体情况，包括用例视图、逻辑视图、进程视图、实施视图和部署视图的简单介绍。另外，简要介绍各种视图的作用和针对的用户 2.2构架表示方式 本节说明当前系统所使用的软件构架及其表示方式。还会从用例视图、逻辑视图、进程视图、部署视图和实施视图中列出必需的那些视图，并分别说明这些视图包含哪些类型的模型元素 2.3构架目标和约束 本节说明对构架具有某种重要影响的软件需求和目标，例如：安全性、保密性、市售产品的使用、可移植
从性能角度来看，处理器、内存和I/O这三个子系统在服务器中是最重要的，它们也是最容易出现性能瓶颈的地方。目前市场上主流的服务器大多使用英特尔Nehalem、Westmere微内核架构的三个家族处理器：Nehalem-EP，Nehalem-EX 和Westmere-EP。下表总结了这些处理器的主要特性： 在本文中，我们将分别从处理器、内存、I/O三大子系统出发，带你一起来梳理和了解最新英特尔架构服务器的变化和关键技术。 一、处理器的演变 现代处理器都采用了最新的硅技术，但一个单die(构成处理器的半导体材料块)上有数百万个晶体管和数兆存储器。多个die组织到一起就形成了一个硅晶片，每个die都是独立切块，测试和用陶瓷封装的，下图显示了封装好的英特尔至强5500处理器外观。 图 1 英特尔至强5500处理器 插座 处理器是通过插座安装到主板上的，下图显示了一个英特尔处理器插座，用户可根据自己的需要，选择不同时钟频率和功耗的处理器安装到主板上。
图 2 英特尔处理器插座 主板上插座的数量决定了最多可支持的处理器数量，最初，服务器都只有一个处理器插座，但为了提高服务器的性能，市场上已经出现了包含2，4和8个插座的主板。 在处理器体系结构的演变过程中，很长一段时间，性能的改善都与提高时钟频率紧密相关，时钟频率越高，完成一次计算需要的时间越短，因此性能就越好。随着时钟频率接近4GHz，处理器材料物理性质方面的原因限制了时钟频率的进一步提高，因此必须找出提高性能的替代方法。 核心 晶体管尺寸不断缩小(Nehalem使用45nm技术，Westmere使用32nm技术)，允许在单块die上集成更多晶体管，利用这个优势，可在一块die上多次复制最基本的CPU(核心)，因此就诞生了多核处理器。
目录 1. 文档简介6 1.1 文档目的6 1.2 文档范围6 1.3 定义、缩写词和缩略语6 1.4 参考资料7 2. 架构描述方式7 2.1 架构视图阅读指南7 2.2 图表与模型阅读指南7 3. 架构设计目标8
3.1 关键功能8 3.2 关键质量属性8 3.3 业务需求和约束因素8 4. 架构设计原则9 4.1 架构设计原则9 4.2 备选架构设计方案及被否原因9 4.3 架构设计对后续工作的限制（详设，部署等）9 5. 逻辑架构视图10 5.1 职责划分与职责确定11 5.2 接口设计与协作机制11 5.3 重要设计包12
6. 开发架构视图12 6.1 Project划分13 6.2 Project 1 14 6.2.1 Project目录结构指导14 6.2.2 程序单元组织14 6.2.3 框架与应用之间的关系（可选）15 6.3 Project 2 (15) 6.4 Project n (16) 7. 运行架构视图16 7.1 控制流组织16 7.2 控制流的创建、销毁、通信17
7.3 加锁设计17 8. 物理架构视图18 8.1 物理拓扑18 8.2 软件到硬件的映射19 8.3 优化部署19 9. 数据架构视图20 9.1 持久化机制的选择20 9.2 持久化存储方案20 9.3 数据同步与复制策略21 10. 关键质量属性的设计原理21
1.文档简介 [帮助读者对本文档建立基本印象，并为阅读后续内容扫清障碍。] 1.1文档目的 [文档目的，非项目目的。否则造成同一项目多个文档之间的内容重复，不利于文档维护。本小节应指明文档针对的读者对象，最好列出各种读者角 色，并说明每种读者角色应该重点阅读的章节。] 1.2文档范围 [文档的Scope，非项目的Scope。否则造成同一项目多个文档之间的内容重复，不利于文档维护。] 1.3定义、缩写词和缩略语 [集中列举文档中的定义、缩写词和缩略语。]
图片服务器分离 1介绍 现在很多的网站上都会用到大量的图片，而图片是网页传输中占主要的数据量,也是影响网站性能的主要因素。因此很多网站都会将图片存储从网站中分离出来，另外架构一个或多个服务器来存储图片，将图片放到一个虚拟目录中，而网页上的图片都用一个URL 地址来指向这些服务器上的图片的地址，这样的话网站的性能就明显提高了，图片服务器(ImageServer)的概念也就产生了。 1.1图片服务器的优势 1，分担Web服务器的I/O负载-将耗费资源的图片服务分离出来，提高服务器的性能和稳定性。 2，能够专门对图片服务器进行优化-为图片服务设置有针对性的缓存方案，减少带宽成本，提高访问速度。 3，提高网站的可扩展性-通过增加图片服务器，提高图片吞吐能力。 1.2图片服务器的注意事项 1，选择适合图片存储的物理介质和文件系统 2，使用物理上独立的服务器 3，如果拥有多台图片服务器，要考虑服务器之间的图片同步问题 4，使用独立域名 5，制定合理的缓存策略 6，使用图片处理模块对用户上传的图片进行再加工 1.3图片服务器的架构 图片是网站中必不可少的一个组成部分，随着网站的不断发展，对图片的处理也将随着访问的增长，图片的增加提出不断改进的需求，网站初期，所有的一切都从简图片所存在的位置通常会在站点下的Images文件夹。 随着访问的增加，IIS压力的增大，开始做拆分，将图片文件夹作为单独站点提取出来如http://images.***.com/(可能根据需要会拆分成多个图片服务器，与具体业务环境相关)，拆分之后很好的将单个IIS应用池的压力分担到2个乃至多个上，大大提高访问瓶颈。随着访问的进一步增加，服务器压力已经无法支撑，这时我们需要将图片站点作为独立服务器存在。在访问图片的过程中，我们可能会面临一个图片有多个图片尺寸的需求，前期我们通常会在保存页面的过程中保存我们需要的各个尺寸图片，但随着所需尺寸的不同，保存图片时需要的尺寸越来越多，这时我们如何应对？ IIS服务器的并发访问意味着随着用户的进一步增加，我们单台图片服务器已经不足以应对了，此时我们如何进一步扩展？
数据中心架构建设计方案建议书 1、数据中心网络功能区分区说明 1.1 功能区说明 图1：数据中心网络拓扑图 数据中心网络通过防火墙和交换机等网络安全设备分隔为个功能区：互联网区、应用服务器区、核心数据区、存储数据区、管理区和测试区。可通过在防火墙上设置策略来灵活控制各功能区之间的访问。各功能区拓扑结构应保持基本一致，并可根据需要新增功能区。 在安全级别的设定上，互联网区最低，应用区次之，测试区等，核心数据区和存储数据区最高。 数据中心网络采用冗余设计，实现网络设备、线路的冗余备份以保证较高的可靠性。 1.2 互联网区网络 外联区位于第一道防火墙之外，是数据中心网络的Internet接口，提供与Internet 高速、可靠的连接，保证客户通过Internet访问支付中心。 根据中国南电信、北联通的网络分割现状，数据中心同时申请中国电信、中国联通各1条Internet线路。实现自动为来访用户选择最优的网络线路，保证优质的网络访问服务。当1条线路出现故障时，所有访问自动切换到另1条线路，即实现线路的冗余备份。
但随着移动互联网的迅猛发展，将来一定会有中国移动接入的需求，互联区网络为未来增加中国移动（铁通）链路接入提供了硬件准备，无需增加硬件便可以接入更多互联网接入链路。 外联区网络设备主要有：2台高性能链路负载均衡设备F5 LC1600，此交换机不断能够支持链路负载,通过DNS智能选择最佳线路给接入用户,同时确保其中一条链路发生故障后,另外一条链路能够迅速接管。互联网区使用交换机可以利用现有二层交换机，也可以通过VLAN方式从核心交换机上借用端口。 交换机具有端口镜像功能，并且每台交换机至少保留4个未使用端口，以便未来网络入侵检测器、网络流量分析仪等设备等接入。 建议未来在此处部署应用防火墙产品，以防止黑客在应用层上对应用系统的攻击。 1.3 应用服务器区网络 应用服务器区位于防火墙内，主要用于放置WEB服务器、应用服务器等。所有应用服务器和web服务器可以通过F5 BigIP1600实现服务器负载均衡。 外网防火墙均应采用千兆高性能防火墙。防火墙采用模块式设计，具有端口扩展能力，以满足未来扩展功能区的需要。 在此区部署服务器负载均衡交换机，实现服务器的负载均衡。也可以采用F5虚拟化版本，即无需硬件，只需要使用软件就可以象一台虚拟服务器一样，运行在vmware ESXi上。 1.4 数据库区
WebGame服务端架构设计
目录 WebGame服务端架构设计 (1) 1需求分析 (2) 1.1背景 (2) 1.2执行环境 (2) 1.3兼容性目标 (3) 1.4网络需求 (3) 1.5系统架构设计原则 (3) 1.6模块设计原则 (3) 1.7开源组件选择 (3) 1.8国际化原则 (3) 1.9性能目标 (4) 1.10已有的成熟方案 (4) 1.11方案简介 (4) 1.11.1服务器当机时玩家数据不回档的保证方案 (4) 1.11.2服务器不停机更新方案 (4) 1.11.3脚本引擎 (4) 1.11.4配置转表工具 (5) 1.11.5前后台协议同步方案 (5) 1.11.6内存管理方案 (5) 1.11.7网络通讯方案 (5) 1.11.8视野同步方案 (5) 1.11.9任务功能实现方案 (5) 1.11.10副本功能实现方案 (6) 2整体架构 (6) 1需求分析 1.1背景 使用C/ C++技术开发的RPG游戏，系统的方向参照《神仙道》 1.2执行环境 业务层模块：对CPU要求最高，其次是内存，对磁盘容量要求不高 存储层模块：对磁盘容量要求最高，其次是内存和CPU
1、操作系统：64位LINUX 2、mysql 5.0以上。 1.4网络需求 根据游戏设计而定，如果是分区分服的设计，普通的网络机房即可。 如果是全区全服的设计，需要三通的机房网络支持。 1.5系统架构设计原则 系统按照功能职责和安全性划分子系统和模块，参考成熟架构 异常处理 过载保护 各个子系统/模块可独立扩容 1.6模块设计原则 模块内各个层次低耦合高内聚 严格控制内存使用 严格控制所有对象资源的生存期，及时回收 逻辑验证在服务器端执行，避免客户端外挂对游戏公平性造成影响对关键算法做性能优化 1.7开源组件选择 Log4c：日志 protobuf：协议 libevent：高并发监听与连接 1.8国际化原则 所有字符串使用UTF8编码 字符串不在程序中硬编码，放入指定的资源文件以方便国际化
架构设计则为满足架构需求的质量属性寻找适当的战术。对如何实现特定的质量属性感兴趣。质量需求指定了软件的响应，以实现业务目标。我们感兴趣的是设计使用设计模式、架构模式或架构策略创建设计的“战术“。 是什么使一个设计具有了可移植性，一个设计具有了高性能，而另一个设计具备了可集成性？实现这些质量属性依赖于基本的设计策略。我们将对这些称之为“战术”的设计决策进行分析。战术就是影响质量属性响应控制的设计决策。战术集合称为“架构策略”。架构模式以某种方式将战术打包在一起。 系统设计是由决策集合组成。对设计师来说，每个战术都是一个设计选择。例如，其中一个战术引入了冗余，以提高系统的可用性。这是提高可用性的一个选择但是不是唯一选择。 我们将每个系统质量属性的战术组织为层次形式，但是每个层次只是为了说明一些战术，而且任何战术列表都肯定是不完成的。 1.可用性战术 恢复和修复是可用性的重要方面，为了阻止错误发展成故障，至少能够把错误限制在一定的范围内，从而使修复成为可能。维持可用性的所有方法包括某种类型的冗余，用来检测故障的某种类型的健康监视，以及当检测到故障时某种类型的恢复。有些情况下，监视或恢复是自动进行的，有时需要手动。 我们事项考虑错误检测，然后分析错误恢复，最后讨论错误预防。 1>错误检测 用于识别错误的3个战术是命令/响应、心跳和异常
⑴命令/响应。一个组件发出一个命令，并希望在预定义的时间内收到一个 来自审查组件的响应。可以把该战术用在共同负责某项任务的一组组件内。客户机也可以使用这种战术，以确保服务器对象和到服务器的通信路径在期望的性能边界内操作。可以用一种层级形式组织“命令/响应”错误探测器，其中最底层的探测器对与其共享一个处理器的软件进程发出命令，较高层的错误探测器对较低层的探测器发出命令。与所有进程发出命令的远程错误探测器相比，这种战术所使用的通信带宽更少。 ⑵心跳。一个组件定期发出一个心跳消息，另一个组件接收听该信息。如 果心跳失败，则假定最初的组件失败，并通知错误纠正组件。心跳还可以传递数据。例如，自动柜员机定期向服务器发送一次交易日志。该消息不仅起到心跳的作用，而且传送了要处理的数据。 ⑶异常。识别错误的一个方法就是遇到了异常。 命令/响应和心跳战术在不同的进程中操作，异常战术在一个进程中操作。 异常处理程序通常将错误在语义上转换为可以被处理的形式。 2>错误恢复 错误恢复由准备恢复和修复系统两部分组成。 ⑴表决。运行在冗余处理器上的每个进程都具有相同的输入，它们计算发 送给表决者的一个简单的输出值。如果表决者检测到单处理器的异常行为，那么就中止这一行为。表决算法可以是“多数规则”或“首选组件“或其他算法。该方法用于纠正算法的错误操作或者处理器的故障，通常用在控制系统。每个冗余组件的软件可以由不同的小组开发，并且在不同平台上执行。稍微好一点情况是在不同平台上开发一个软件组件，但是这
15 第41卷 第7期 2018年7月Vol.41 No.7Jul.2018水 电 站 机 电 技 术Mechanical & Electrical Technique of Hydropower Station 收稿日期： 2018-05-29 作者简介： 仓义东（1983-），男，工程师，从事水电厂自动化工作。智能集控中心系统架构设计与实现 仓义东1，茅 伟1，衡 旭2 （1. 南瑞集团公司（国网电力科学研究院），江苏 南京211106； 2. 新疆生产建设兵团第八师玛纳斯河肯斯瓦特建设管理局，新疆 石河子832000） 摘 要： 随着中国智能电网的不断发展，智能化水电站也正在同步建设中。智能化集控中心较之一般的集控中心，由于能够充分发挥流域各水电站资源优势，近几年正成为流域集控的建设趋势。受制于客观条件及一些固有做法，集控系统架构一般较为复杂，表现为多级分层结构。本文结合新疆某集控系统的建设思路及当前主流梯级集控中心的现状，提出一种优化、简化的梯级集控中心系统架构，将原有的多层分级结构通过优化，变更为并行运行模式，既充分满足智能化集控及智能化水电站的发展需求，又满足电力系统二次安全防护的有关规定，同时使得一般集控中心改造简单易行，从而为更多的集控中心系统建设提供参考。 关键词： 智能化水电站；智能化集控中心；新型架构；优化；简化 中图分类号：TV736 文献标识码：A 文章编号：1672-5387（2018）07-0015-03 DOI：10.13599/https://www.doczj.com/doc/3f18664149.html,ki.11-5130.2018.07.005 0 引言 经过多年的不懈努力，我国各流域水电公司已 先后建立了梯级集控中心自动化系统，实现流域梯 级水电资源的优化控制管理，流域梯级电站监控、水 情水调、机组状态监测、继电保护、电能量、大坝监测 等自动化系统获得广泛的应用，为流域各电站实现 “无人值班（少人值守）”，提高流域梯级水电站的安 全运行和自动化管理水平发挥了重要作用。 随着智能化水电站的不断建设，必然对智能化集 控提出新的要求。然而在实际的集控建设过程中，受 制于一些主客观因素，系统架构过于复杂，导致故障 频发，大大降低了系统的可靠性及稳定性，增加了维 护难度，长此以往，不利于整个集控中心的健康发展。1 常规集控系统架构及一般优化 在常规集控系统架构中，集控主机经由核心交 换机与前置通信机交换数据，前置通信机通过前置 交换机、加密装置、路由器、调度数据网、电站侧路由 器、加密装置、前置交换机等与电站侧前置通信机交 换数据，电站前置通信机再经由电站核心交换机、电 站主机与电站终端控制系统交换数据，并经由电站 终端控制系统控制电站终端设备，从而实现集控的远程监视和控制。其典型系统结构如图1所示。图1 常规集控系统结构图从图1中可以看出，在常规集控系统架构中，冗余通信网络