无服务器架构

① 传奇服务器架构，我有服务器端，怎么配置，请教高手

一步一步的跟着这个步骤做应该可以架设好自己的私服服务器的，所以请大家认真看.
首先你需要下载一个服务器端，建议使用一起玩传奇精装版第4版，一起玩传奇第4版本修正所有漏洞，绝对稳定的状态下运行，服务器完全汉化.如果你要深入可以选择使用一起玩传奇第6版.

下载下来后，安装系统会选择默认路径安装，如果你是新人，建议不要修改默认路径，否则会造成许多麻烦的地方

安装后进去
D:\MIRSERVER
现介绍目录结构
GameLog 目录 游戏日值记录，里面有记录程序和记录目录，对应的软件和记录的文档方在其中
Gate_Server 目录 游戏登陆选择人物管理界面
Mir200游戏核心文件 我们在游戏中看见的修改都是通过修改这里来实现[这里就不忙介绍这些，我们现说说如何让自己的私服开通]

MUD2，DB保存地方、人物保存地方

我们现就不说其他了，现让你的私服运行起来
改IP和服务器名字往往就是新人遇到的问题,新人不建议自己手动修改，建议你用心意软件进行修改，每一个一起玩传奇精装的版本中都加入有这些相关的好用的软件，对于新人来说，是个很不错的软件.就算是技术比较成熟的用户，大家也都经常使用这个软件

进去心意软件后相关的设置一幕了然，很直接

安装私服必须安装DBC:DBC是DB Commander 2000 PRO的简称，需要自己下载，下载天空中有下载.

下载下来后进行安装

现在进入控制面板 允许 BDE ADMINISTRATOR 安 CTRL+N 按下 OK，然后在下面出现了一个STANDARD的选项，点中他安 CTRL+M 进行改名 改成 "HeroDB" 为什么有些人出现 无法读取 IP的问题就是因为这里的HeroDB没有正确填写，在这里要注意大小写最后就是设置路径了PATH 处设置成 "D:\mirserver\mud2\DB" 这个是默认安装后的路径
好了又把鼠标在 HeroDB上点击一下然后安下 "CTAL+A" 现在可以关闭他了，这里基本上私服应该可以正常运行了.
BaseDir=D:\mirserver\Mir200\Share\
GuildDir=D:\mirserver\Mir200\GuildBase\Guilds\
GuildFile=D:\mirserver\Mir200\GuildBase\Guildlist.txt
VentureDir=D:\mirserver\Mir200\ShareV\
ConLogDir=D:\mirserver\Mir200\ConLog\
CastleDir=D:\mirserver\Mir200\Envir\Castle\
EnvirDir=D:\mirserver\Mir200\Envir\
MapDir=D:\mirserver\Mir200\Map\

② 电脑和服务器X86架构和X64架构的区别是什么

实际上X86架构是基础架构，X64架构是基于X86的，也可称为X86-64架构。具体介绍如下：
x86或80x86是英特尔Intel首先开发制造的一种微处理器体系结构的泛称。该系列较早期的处理器名称是以数字来表示，并以“86”作为结尾，包括Intel 8086、80186、80286、80386以及80486，因此其架构被称为“x86”。x86架构于1978年推出的Intel 8086中央处理器中首度出现，它是从Intel 8008处理器中发展而来的，而8008则是发展自Intel 4004的。8086在三年后为IBM PC所选用，之后x86便成为了个人计算机的标准平台，成为了历来最成功的CPU架构，如Pentium、Athlon。现在，Intel把x86-32称为IA-32，全名为“Intel Architecture, 32-bit”。
x86-64架构诞生颇有时代意义。当时处理器的发展遇到了瓶颈，内存寻址空间由于受到32位CPU的限制而只能最大到约4G。AMD主动把32位x86（或称为IA-32）扩充为64位。它以一个称为AMD64的架构出现（在重命名前也称为x86-64），且以这个技术为基础的第一个产品是单内核的Opteron和Athlon 64处理器家族。由于AMD的64位处理器产品线首先进入市场，且微软也不愿意为Intel和AMD开发两套不同的64位操作系统，Intel也被迫采纳AMD64指令集且增加某些新的扩充到他们自己的产品，命名为EM64T架构（显然他们不想承认这些指令集是来自它的主要对手），EM64T后来被Intel正式更名为Intel 64。这两者被统称为x86-64或x64，开创了x86的64位时代。
关于32位系统与64位系统的比较，速度并不是唯一的考量因素。也不能因为数字上的变化，简单地认为64位CPU的性能是32位CPU的两倍。实际在目前阶段64位的应用程序并不多，即便有，很多也只是因为其32位的版本无法在64位操作系统上运行而产生的。而没有真正做过64位优化的程序，性能上并不会带来太大的提升。相反，在32位的应用上 ，跑32位的CPU性能甚至会更强。另一方面，由于32位的Windows系统最大只支持3.25G的内存，而64位的Windows系统则可以最大支持128G的内存。所以，当电脑内存大于4G时，就要果断采用64位系统了。

