模块化云服务器架构的安全性挑战和缓解措施 (模块化平台)

随着云计算的普及，模块化云服务器架构越来越受到欢迎。模块化架构将云服务器分解成更小的模块，使其更易于管理和扩展。这种架构也带来了一些新的安全性挑战。本文将讨论模块化云服务器架构的安全性挑战，并提出相应的缓解措施。

安全性挑战

1. 攻击面扩大：模块化架构将云服务器分解成更小的模块，增加了攻击面。攻击者可以针对这些模块中的任何一个发起攻击。
2. 模块隔离不当：如果模块之间隔离不当，攻击者可以利用一个模块的漏洞来访问其他模块。这可能会导致敏感数据的泄露或云服务器的控制权被夺取。
3. 供应链攻击：模块化架构依赖于第三方模块。如果这些模块被恶意软件感染，攻击者可以利用它们来破坏云服务器。
4. 微服务通信不安全：模块化架构中的微服务经常需要相互通信。如果这些通信不安全，攻击者可以截取或篡改数据。
5. 容器安全：模块化架构通常使用容器来隔离和部署模块。容器自身也可能存在安全漏洞，攻击者可以利用这些漏洞来攻击云服务器。

缓解措施

针对模块化云服务器架构的安全性挑战，我们可以采取以下缓解措施：

1. 缩小攻击面：部署尽可能少的模块，并确保仅启用必要的服务。这将减少攻击者可以利用的潜在攻击面。
2. 加强模块隔离：确保模块之间通过网络隔离或防火墙进行严格隔离。这将阻止攻击者从一个模块跳到另一个模块。
3. 验证第三方模块：从信誉良好的供应商处下载模块，并在部署前验证其完整性。这将降低供应链攻击的风险。
4. 保护微服务通信：使用加密协议（如 TLS）来保护微服务之间的通信。这将防止攻击者截取或篡改数据。
5. 确保容器安全：使用安全容器映像，并定期更新和修补容器。这将降低容器安全漏洞被利用的可能性。

结论

模块化云服务器架构虽然带来了许多优势，但也带来了新的安全性挑战。通过遵循本文中概述的缓解措施，我们可以降低这些挑战的风险，并确保模块化云服务器架构的安全。

数据中心服务器技术发展趋势与应用

当前，为推进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%。

同时，无纸化业务单据人工稽核成本约1.5元/单，采用GPU进行AI稽核成本约0.048元/单，稽核成本降低达96.8%。

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

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

整机柜服务器是按照模块化设计思路打造的服务器解决方案，系统架构由机柜、网络、供电、服务器节点、集中散热、集中管理6个子系统组成，是对数据中心服务器设计技术的一次根本性变革。

整机柜服务器将供电单元、散热单元池化，通过节约空间来提高部署密度，其部署密度通常可以翻倍。

集中供电和散热的设计，使整机柜服务器仅需配置传统机柜式服务器10%的电源数量就可满足供电需要，电源效率可以提升10%以上，且单台服务器的能耗可降低5%。

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

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

一是工厂预制，交付工时大幅缩短。

传统服务器交付效率低，采用整机柜服务器将原来在数据中心现场进行的服务器拆包、上架、布线等工作转移到工厂完成，部署的颗粒度从1台上升到几十台，交付效率大大提升。

以一次性交付1500台服务器为例，交付工作量可减少170~210人天，按每天配10人计算，现场交付时间可节省约17~21天。

二是资源池化带来部件数量降低，故障率大幅下降。

整机柜服务器通过将供电、制冷等部件资源池化，大幅减少了部件数量，带来故障率的大幅降低。

图1比较了32节点整机柜服务器与传统1U、2U服务器机型各自的电源部件数量及在一年内的月度故障率情况。

由于32节点整机柜服务器含10个电源部件，而32台1U通用服务器的电源部件为64个，相较而言，整机柜电源部件数减少84.4%。

由于电源部件数量的降低，32节点整机柜服务器相对于32台1U通用服务器的月度故障率也大幅缩减。

三是运维效率提升60%以上。

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

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

液冷服务器技术发展态势

液冷服务器技术也称为服务器芯片液体冷却技术，采用特种或经特殊处理的液体，直接或近距离间接换热冷却芯片或者IT整体设备，具体包括冷板式冷却、浸没式冷却和喷淋式冷却3种形态。

液冷服务器可以针对CPU热岛精确定点冷却，精确控制制冷分配，能真正将高密度部署带到前所未有的更高层级（例如20kW~100kW高密度数据中心），是数据中心节能技术的发展方向之一，3种液冷技术对比如表1所示。

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

液冷服务器技术目前在我国仍处于应用初期，产业链尚不完备、设备采购成本偏高、采购渠道少、电子元器件的兼容性低、液冷服务器专用冷却液成本高等问题是液冷服务器尚未大规模推广的重要原因。

