服务器有哪几种 ？

文件服务器、数据库服务器、邮件服务器。

文件服务器是指在计算机网络中,以文件数据的存储与共享为主要功能的服务器,负责中央存储和数据文件管理,处于同一网络环境。数据库服务器因为数据文件的重要性及数据的文件都较大,数据库服务器一般是指运行在网络中的一台或多台服务器和数据库管理系统软件，邮件服务器。

文件服务器（Fileserver），又称档案伺服器，是指在计算机网络环境中，所有用户都可访问的文件存储设备，是一种专供其他电脑检索文件和存储的特殊电脑。文件服务器通常比一般的个人电脑拥有更大的存储容量，并具有一些其他的功能，如磁盘镜像、多个网络接口。

分布式架构的演进

系统架构演化历程-初始阶段架构

初始阶段 的小型系统 应用程序、数据库、文件等所有的资源都在一台服务器上通俗称为LAMP

特征：

应用程序、数据库、文件等所有的资源都在一台服务器上。

描述：

通常服务器操作系统使用Linux，应用程序使用PHP开发，然后部署在Apache上，数据库使用MySQL，汇集各种免费开源软件以及一台廉价服务器就可以开始系统的发展之路了。

系统架构演化历程-应用服务和数据服务分离

好景不长，发现随着系统访问量的再度增加，webserver机器的压力在高峰期会上升到比较高，这个时候开始考虑增加一台webserver

特征：

应用程序、数据库、文件分别部署在独立的资源上。

描述：

数据量增加，单台服务器性能及存储空间不足，需要将应用和数据分离，并发处理能力和数据存储空间得到了很大改善。

系统架构演化历程-使用缓存改善性能

特征：

数据库中访问较集中的一小部分数据存储在缓存服务器中，减少数据库的访问次数，降低数据库的访问压力。

描述：

系统访问特点遵循二八定律，即80%的业务访问集中在20%的数据上。

缓存分为本地缓存和远程分布式缓存，本地缓存访问速度更快但缓存数据量有限，同时存在与应用程序争用内存的情况。

系统架构演化历程-使用应用服务器集群

在做完分库分表这些工作后，数据库上的压力已经降到比较低了，又开始过着每天看着访问量暴增的幸福生活了，突然有一天，发现系统的访问又开始有变慢的趋势了，这个时候首先查看数据库，压力一切正常，之后查看webserver，发现apache阻塞了很多的请求，而应用服务器对每个请求也是比较快的，看来 是请求数太高导致需要排队等待，响应速度变慢

特征：

多台服务器通过负载均衡同时向外部提供服务，解决单台服务器处理能力和存储空间上限的问题。

描述：

使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源，提升系统的并发处理能力，使得服务器的负载压力不再成为整个系统的瓶颈。

系统架构演化历程-数据库读写分离

享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢，经过查找，发现数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈，导致了系统变慢

特征：

多台服务器通过负载均衡同时向外部提供服务，解决单台服务器处理能力和存储空间上限的问题。

描述：

使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源，使得服务器的负载压力不在成为整个系统的瓶颈。

系统架构演化历程-反向代理和CDN加速

特征：

采用CDN和反向代理加快系统的 访问速度。

描述：

为了应付复杂的网络环境和不同地区用户的访问，通过CDN和反向代理加快用户访问的速度，同时减轻后端服务器的负载压力。CDN与反向代理的基本原理都是缓存。

系统架构演化历程-分布式文件系统和分布式数据库

随着系统的不断运行，数据量开始大幅度增长，这个时候发现分库后查询仍然会有些慢，于是按照分库的思想开始做分表的工作

特征：

数据库采用分布式数据库，文件系统采用分布式文件系统。

描述：

任何强大的单一服务器都满足不了大型系统持续增长的业务需求，数据库读写分离随着业务的发展最终也将无法满足需求，需要使用分布式数据库及分布式文件系统来支撑。

分布式数据库是系统数据库拆分的最后方法，只有在单表数据规模非常庞大的时候才使用，更常用的数据库拆分手段是业务分库，将不同的业务数据库部署在不同的物理服务器上。