③ 关于服务器架构问题

初级篇：（单机模式）

假设配置：（Dual core 2.0GHz,4GB ram,SSD）

基础框架：apache(PHP) + Mysql / IIS + MSSQL
（最基础框架，处理一般访问请求）

进阶1：替换Apache为Nginx，并在数据库前加上cache层【数据库的速度是最大的瓶颈】
Nginx(PHP) + Memcache + Mysql
（此时已经具备处理小型访问量的能力）

进阶2：随着访问量的上涨，最先面临的问题就来了：CGI无法匹配上Nginx的高IO性能，这时候可以通过写扩展来替代脚本程序来提升性能，C扩展是个好办法，但是大家更喜欢用简单的脚本语言完成任务，Taobao团队开源了一个Nginx_lua模块，可以用lua写Nginx扩展，这时候可处理的并发已经超越进阶1 一个档次了。
Nginx(nginx_lua or C) + Memcache + Mysql
（此时处理个同时在线三四千人没有问题了）

进阶3：随着用户的增多，Mysql的写入速度成了又一大瓶颈，读取有memcache做缓存，但写入是直接面对Mysql，性能受到了很大阻碍，这时候，要在Nginx和Mysql中间加入一层写缓存，队列系统就出场了,就以RabbitMQ为例，所有写入操作全部丢到这只兔子的胃里面，然后屁股后面写个接应程序，一条条的拉出来再写入mysql。而RabbitMQ的写入效率是Mysql的N倍，此时架构的处理能力又上一阶层。
|----write------>RabbitMQ--------
Nginx（lua or c）----- |--------->Mysql
|----read------>Memcache--------

(此时的并发吞吐能力已经可以处理万人左右在线)

中级篇：（分而治之）

此时我们在单机优化上已经算是达到极限，接下来就要集群来显示作用了。

数据库篇： 数据库总是在整个环节中是吞吐能力最弱的，最常见的方法就是sharding。
sharding可以按多种方法来分，没有定式，看情况。可以按用户ID区段分，按读写分等等，可用参考软件：mysql proxy（工作原理类似lvs）

缓存篇：memcache一般采用的是构建memcache pool，将缓存分散到多台memcache节点上，如何将缓存数据均匀分散在各节点，一般采用将各节点顺序编号，然后hash取余对应到各个节点上去。这样可以做到比较均匀的分散，但是有一个致命点就是，如果节点数增加或减少，将会带来几乎80%的数据迁移，解决方案我们在高级篇再提。

WEB服务器篇： web服务器集群的建设，最常见的就是lvs方式(memcache pool同样可以如此组建)，lvs的核心就是调度节点，调度节点负责将流量通过算法分散到各个节点上，因调度所耗资源很少，所以可以产生很高的吞吐率，后台节点数量可以任意增删，但此法弊病就是如果调度节点挂了，则整个集群都挂了，解决方案我们在高级篇提。

高级篇：（高可用性+高可扩展性的集群）