从液冷服务器在运营商数据中心领域的具体应用案例来看，运营商在IT云资源池规划和建设过程中，通常会对液冷服务器的发展现状、技术成熟度等进行分析论证。

考虑到目前液冷服务器规模化应用尚处于起步阶段，需要3~5年的引入期，因此暂时未在IT云资源池建设中进行大规模落地部署，但在部分地区有小规模应用，如中国移动南方基地数据中心已经开展液冷服务器试点应用，中国联通研究院也在开展边缘数据中心服务器喷淋式液冷系统的开发。

未来，随着IT云建设规模、建设密度的继续攀升，以及液冷产业生态体系的逐步成熟，液冷服务器在IT云建设中将有更大的应用空间。

总体来看，运营商IT云资源池建设对服务器计算性能、延迟、吞吐、制冷、定制化、分布式部署等方面都提出了更高要求。

未来，GPU服务器、定制化整机柜服务器、液冷服务器等新兴服务器技术将快速迭代，为运营商数据中心服务器技术的发展和演进带来新的思路和路径。

360核心安全大脑，将17年积累的安全能力直达用户

17年安全积累，360核心安全大脑正式发布，共享安全能力在数字化进程不断深入的今天，安全挑战日益凸显。

360核心安全大脑3.0的发布，旨在为政企用户和业界厂商提供全面、强大的安全解决方案。

高瀚昭解释，此大脑是云端安全大脑的私有化部署，构建政企用户的“能力中枢平台”。

推出这一产品是基于用户对整合安全能力的强烈需求。

在安全体系建设中，普遍存在企业设备各自为战、生态产品难以联动、外部能力无法融合的问题。

这严重限制了政企用户整体应对威胁的能力。

360核心安全大脑通过提供单一平台，实现企业产品、厂商产品、外部安全能力与内部安全能力的体系化、实战化协同，显著提高安全风险的识别、保护、检测、响应和恢复能力。

具体而言，360核心安全大脑3.0能够整合安全大数据、攻防对抗知识库、威胁情报等资源，帮助用户实现网络安全产品的信息共享，通过大数据集中分析研判，赋能各个产品，实现体系化联动和协同。

同时，它允许业界厂商基于此平台进行二次开发，建设自身安全分析能力体系，并与360现有安全体系框架互联互通。

360核心安全大脑的优势在于其丰富的大数据资源、多年的实战攻防经验和高效的云端分析能力。

它包括一个安全大数据平台、一个云端赋能平台以及多个安全分析引擎，以及内嵌17年经验积累的实战方法论。

通过提供从数据接入到存储、清洗到运算、最终到图表展示的全生命周期一站式服务，该平台显著提升了数据处理效率和安全运营效率。

360核心安全大脑的安全大数据平台不仅数据量大、更新及时，且兼容面广、处理速度快，能够接入市场主流设备和系统的数据，提供从漏洞到资产、从情报到知识、从线索到规则、从事件到态势的百余种基础安全数据及分析能力。

此外，内置的全景攻防知识框架和安全分析引擎，能够为用户基于已知威胁对抗未知威胁提供明确的行动指导，并针对不同安全场景进行模块化灵活组合，实现与各种安全设备的协同联动。

360核心安全大脑作为赋能者，旨在促进安全行业的协作，让细分赛道的厂商专注于自身领域，无需额外开发大数据平台，避免重复投入和恶性竞争。

通过统一标准API，第三方安全厂商可以开发联动接口，实现与不同安全设备的协同防御。

360核心安全大脑处于数字化安全能力体系的中枢位置，致力于将安全能力打通、优化，赋能企业到国家的网络安全防线。

在未来，它将更好地连接云端和本地、产品和产品之间、厂商和厂商之间的桥梁，为各行各业的数字化转型提供保障，推动国家数字经济的稳健发展。

阿里微服务框架dubbo(阿里的微服务框架)

Dubbo分布式服务框架介绍

随着业务的发展、用户量的增长、系统并发访问需求越来越大，系统数量增多，调用依赖关系也变得复杂，为了确保系统高可用、高并发的要求，系统的架构也从单体时代慢慢迁移至服务SOA时代，根据不同服务对系统资源的要求不同，我们可以更合理的配置系统资源，使系统资源利用率最大化。

而Dubbo则是SOA服务化治理方案的一个核心框架。

Dubbo作为阿里巴巴内部的SOA服务化治理方案的核心框架，在2012年时已经每天为2000+个服务提供3,000,000,000+次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点。

Dubbo自2011年开源后，已被许多非阿里系公司使用，其中既有当当网、网易考拉等互联网公司，也有中国人寿、青岛海尔等传统企业。