系统架构演化历程-使用NoSQL和搜索引擎

特征：

系统引入NoSQL数据库及搜索引擎。

描述：

随着业务越来越复杂，对数据存储和检索的需求也越来越复杂，系统需要采用一些非关系型数据库如NoSQL和分数据库查询技术如搜索引擎。应用服务器通过统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。

系统架构演化历程-业务拆分

特征：

系统上按照业务进行拆分改造，应用服务器按照业务区分进行分别部署。

描述：

为了应对日益复杂的业务场景，通常使用分而治之的手段将整个系统业务分成不同的产品线，应用之间通过超链接建立关系，也可以通过消息队列进行数据分发，当然更多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。

纵向拆分：

将一个大应用拆分为多个小应用，如果新业务较为独立，那么就直接将其设计部署为一个独立的Web应用系统

纵向拆分相对较为简单，通过梳理业务，将较少相关的业务剥离即可。

横向拆分：将复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用这些分布式服务

横向拆分需要识别可复用的业务，设计服务接口，规范服务依赖关系。

系统架构演化历程-分布式服务

特征：

公共的应用模块被提取出来，部署在分布式服务器上供应用服务器调用。

描述：

随着业务越拆越小，应用系统整体复杂程度呈指数级上升，由于所有应用要和所有数据库系统连接，最终导致数据库连接资源不足，拒绝服务。

Q：分布式服务应用会面临哪些问题？

A：

(1) 当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。

(2) 当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。

(3) 接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？

(4) 服务多了，沟通成本也开始上升，调某个服务失败该找谁？服务的参数都有什么约定？

(5) 一个服务有多个业务消费者，如何确保服务质量？

(6) 随着服务的不停升级，总有些意想不到的事发生，比如cache写错了导致内存溢出，故障不可避免，每次核心服务一挂，影响一大片，人心慌慌，如何控制故障的影响面？服务是否可以功能降级？或者资源劣化？

Java分布式应用技术基础

分布式服务下的关键技术：消息队列架构

消息对列通过消息对象分解系统耦合性，不同子系统处理同一个消息

分布式服务下的关键技术：消息队列原理

分布式服务下的关键技术：服务框架架构

服务框架通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务启用

服务框架是一个点对点模型

服务框架面向同构系统

适合：移动应用、互联网应用、外部系统

分布式服务下的关键技术：服务框架原理

分布式服务下的关键技术：服务总线架构

服务总线同服务框架一样，均是通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务启用

服务总线是一个总线式的模型

服务总线面向同构、异构系统

适合：内部系统

分布式服务下的关键技术：服务总线原理

分布式架构下系统间交互的5种通信模式

request/response模式（同步模式）：客户端发起请求一直阻塞到服务端返回请求为止。

Callback（异步模式）：客户端发送一个RPC请求给服务器，服务端处理后再发送一个消息给消息发送端提供的callback端点，此类情况非常合适以下场景：A组件发送RPC请求给B，B处理完成后，需要通知A组件做后续处理。

Future模式：客户端发送完请求后，继续做自己的事情，返回一个包含消息结果的Future对象。客户端需要使用返回结果时，使用Future对象的get(),如果此时没有结果返回的话，会一直阻塞到有结果返回为止。

Oneway模式：客户端调用完继续执行，不管接收端是否成功。

Reliable模式：为保证通信可靠，将借助于消息中心来实现消息的可靠送达，请求将做持久化存储，在接收方在线时做送达，并由消息中心保证异常重试。

五种通信模式的实现方式-同步点对点服务模式

五种通信模式的实现方式-异步点对点消息模式1

五种通信模式的实现方式-异步点对点消息模式2

五种通信模式的实现方式-异步广播消息模式

分布式架构下的服务治理

服务治理是服务框架/服务总线的核心功能。所谓服务治理，是指服务的提供方和消费方达成一致的约定，保证服务的高质量。服务治理功能可以解决将某些特定流量引入某一批机器，以及限制某些非法消费者的恶意访问，并在提供者处理量达到一定程度是，拒绝接受新的访问。

基于服务框架Dubbo的服务治理-服务管理