单点调度故障解决：
集群的好处显而易见，但是有一个弊端就是单节点进行调度，如果节点出现故障，则整个集群全部都无法服务，对此的解决方案，我们使用keepalived来解决。Keepalived for Linux
keepalived是基于VRRP协议（VRRP协议介绍）的，请一定先了解VRRP协议后再进行配置。
keepalived可以把多台设备虚拟出一个IP，并自动在故障节点与备用节点之间实现failover切换。这样我们配置两台货多台lvs调度节点，然后配置好keepalived就可以做到lvs调度节点出现故障后，自动切换到备用调度节点。（同样适用于mysql）

memcache集群扩展解决：
memcache因为我们一般采用的都是hash后除以节点数取余，然后分配到对应节点上，如果节点数出现变化，以前的缓存数据将基本都不能命中。

④ 几种经典的网络服务器架构模型的分析与比较

前言
事件驱动为广大的程序员所熟悉，其最为人津津乐道的是在图形化界面编程中的应用；事实上，在网络编程中事件驱动也被广泛使用，并大规模部署在高连接 数高吞吐量的服务器程序中，如 http 服务器程序、ftp 服务器程序等。相比于传统的网络编程方式，事件驱动能够极大的降低资源占用，增大服务接待能力，并提高网络传输效率。
关于本文提及的服务器模型，搜索网络可以查阅到很多的实现代码，所以，本文将不拘泥于源代码的陈列与分析，而侧重模型的介绍和比较。使用 libev 事件驱动库的服务器模型将给出实现代码。
本文涉及到线程 / 时间图例，只为表明线程在各个 IO 上确实存在阻塞时延，但并不保证时延比例的正确性和 IO 执行先后的正确性；另外，本文所提及到的接口也只是笔者熟悉的 Unix/Linux 接口，并未推荐 Windows 接口，读者可以自行查阅对应的 Windows 接口。
阻塞型的网络编程接口
几乎所有的程序员第一次接触到的网络编程都是从 listen()、send()、recv()等接口开始的。使用这些接口可以很方便的构建服务器 /客户机的模型。
我们假设希望建立一个简单的服务器程序，实现向单个客户机提供类似于“一问一答”的内容服务。
图 1. 简单的一问一答的服务器 /客户机模型

我们注意到，大部分的 socket接口都是阻塞型的。所谓阻塞型接口是指系统调用（一般是 IO接口）不返回调用结果并让当前线程一直阻塞，只有当该系统调用获得结果或者超时出错时才返回。
实际上，除非特别指定，几乎所有的 IO接口 (包括 socket 接口 )都是阻塞型的。这给网络编程带来了一个很 大的问题，如在调用 send()的同时，线程将被阻塞，在此期间，线程将无法执行任何运算或响应任何的网络请求。这给多客户机、多业务逻辑的网络编程带 来了挑战。这时，很多程序员可能会选择多线程的方式来解决这个问题。
多线程服务器程序
应对多客户机的网络应用，最简单的解决方式是在服务器端使用多线程（或多进程）。多线程（或多进程）的目的是让每个连接都拥有独立的线程（或进程），这样任何一个连接的阻塞都不会影响其他的连接。
具体使用多进程还是多线程，并没有一个特定的模式。传统意义上，进程的开销要远远大于线程，所以，如果需要同时为较多的客户机提供服务，则不推荐使 用多进程；如果单个服务执行体需要消耗较多的 CPU 资源，譬如需要进行大规模或长时间的数据运算或文件访问，则进程较为安全。通常，使用 pthread_create () 创建新线程，fork() 创建新进程。
我们假设对上述的服务器 / 客户机模型，提出更高的要求，即让服务器同时为多个客户机提供一问一答的服务。于是有了如下的模型。
图 2. 多线程服务器模型

在上述的线程 / 时间图例中，主线程持续等待客户端的连接请求，如果有连接，则创建新线程，并在新线程中提供为前例同样的问答服务。
很多初学者可能不明白为何一个 socket 可以 accept 多次。实际上，socket 的设计者可能特意为多客户机的情况留下了伏笔，让 accept() 能够返回一个新的 socket。下面是 accept 接口的原型：
?