Dubbo是一个高性能服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案，使得应用可通过高性能RPC实现服务的输出和输入功能，和Spring框架可以无缝集成。

作为一个分布式服务框架，以及SOA治理方案，Dubbo其功能主要包括：

Dubbo最大的特点是按照分层架构思维构建应用服务，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。

从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。

Dubbo包含远程通讯、服务集群和服务发现与注册三个核心部分。

提供透明化的远程方法调用，实现像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。

同时具备软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。

可以实现服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

Dubbo服务组件调用关秕说明：

Dubbo框架设计一共划分了10个层，而最上面的Service层是留给实际想要使用Dubbo开发分布式服务的开发者实现业务逻辑的接口层。

图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口，位于中轴线上的为双方都用到的接口。

下面，结合Dubbo官方文档，我们分别理解一下框架分层架构中，各个层次的设计要点：

从上图可以看出，Dubbo对于服务提供方和服务消费方，从框架的10层中分别提供了各自需要关心和扩展的接口，构建整个服务生态系统（服务提供方和服务消费方本身就是一个以服务为中心的）。

根据官方提供的，对于上述各层之间关系的描述，如下所示：

Dubbo协议

Dubbo是Alibaba开源的分布式服务框架远程调用框架，在网络间传输数据，就需要通信协议和序列化。

Dubbo支持dubbo、rmi、hessian、http、webservice、thrift、redis等多种协议，但是Dubbo官网是推荐我们使用Dubbo协议的，默认也是用的dubbo协议。

先介绍几种常见的协议：

缺省协议，使用基于mina1.1.7+hessian3.2.1的tbremoting交互。

连接个数：单连接

连接方式：长连接

传输协议：TCP

传输方式：NIO异步传输

序列化：Hessian二进制序列化

适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用dubbo协议传输大文件或超大字符串。

适用场景：常规远程服务方法调用

1、dubbo默认采用dubbo协议，dubbo协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况

2、他不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低。

配置如下：

dubbo:protocolname=dubboport=/

dubbo:protocolname=“dubbo”port=“9090”server=“netty”client=“netty”codec=“dubbo”

serialization=“hessian2”charset=“UTF-8”threadpool=“fixed”threads=“100”queues=“0”iothreads=“9”

buffer=“8192”accepts=“1000”payload=“”/

3、Dubbo协议缺省每服务每提供者每消费者使用单一长连接，如果数据量较大，可以使用多个连接。

dubbo:protocolname=dubboconnections=2/

4、为防止被大量连接撑挂，可在服务提供方限制大接收连接数，以实现服务提供方自我保护

dubbo:protocolname=dubboaccepts=1000/

Java标准的远程调用协议。

连接个数：多连接

连接方式：短连接

传输协议：TCP

传输方式：同步传输

序列化：Java标准二进制序列化

适用范围：传入传出参数数据包大小混合，消费者与提供者个数差不多，可传文件。

适用场景：常规远程服务方法调用，与原生RMI服务互操作

RMI协议采用JDK标准的.*实现，采用阻塞式短连接和JDK标准序列化方式。

基于Hessian的远程调用协议。

连接个数：多连接

连接方式：短连接

传输协议：HTTP

传输方式：同步传输

序列化：表单序列化

适用范围：传入传出参数数据包大小混合，提供者比消费者个数多，可用浏览器查看，可用表单或URL传入参数，暂不支持传文件。

适用场景：需同时给应用程序和浏览器JS使用的服务。

1、Hessian协议用于集成Hessian的服务，Hessian底层采用Http通讯，采用Servlet暴露服务，Dubbo缺省内嵌Jetty作为服务器实现。

2、Hessian是Caucho开源的一个RPC框架：，其通讯效率高于WebService和Java自带的序列化。

基于http表单的远程调用协议。参见：[HTTP协议使用说明]

连接个数：多连接

连接方式：短连接

传输协议：HTTP

传输方式：同步传输

序列化：表单序列化

适用范围：传入传出参数数据包大小混合，提供者比消费者个数多，可用浏览器查看，可用表单或URL传入参数，暂不支持传文件。

适用场景：需同时给应用程序和浏览器JS使用的服务。

基于WebService的远程调用协议。

连接个数：多连接

连接方式：短连接

传输协议：HTTP

传输方式：同步传输

序列化：SOAP文本序列化

适用场景：系统集成，跨语言调用

序列化是将一个对象变成一个二进制流就是序列化，反序列化是将二进制流转换成对象

为什么要序列化？

Dubbo序列化支持java、compactedjava、nativejava、fastjson、dubbo、fst、hessian2、kryo，其中默认hessian2。

其中java、compactedjava、nativejava属于原生java的序列化。

hessian2序列化：hessian是一种跨语言的高效二进制序列化方式。

但这里实际不是原生的hessian2序列化，而是阿里修改过的，它是dubboRPC默认启用的序列化方式。