可以知道你的系统，对外提供了多少服务，可以对服务进行升级、降级、停用、权重调整等操作

可以知道你提供的服务，谁在使用，因业务需求，可以对该消费者实施屏蔽、停用等操作

基于服务框架Dubbo的服务治理-服务监控

可以统计服务的每秒请求数、平均响应时间、调用量、峰值时间等，作为服务集群规划、性能调优的参考指标。

基于服务框架Dubbo的服务治理-服务路由

基于服务框架Dubbo的服务治理-服务保护

基于服务总线OSB的服务治理-功能介绍

基于服务总线OSB的服务治理

Q：Dubbo到底是神马？

A：

淘宝开源的高性能和透明化的RPC远程调用服务框架

SOA服务治理方案

Q：Dubbo原理是？

A：

-结束-

相比于传统的网络编程方式，事件驱动能够极大的降低资源占用，增大服务接待能力，并提高网络传输效率。 关于本文提及的服务器模型，搜索网络可以查阅到很多的实现代码，所以，本文将不拘泥于源代码的陈列与分析，而侧重模型的介绍和比较。使用 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 接口的原型：int accept(int s, struct sockaddr 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 接口的原型： FD_ZERO(int fd, fd_set fds) FD_SET(int fd, fd_set fds) FD_ISSET(int fd, fd_set fds) FD_CLR(int fd, fd_set fds) intselect(int nfds, fd_set readfds, fd_set writefds, fd_set exceptfds, struct timeval 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( ) 来启动。void ev_loop( ev_loop loop, int flags ) Libev 支持八种事件类型，其中包括 IO 事件。一个 IO 事件用 ev_io 来表征，并用 ev_io_init() 函数来初始化：void ev_io_init(ev_io io, callback, int fd, int events) 初始化内容包括回调函数 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()。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 事件驱动库的服务器模型。文章对各种模型的优缺点都做了比较，从比较中得出结论，即使用“事件驱动模型”可以的实现更为高效稳定的服务器程序。文中描述的多种模型可以为读者的网络编程提供参考价值。

当前，为推进IT支撑系统集约化建设和运营，进一步发挥集中化能力优势，IT云成为运营商IT支撑系统建设的基础架构。但在IT云资源池部署过程中，服务器技术面临多个新挑战，主要体现在以下3个方面。

在性能方面，人工智能（AI）应用快速扩张，要求IT云采用高性能GPU服务器。AI已在电信业网络覆盖优化、批量投诉定界、异常检测/诊断、业务识别、用户定位等场景规模化应用。AI应用需求的大量出现，要求数据中心部署的服务器具有更好的计算效能、吞吐能力和延迟性能，以传统通用x86服务器为核心的计算平台显得力不从心，GPU服务器因此登上运营商IT建设的历史舞台。

在效率成本方面，IT云部署通用服务器存在弊端，催生定制化整机柜服务器应用需求。在IT云建设过程中，由于业务需求增长快速，IT云资源池扩容压力较大，云资源池中的服务器数量快速递增，上线效率亟需提高。同时，传统通用服务器部署模式周期长、部署密度低的劣势，给数据中心空间、电力、建设成本和高效维护管理都带来了较大的挑战。整机柜服务器成为IT云建设的另一可选方案。

在节能方面，AI等高密度应用场景的快速发展，驱动液冷服务器成为热点。随着AI高密度业务应用的发展，未来数据中心服务器功率将从3kW~5kW向20kW甚至100kW以上规模发展，传统的风冷式服务器制冷系统解决方案已经无法满足制冷需求，液冷服务器成为AI应用场景下的有效解决方案。

GPU服务器技术发展态势及在电信业的应用

GPU服务器技术发展态势

GPU服务器是单指令、多数据处理架构，通过与CPU协同进行工作。从CPU和GPU之间的互联架构进行划分，GPU服务器又可分为基于传统PCIe架构的GPU服务器和基于NVLink架构的GPU服务器两类。GPU服务器具有通用性强、生态系统完善的显著优势，因此牢牢占据了AI基础架构市场的主导地位，国内外主流厂商均推出不同规格的GPU服务器。

GPU服务器在运营商IT云建设中的应用

当前，电信业开始推动GPU服务器在IT云资源池中的应用，省公司现网中已经部署了部分GPU服务器。同时，考虑到GPU成本较高，集团公司层面通过建设统一AI平台，集中化部署一批GPU服务器，形成AI资源优化配置。从技术选型来看，目前运营商IT云资源池采用英伟达、英特尔等厂商相关产品居多。

GPU服务器在IT云应用中取得了良好的效果。在现网部署的GPU服务器中，与训练和推理相关的深度学习应用占主要部分，占比超过70%，支撑的业务包括网络覆盖智能优化、用户智能定位、智能营销、智能稽核等，这些智能应用减少了人工投入成本，提升了工作效率。以智能稽核为例，以往无纸化业务单据的人工稽核平均耗时约48秒/单，而AI稽核平均耗时仅约5秒/单，稽核效率提升达 90%。同时，无纸化业务单据人工稽核成本约15元/单，采用GPU进行AI稽核成本约0048元/单，稽核成本降低达968%。

整机柜服务器发展态势及在电信业的应用

整机柜服务器技术发展态势

整机柜服务器是按照模块化设计思路打造的服务器解决方案，系统架构由机柜、网络、供电、服务器节点、集中散热、集中管理6个子系统组成，是对数据中心服务器设计技术的一次根本性变革。整机柜服务器将供电单元、散热单元池化，通过节约空间来提高部署密度，其部署密度通常可以翻倍。集中供电和散热的设计，使整机柜服务器仅需配置传统机柜式服务器10%的电源数量就可满足供电需要，电源效率可以提升10%以上，且单台服务器的能耗可降低5%。

整机柜服务器在运营商IT云建设中的应用

国内运营商在IT云建设中已经推进了整机柜服务器部署，经过实际应用检验，在如下方面优势明显。

一是工厂预制，交付工时大幅缩短。传统服务器交付效率低，采用整机柜服务器将原来在数据中心现场进行的服务器拆包、上架、布线等工作转移到工厂完成，部署的颗粒度从1台上升到几十台，交付效率大大提升。以一次性交付1500台服务器为例，交付工作量可减少170~210人天，按每天配10人计算，现场交付时间可节省约17~21天。

二是资源池化带来部件数量降低，故障率大幅下降。整机柜服务器通过将供电、制冷等部件资源池化，大幅减少了部件数量，带来故障率的大幅降低。图1比较了32节点整机柜服务器与传统1U、2U服务器机型各自的电源部件数量及在一年内的月度故障率情况。由于32节点整机柜服务器含10个电源部件，而32台1U通用服务器的电源部件为64个，相较而言，整机柜电源部件数减少844%。由于电源部件数量的降低，32节点整机柜服务器相对于32台1U通用服务器的月度故障率也大幅缩减。

三是运维效率提升60%以上。整机柜服务器在工厂预制机柜布线，网络线缆在工厂经过预处理，线缆长度精确匹配，理线简洁，接线方式统一规范，配合运维标签，在运维中可以更方便简洁地对节点实施维护操作，有效降低运维误操作，提升运维效率60%以上，并大幅减少发生故障后的故障恢复时间。

液冷服务器技术发展态势及在电信业的应用

液冷服务器技术发展态势

液冷服务器技术也称为服务器芯片液体冷却技术，采用特种或经特殊处理的液体，直接或近距离间接换热冷却芯片或者IT整体设备，具体包括冷板式冷却、浸没式冷却和喷淋式冷却3种形态。液冷服务器可以针对CPU热岛精确定点冷却，精确控制制冷分配，能真正将高密度部署带到前所未有的更高层级（例如20kW~100kW高密度数据中心），是数据中心节能技术的发展方向之一，3种液冷技术对比如表1所示。

液冷服务器在运营商IT建设中的应用

液冷服务器技术目前在我国仍处于应用初期，产业链尚不完备、设备采购成本偏高、采购渠道少、电子元器件的兼容性低、液冷服务器专用冷却液成本高等问题是液冷服务器尚未大规模推广的重要原因。从液冷服务器在运营商数据中心领域的具体应用案例来看，运营商在IT云资源池规划和建设过程中，通常会对液冷服务器的发展现状、技术成熟度等进行分析论证。

考虑到目前液冷服务器规模化应用尚处于起步阶段，需要3~5年的引入期，因此暂时未在IT云资源池建设中进行大规模落地部署，但在部分地区有小规模应用，如中国移动南方基地数据中心已经开展液冷服务器试点应用，中国联通研究院也在开展边缘数据中心服务器喷淋式液冷系统的开发。未来，随着IT云建设规模、建设密度的继续攀升，以及液冷产业生态体系的逐步成熟，液冷服务器在IT云建设中将有更大的应用空间。

总体来看，运营商IT云资源池建设对服务器计算性能、延迟、吞吐、制冷、定制化、分布式部署等方面都提出了更高要求。未来，GPU服务器、定制化整机柜服务器、液冷服务器等新兴服务器技术将快速迭代，为运营商数据中心服务器技术的发展和演进带来新的思路和路径。

顺序存储方法它是把逻辑上相邻的结点存储在物理位置相邻的存储单元里，结点间的逻辑关系由存储单元的邻接关系来体现，由此得到的存储表示称为顺序存储结构。顺序存储结构是一种最基本的存储表示方法，通常借助于程序设计语言中的数组来实现。

链接存储方法它不要求逻辑上相邻的结点在物理位置上亦相邻，结点间的逻辑关系是由附加的指针字段表示的。由此得到的存储表示称为链式存储结构，链式存储结构通常借助于程序设计语言中的指针类型来实现。

顺序存储和链接存储的基本原理

顺序存储和链接存储是数据的两种最基本的存储结构。

在顺序存储中，每个存储空间含有所存元素本身的信息，元素之间的逻辑关系是通过数组下标位置简单计算出来的线性表的顺序存储，若一个元素存储在对应数组中的下标位置为i，则它的前驱元素在对应数组中的下标位置为i-1，它的后继元素在对应数组中的下标位置为i+1。在链式存储结构中，存储结点不仅含有所存元素本身的信息，而且含有元素之间逻辑关系的信息。

数据的链式存储结构可用链接表来表示。

其中data表示值域，用来存储节点的数值部分。Pl，p2，…，Pill(1n≥1)均为指针域，每个指针域为其对应的后继元素或前驱元素所在结点(以后简称为后继结点或前驱结点)的存储位置。通过结点的指针域(又称为链域)可以访问到对应的后继结点或前驱结点，若一个结点中的某个指针域不需要指向其他结点，则令它的值为空（NULL）。

在数据的顺序存储中，由于每个元素的存储位置都可以通过简单计算得到，所以访问元素的时间都相同；而在数据的链接存储中，由于每个元素的存储位置保存在它的前驱或后继结点中，所以只有当访问到其前驱结点或后继结点后才能够按指针访问到，访问任一元素的时间与该元素结点在链式存储结构中的位置有关。

储存器方面的储存结构

储存系统的层次结构为了解决存储器速度与价格之间的矛盾，出现了存储器的层次结构。

程序的局部性原理

在某一段时间内，CPU频繁访问某一局部的存储器区域，而对此范围外的地址则较少访问的现象就是

程序的局部性原理。层次结构是基于程序的局部性原理的。对大量典型程序运行情况的统计分析得出的结论是：CPU对某些地址的访问在短时间间隔内出现集中分布的倾向。这有利于对存储器实现层次结构。

多级存储体系的组成

目前，大多采用三级存储结构。

即：Cache-主存-辅存，如下图：

3、多级存储系统的性能

考虑由Cache和主存构成的两级存储系统，其性能主要取决于Cache和贮存的存取周期以及访问它们的

次数。（存取周期为: Tc,Tm ;访问次数为: Nc,Nm）

（1）Cache的命中率 H= Nc / (Nc+Nm)

（2）CPU访存的平均时间 Ta= H Tc+ (1-H) Tm

Cache-主存系统的效率

e= Tc / Ta

=1/H+(1-H)Tm/Tc

根据统计分析：Cache的命中率可以达到90%~98%

当Cache的容量为：32KB时，命中率为86%

64KB时，命中率为92%

128KB时，命中率为95%

256KB时，命中率为98%

分布式和集群其实就好像权限或者表的水平切割和垂直切割，集群是一种水平切割来分担压力的形式，分布式就好像一个垂直切割来分担压力一样。分布式必定包含集群。

一、为什么要集群？

1JavaEE项目，如果部署在一台Tomcat上，所有的请求，都由这一台服务器处理，存在很大风险：

A：并发处理能力有限

（一般单台服务器处理的并发量为250左右，超过250，可能会出现数据丢失，链接不稳定的情况）。因为单服务器的性能有限制。所以单台Tomcat的最大连接数有限制，

B：容错率低，一旦服务器故障，整个服务就无法访问了。

eBay于 1999年6月停机22小时的事故，中断了约230万的拍卖，使eBay的股票下降了92个百分点。

C：单台服务器计算能力低，无法完成复杂的海量数据计算。

提高CPU主频和总线带宽是最初提供计算机性能的主要手段。但是这一手段对系统性能的提供是有限的。接着人们通过增加CPU个数和内存容量来提高性能，于是出现了向量机，对称多处理机(SMP)等。但是当CPU的个数超过某一阈值，这些多处理机系统的可扩展性就变的极差。主要瓶颈在于CPU访问内存的带宽并不能随着CPU个数的增加而有效增长。与SMP相反，集群系统的性能随着CPU个数的增加几乎是线性变化的。

使用集群架构完成工作主要有以下几点决定：

1、高性能计算

一些国家重要的计算密集型应用（如天气预报，核试验模拟等），需要计算机有很强的运算处理能力⌄以全世界现有的技术，即使是大型机器，其计算能力也是有限的，很难单独完成此任务。因为计算时间可能会相当长，也许几天，甚至几年或更久。因此，对于这类复杂的计算业务，便使用了计算机集群技术，集中几十上百台，甚至成千上万台计算机进行计算。

2、价格有效性

早期的淘宝，支付宝的数据库等核心系统就是使用上百万元的小型机服务器。后因使用维护成本太高以及扩展设备费用成几何级数翻倍，甚至成为扩展瓶颈，人员维护也十分困难，最终使用PC服务器集群替换之，比如，把数据库系统从小机结合Oracle数据库迁移到MySQL开源数据库结合PC服务器上来。不但成本下降了，扩展和维护也更容易了。

3、可伸缩性

当服务负载，压力增长时，针对集群系统进行较简单的扩展即可满足需求，且不会降低服务质量。

通常情况下，硬件设备若想扩展性能，不得不增加新的CPU和存储器设备，如果加不上去了，就不得不购买更高性能的服务器，就拿我们现在的服务器来讲，可以增加的设备总是有限的。如果采用集群技术，则只需要将新的单个服务器加入现有集群架构中即可，从访问的客户角度来看，系统服务无论是连续性还是性能上都几乎没有变化，系统在不知不觉中完成了升级，加大了访问能力，轻松地实现了扩展。集群系统中的节点数目可以增长到几千乃至上万个，其伸缩性远超过单台超级计算机。

4、高可用性

单一的计算机系统总会面临设备损毁的问题，如CPU，内存，主板，电源，硬盘等，只要一个部件坏掉，这个计算机系统就可能会宕机，无法正常提供服务。在集群系统中，尽管部分硬件和软件还是会发生故障，但整个系统的服务可以是724小时可用的。

集群架构技术可以使得系统在若干硬件设备故障发生时仍可以继续工作，这样就将系统的停机时间减少到了最小。集群系统在提高系统可靠性的同时，也大大减小了系统故障带来的业务损失，目前几乎100%的互联网网站都要求724小时提供服务。

5、透明性

多个独立计算机组成的松耦合集群系统构成一个虚拟服务器。用户或客户端程序访问集群系统时，就像访问一台高性能，高可用的服务器一样，集群中一部分服务器的上线，下线不会中断整个系统服务，这对用户也是透明的。

6、可管理性

整个系统可能在物理上很大，但其实容易管理，就像管理一个单一映像系统一样。在理想状况下，软硬件模块的插入能做到即插即用。

7、可编程性

在集群系统上，容易开发及修改各类应用程序。

蓝海大脑水冷工作站超融合架构承担着计算资源池和分布式存储资源池的作用，极大地简化了数据中心的基础架构，通过软件定义的计算资源虚拟化和分布式存储架构实现无单点故障、无单点瓶颈、弹性扩展、性能线性增长等能力。通过简单方便的统一管理界面，实现对数据中心计算、存储、网络、虚拟化等资源的统一监控、管理和运维。

型号 蓝海大脑水冷服务器

英特尔

处理器 Intel Xeon Gold 6240R 24C/48T,24GHz,3575MB,DDR4 2933,Turbo,HT,165W1TB

Intel Xeon Gold 6258R 28C/56T,27GHz,3855MB,DDR4 2933,Turbo,HT,205W1TB

Intel Xeon W-3265 24C/48T 27GHz 33MB 205W DDR4 2933 1TB

Intel Xeon Platinum 8280 28C/56T 27GHz 385MB,DDR4 2933,Turbo,HT 205W 1TB

Intel Xeon Platinum 9242 48C/96T 38GHz 715MB L2,DDR4 3200,HT 350W 1TB

Intel Xeon Platinum 9282 56C/112T 38GHz 715MB L2,DDR4 3200,HT 400W 1TB

AMD

处理器 AMD锐龙Threadripper Pro 3945WX 40GHz/12核/64M/3200/280W

AMD锐龙Threadripper Pro 3955WX 39GHz/16核/64M/3200/280W

AMD锐龙Threadripper Pro 3975WX 35GHz/32核/128M/3200/280W

AMD锐龙Threadripper Pro 3995WX 27GHz/64核/256M/3200/280W

AMD锐龙Threadripper Pro 5945WX 41G 12核/64M/3200/280W

AMD锐龙Threadripper Pro 5955WX 40G 16核/64M/3200/280W

AMD锐龙Threadripper Pro 5965WX 38G 24核/128M/3200/280W

AMD锐龙Threadripper Pro 5975WX 36G 32核/128M/3200/280W

AMD锐龙Threadripper Pro 5995WX 27G 64核/256M/3200/280W

显卡 NVIDIA A100×4, NVIDIA GV100×4

NVIDIA RTX 3090×4, NVIDIA RTX 3090TI×4,

NVIDIA RTX 8000×4, NVIDIA RTX A6000×4,

NVIDIA Quadro P2000×4,NVIDIA Quadro P2200×4

硬盘 NVMe2 SSD: 512GB，1TB； M2 PCIe - Solid State Drive (SSD),

SATA SSD: 1024TB, 2048TB, 5120TB

SAS:10000rpm&15000rpm,600GB,12TGB,18TB

HDD : 1TB，2TB,4TB,6TB,10TB

外形规格 立式机箱

210尺寸mm（高深宽) : 726 x 616 x 266

210A尺寸mm（高深宽) : 666 x 626 x 290

210B尺寸mm（高深宽) : 697 x 692 x 306

声卡：71通道田声卡

机柜安装 : 前置机柜面板或倒轨（可选）

电源 功率 : 1300W×2; 2000W×1

软件环境 可预装 CUDA、Driver、Cudnn、NCCL、TensorRT、Python、Opencv 等底层加速库、选装 Tensorflow、Caffe、Pytorch、MXnet 等深度学习框架。

前置接口 USB32 GEN2 Type-C×4

指承灯电和硬盘LED

灵动扩展区 : 29合1读卡器，eSATA，1394，PCIe接口（可选）

读卡器 : 9合1SD读卡器（可选）

模拟音频 : 立体声、麦克风

后置接口 PS2接口 : 可选

串行接口 : 可选

USB32 GEN2 Type-C×2

网络接口 : 双万兆 (RJ45)

IEEE 1394 : 扩展卡口

模拟音频 : 集成声卡 3口

连接线 专用屏蔽电缆（信号电缆和电源电缆）

资料袋 使用手册、光盘1张、机械键盘、鼠标、装箱单、产品合格证等