1

intaccept(ints,structsockaddr *addr, socklen_t *addrlen);


输入参数 s 是从 socket()，bind() 和 listen() 中沿用下来的 socket 句柄值。执行完 bind() 和 listen() 后，操作系统已经开始在指定的端口处监听所有的连接请求，如果有请求，则将该连接请求加入请求队列。调用 accept() 接口正是从 socket s 的请求队列抽取第一个连接信息，创建一个与 s 同类的新的 socket 返回句柄。新的 socket 句柄即是后续 read() 和 recv() 的输入参数。如果请求队列当前没有请求，则 accept() 将进入阻塞状态直到有请求进入队列。
上述多线程的服务器模型似乎完美的解决了为多个客户机提供问答服务的要求，但其实并不尽然。如果要同时响应成百上千路的连接请求，则无论多线程还是多进程都会严重占据系统资源，降低系统对外界响应效率，而线程与进程本身也更容易进入假死状态。
很多程序员可能会考虑使用“线程池”或“连接池”。“线程池”旨在减少创建 和销毁线程的频率，其维持一定合理数量的线程，并让空闲的线程重新承担新的执行任务。“连接池”维持连接的缓存池，尽量重用已有的连接、减少创建和关闭连 接的频率。这两种技术都可以很好的降低系统开销，都被广泛应用很多大型系统，如 websphere、tomcat 和各种数据库等。
但是，“线程池”和“连接池”技术也只是在一定程度上缓解了频繁调用 IO 接口带来的资源占用。而且，所谓“池”始终有其上限，当请求大大超过上限时，“池”构成的系统对外界的响应并不比没有池的时候效果好多少。所以使用“池” 必须考虑其面临的响应规模，并根据响应规模调整“池”的大小。
对应上例中的所面临的可能同时出现的上千甚至上万次的客户端请求，“线程池”或“连接池”或许可以缓解部分压力，但是不能解决所有问题。
总之，多线程模型可以方便高效的解决小规模的服务请求，但面对大规模的服务请求，多线程模型并不是最佳方案。下一章我们将讨论用非阻塞接口来尝试解决这个问题。
使用select()接口的基于事件驱动的服务器模型
大部分 Unix/Linux 都支持 select 函数，该函数用于探测多个文件句柄的状态变化。下面给出 select 接口的原型：
?

1
2
3
4
5
6

FD_ZERO(intfd, fd_set* fds)
FD_SET(intfd, fd_set* fds)
FD_ISSET(intfd, fd_set* fds)
FD_CLR(intfd, fd_set* fds)
intselect(intnfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
structtimeval *timeout)


这里，fd_set 类型可以简单的理解为按 bit 位标记句柄的队列，例如要在某 fd_set 中标记一个值为 16 的句柄，则该 fd_set 的第 16 个 bit 位被标记为 1。具体的置位、验证可使用 FD_SET、FD_ISSET 等宏实现。在 select() 函数中，readfds、writefds 和 exceptfds 同时作为输入参数和输出参数。如果输入的 readfds 标记了 16 号句柄，则 select() 将检测 16 号句柄是否可读。在 select() 返回后，可以通过检查 readfds 有否标记 16 号句柄，来判断该“可读”事件是否发生。另外，用户可以设置 timeout 时间。
下面将重新模拟上例中从多个客户端接收数据的模型。
图4.使用select()的接收数据模型

上述模型只是描述了使用 select() 接口同时从多个客户端接收数据的过程；由于 select() 接口可以同时对多个句柄进行读状态、写状态和错误状态的探测，所以可以很容易构建为多个客户端提供独立问答服务的服务器系统。
图5.使用select()接口的基于事件驱动的服务器模型