json序列化：目前有两种实现，一种是采用的阿里的fastjson库，另一种是采用dubbo中自己实现的简单json库，但其实现都不是特别成熟，而且json这种文本序列化性能一般不如上面两种二进制序列化。

java序列化：主要是采用JDK自带的Java序列化实现，性能很不理想。

阿里研发后开源，Dubbo成Apache基金会顶级项目

近日，基于Java的开源远程过程调用框架ApacheDubbo正在逐渐从Apache孵化器升级到顶级项目（TLP）。

该项目最初是由阿里开发的，并于2011年开源。

它于去年年初进入了Apache孵化器。

Apache软件基金会表示，Dubbo框架可以指定可跨分布式或微服务系统远程调用的方法，其主要功能是：基于接口的远程调用；容错和负载均衡；自动服务注册和发现。

最近加入TLP排名的其他项目包括基于标准的客户数据平台ApacheUnom和用于创建和管理大数据的可扩展工作流自动化和调度系统ApacheAirflow。

dubbo和eureka的区别

dubbo和springcloud区别是：

1、初始定位不同：

SpringCloud定位为微服务架构下的一站式解决方案；Dubbo是SOA时代的产物，它的关注点主要在于服务的调用和治理。

2、生态环境不同：

SpringCloud依托于Spring平台，具备更加完善的生态体系；而Dubbo一开始只是做RPC远程调用，生态相对匮乏，现在逐渐丰富起来。

3、调用方式：

SpringCloud是采用Http协议做远程调用，接口一般是Rest风格，比较灵活；Dubbo是采用Dubbo协议，接口一般是Java的Service接口，格式固定。

但调用时采用Netty的NIO方式，性能较好。

4、组件差异：

例如SpringCloud注册中心一般用Eureka，而Dubbo用的Zookeeper，SpringCloud生态丰富，功能完善，更像是品牌机，Dubbo则相对灵活，可定制性强，更像是组装机。

5、SpringCloud：

Spring公司开源的微服务框架，SpirngCloud定位为微服务架构下的一站式解决方案。

阿里巴巴开源的RPC框架，Dubbo是SOA时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。

两者的生态对比：

1、SpringCloud的功能很明显比Dubbo更加强大，涵盖面更广，而且作为Spring的旗舰项目，它也能够与SpringFramework、SpringBoot、SpringData、SpringBatch等其他Spring项目完美融合，这些对于微服务而言是至关重要的。

2、使用Dubbo构建的微服务架构就像组装电脑，各环节选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心。

3、而SpringCloud就像品牌机，在SpringSource的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础原理有足够的了解。

目前比较流程的微服务开发框架是?

SpringBoot的设计目的是简化新Spring应用初始搭建以及开发过程，2017年有64.4%的受访者决定使用SpringBoot，可以说是最受欢迎的微服务开发框架。

利用SpringBoot开发的便捷度简化分布式系统基础设施的开发，比如像配置中心、注册、负载均衡等方面都可以做到一键启动和一键部署。

SpringCloud是一个系列框架的合计，基于HTTP（s）的RETS服务构建服务体系，SpringCloud能够帮助架构师构建一整套完整的微服务架构技术生态链。

Dubbo是由阿里巴巴开源的分布式服务化治理框架，通过RPC请求方式访问。

Dubbo是在阿里巴巴的电商平台中逐渐探索演进所形成的，经历过复杂业务的高并发挑战，比SpringCloud的开源时间还要早。

目前阿里、京东、当当、携程、去哪等一些企业都在使用Dubbo。

Dropwizard将Java生态系统中各个问题域里最好的组建集成于一身，能够快速打造一个Rest风格的后台，还可以整合Dropwizard核心以外的项目。

国内现在使用Dropwizard还很少，资源也不多，但是与SpringBoot相比，Dropwizard在轻量化上更有优势，同时如果用过Spring，那么基本也会使用SpringBoot。

Akka是一个用Scala编写的库，可以用在有简化编写容错、高可伸缩性的Java和Scala的Actor模型，使用Akka能够实现微服务集群。

.x/Lagom/ReactiveX/Spring5

这四种框架主要用于响应式微服务开发，响应式本身和微服务没有关系，更多用于提升性能上，但是可以和微服务相结合，也可以提升性能。

相关微服务框架

是专门针对模块化微服务架构设计的，是跨平台应用程序开发框架，是微软开发的第一个官方版本。

ServiceFabric是微软开发的一个微服务框架，基于ServiceFabric构建的很多云服务被用在了Azure上。

Surging是基于RPC协议的分布式微服务技术框架，基于而来。

MicrodotFramework用于编写定义服务逻辑代码，不需要解决开发分布式系统的挑战，能够很方便的进行MicrosoftOrleans集成。