这里需要指出的是，客户端的一个 connect() 操作，将在服务器端激发一个“可读事件”，所以 select() 也能探测来自客户端的 connect() 行为。
上述模型中，最关键的地方是如何动态维护 select() 的三个参数 readfds、writefds 和 exceptfds。作为输入参数，readfds 应该标记所有的需要探测的“可读事件”的句柄，其中永远包括那个探测 connect() 的那个“母”句柄；同时，writefds 和 exceptfds 应该标记所有需要探测的“可写事件”和“错误事件”的句柄 ( 使用 FD_SET() 标记 )。
作为输出参数，readfds、writefds 和 exceptfds 中的保存了 select() 捕捉到的所有事件的句柄值。程序员需要检查的所有的标记位 ( 使用 FD_ISSET() 检查 )，以确定到底哪些句柄发生了事件。
上述模型主要模拟的是“一问一答”的服务流程，所以，如果 select() 发现某句柄捕捉到了“可读事件”，服务器程序应及时做 recv() 操作，并根据接收到的数据准备好待发送数据，并将对应的句柄值加入 writefds，准备下一次的“可写事件”的 select() 探测。同样，如果 select() 发现某句柄捕捉到“可写事件”，则程序应及时做 send() 操作，并准备好下一次的“可读事件”探测准备。下图描述的是上述模型中的一个执行周期。
图6. 一个执行周期

这种模型的特征在于每一个执行周期都会探测一次或一组事件，一个特定的事件会触发某个特定的响应。我们可以将这种模型归类为“事件驱动模型”。
相比其他模型，使用 select() 的事件驱动模型只用单线程（进程）执行，占用资源少，不消耗太多 CPU，同时能够为多客户端提供服务。如果试图建立一个简单的事件驱动的服务器程序，这个模型有一定的参考价值。
但这个模型依旧有着很多问题。
首先，select() 接口并不是实现“事件驱动”的最好选择。因为当需要探测的句柄值较大时，select() 接口本身需要消耗大量时间去轮询各个句柄。很多操作系统提供了更为高效的接口，如 linux 提供了 epoll，BSD 提供了 kqueue，Solaris 提供了 /dev/poll …。如果需要实现更高效的服务器程序，类似 epoll 这样的接口更被推荐。遗憾的是不同的操作系统特供的 epoll 接口有很大差异，所以使用类似于 epoll 的接口实现具有较好跨平台能力的服务器会比较困难。
其次，该模型将事件探测和事件响应夹杂在一起，一旦事件响应的执行体庞大，则对整个模型是灾难性的。如下例，庞大的执行体 1 的将直接导致响应事件 2 的执行体迟迟得不到执行，并在很大程度上降低了事件探测的及时性。
图7. 庞大的执行体对使用select()的事件驱动模型的影响

幸运的是，有很多高效的事件驱动库可以屏蔽上述的困难，常见的事件驱动库有 libevent 库，还有作为 libevent 替代者的 libev 库。这些库会根据操作系统的特点选择最合适的事件探测接口，并且加入了信号 (signal) 等技术以支持异步响应，这使得这些库成为构建事件驱动模型的不二选择。下章将介绍如何使用 libev 库替换 select 或 epoll 接口，实现高效稳定的服务器模型。
使用事件驱动库libev的服务器模型
Libev 是一种高性能事件循环 / 事件驱动库。作为 libevent 的替代作品，其第一个版本发布与 2007 年 11 月。Libev 的设计者声称 libev 拥有更快的速度，更小的体积，更多功能等优势，这些优势在很多测评中得到了证明。正因为其良好的性能，很多系统开始使用 libev 库。本章将介绍如何使用 Libev 实现提供问答服务的服务器。
（事实上，现存的事件循环 / 事件驱动库有很多，作者也无意推荐读者一定使用 libev 库，而只是为了说明事件驱动模型给网络服务器编程带来的便利和好处。大部分的事件驱动库都有着与 libev 库相类似的接口，只要明白大致的原理，即可灵活挑选合适的库。）
与前章的模型类似，libev 同样需要循环探测事件是否产生。Libev 的循环体用 ev_loop 结构来表达，并用 ev_loop( ) 来启动。
?

1

voidev_loop( ev_loop* loop,intflags )


Libev 支持八种事件类型，其中包括 IO 事件。一个 IO 事件用 ev_io 来表征，并用 ev_io_init() 函数来初始化：
?

1

voidev_io_init(ev_io *io, callback,intfd,intevents)


初始化内容包括回调函数 callback，被探测的句柄 fd 和需要探测的事件，EV_READ 表“可读事件”，EV_WRITE 表“可写事件”。
现在，用户需要做的仅仅是在合适的时候，将某些 ev_io 从 ev_loop 加入或剔除。一旦加入，下个循环即会检查 ev_io 所指定的事件有否发生；如果该事件被探测到，则 ev_loop 会自动执行 ev_io 的回调函数 callback()；如果 ev_io 被注销，则不再检测对应事件。
无论某 ev_loop 启动与否，都可以对其添加或删除一个或多个 ev_io，添加删除的接口是 ev_io_start() 和 ev_io_stop()。
?

1
2

void ev_io_start( ev_loop *loop, ev_io* io )
void ev_io_stop( EV_A_* )


由此，我们可以容易得出如下的“一问一答”的服务器模型。由于没有考虑服务器端主动终止连接机制，所以各个连接可以维持任意时间，客户端可以自由选择退出时机。
图8. 使用libev库的服务器模型

上述模型可以接受任意多个连接，且为各个连接提供完全独立的问答服务。借助 libev 提供的事件循环 / 事件驱动接口，上述模型有机会具备其他模型不能提供的高效率、低资源占用、稳定性好和编写简单等特点。
由于传统的 web 服务器，ftp 服务器及其他网络应用程序都具有“一问一答”的通讯逻辑，所以上述使用 libev 库的“一问一答”模型对构建类似的服务器程序具有参考价值；另外，对于需要实现远程监视或远程遥控的应用程序，上述模型同样提供了一个可行的实现方案。
总结
本文围绕如何构建一个提供“一问一答”的服务器程序，先后讨论了用阻塞型的 socket 接口实现的模型，使用多线程的模型，使用 select() 接口的基于事件驱动的服务器模型，直到使用 libev 事件驱动库的服务器模型。文章对各种模型的优缺点都做了比较，从比较中得出结论，即使用“事件驱动模型”可以的实现更为高效稳定的服务器程序。文中描述的 多种模型可以为读者的网络编程提供参考价值。

⑤ 文档服务器架构是什么

文档服务器是用于政府、企业等机构安全共享文档信息的整体解决方案，它依托书生 TESDI 数字权限管理技术、 SEP 数字文档技术，以集中管理的方式完整保存各单位日常产生的各类文档，提供最大程度的共享机制，使文档信息的价值得到最充分的利用，同时还能保证敏感文件不会被泄露 , 即使是对合法阅读者也能进行拷贝、打印等权限的管理和控制，从而彻底解决机构用户的信息数字化率和信息使用率偏低的问题。

书生文档服务器是一个文档集中存放，受限访问的平台。系统采用了书生 SEPReader 作为文档阅读的终端，采用 SEPWriter 作为文档转换的工具。 SEP Writer 将不同格式不同应用程序生成的文档转换成统一的 SEP 格式，再通过客户端将转换后的文件提交给给安全文档管理服务器（ SDP Server ），保存到专门的安全文档数据库中。服务器统一控制每个文档针对每个操作人员的浏览、复制、打印、传播、摘录等权限，最大限度的保证电子文档安全，而且又不妨碍合法和正常的阅读以及操作。

书生文档服务器集成了多种主流的用户身份机制，包括 Windows 域和活动目录， Lotus 用户集成， LDAP 用户集成以及提供集成其他基于数据库的应用系统用户机制。可以和各种类型的应用系统无缝集成。系统提供 14 种不同粒度的访问权限，可以充分满足复杂的管理需要。

传统的文档管理系统不同的是，书生文档服务器真正防止了非受限的传播重要文档，比如传统的档案系统，虽然有多级的用户权限管理机制，但文档一旦被某个用户访问，用户就可以不受限的将该文档通过拷贝，邮寄等方式传播给他人。而此系统采用的文档的终生机制，文档无论何时被访问，除非管理员特别指定，文档都受管理系统的控制。可以称作是全程安全的文档管理系统。

文档服务器可以与书生 Office 配合进行使用，会具有最佳的使用效果。用户在用 Office 编辑定稿后轻松一键即可提交给文档服务器，便捷方便的操作最大程度地降低了使用者的负担，使文档集中共享的制度能得到最有效的贯彻执行。

⑥ 无服务架构和微服务器架构的区别

微服务架构中有两个阵营，一是坚持微服务是无状态的HTTP API服务，另一阵营认为微服务本身就要内求把整个系统当做一个容完整的分布式应用来对待，而不是原来那种把各种组件堆积在一起，“拼接”系统的做法。
无服务架构就是原来那种把各种组件堆积在一起，拼接系统的做法。

⑦ 服务器类型的架构

服务器是静态IP吧
直接\\IP不行，你去ping下服务器IP看看，如果能连接，但ping不通IP的话，一般版是服务器上的服务里有什权么被禁用了，把相关的和网络有关的服务全部打开。
还有就是防火墙关系，我之前就是因为防火墙ping不通IP，但能连接。
ping不通IP的话，\\IP回车就不能直接连接。

⑧ 什么是Serverless架构

Serverless（无服务器架构）是指服务端逻辑由开发者实现，应用运行在无状态的计算容器中，由事件触发，完全被第三方管理，其业务层面的状态则存储在数据库或其他介质中。

Serverless可以使开发者更聚焦在业务逻辑，而减少对基础设施的关注。

Serverless通常包含了两个领域 BaaS（Backend as a Service）和 FaaS（Function as a Service）

• BaaS是一种广泛依赖于第三方应用和服务的无服务器计算方法。BaaS供应商可以提供加密、用户认证、云数据库的使用。这些服务可以通过调用云供应商提供的API进行访问；相比自己重新开发，这些功能可以更方便地整合到各个类型的系统中。

• FaaS 是一种事件驱动的由消息触发的服务，FaaS 供应商一般会集成各种同步和异步的事件（如AWS的SNS），通过订阅这些事件，可以触发指定的函数运行，例如当前使用很广泛的 AWS 的 Lambda函数。

Serverless架构的优点

• 降低运营成本：

Serverless是非常简单的外包解决方案。它可以让您委托服务提供商管理服务器、数据库和应用程序甚至逻辑。由于这个服务使用者的数量会非常庞大，于是就会产生规模经济效应。在降低成本上包含了两个方面，即基础设施的成本和人员（运营/开发/维护）的成本。

• 降低开发成本：

Serverless作为一种云服务，使得整个应用程序组件被商品化。

• 扩展能力：

横向扩展是完全自动的、有弹性的、且由服务提供者所管理。从基本的基础设施方面受益最大的好处是，您只需支付您所需要的计算能力。

• 更简单的管理：

Serverless架构明显比其他架构更简单。更少的组件，就意味着您的管理开销会更少。

• 有效利用计算资源：

据《福布斯》的统计，在商业和企业数据中心的典型服务器仅提供5%～15%的平均最大处理能力的输出。这无疑是一种资源的巨大浪费。Serverless让服务提供商提供我们的计算能力最大限度满足实时需求，更有效地利用计算资源。




Serverless架构的缺点

• 状态管理：

要想实现自由的缩放，无状态是必须的，而对于有状态的服务，使用serverless这就丧失了灵活性。

• 延迟：

Serverless应用程序是高度分布式、低耦合的，这就意味着延迟将始终是一个问题，单纯使用serverless的应用程序是不太现实的。

• 本地测试：

Serverless应用的本地测试困难是一个很棘手的问题。虽然可以在测试环境下使用各种数据库和消息队列来模拟生产环境，但是对于无服务应用的集成或者端到端测试很困难。

⑨ 服务器架构是什么意思

所谓服务器架构，也就是如何将服务器各部分合理地安排，以实现最初的功专能需求。所以属，架构本无所谓正确与错误；当然，优秀的架构更有助于系统的搭建，对系统的可扩展性及可维护性也有更大的帮助。