在当今数字化时代，网络安全至关重要。为了确保局域网络(LAN)的安全性，开发人员常常需要进行漏洞测试与防护。本文将介绍如何使用C++编程语言开发软件来监控局域网络，并提供实用的指南，以确保网络系统的稳定性和安全性。

1. 漏洞测试

首先，让我们关注漏洞测试。在C++中，可以使用套接字编程来实现网络监控。以下是一个简单的例子，演示如何创建一个基本的套接字连接：

#include <iostream>
#include <winsock2.h>

int main() {
    // 初始化 Winsock
    WSADATA wsaData;
    if (WSAStartup(MAKEWORD(2, 2), &wsaData) != 0) {
        std::cerr << "Failed to initialize Winsock." << std::endl;
        return 1;
    }

    // 创建套接字
    SOCKET serverSocket = socket(AF_INET, SOCK_STREAM, 0);
    if (serverSocket == INVALID_SOCKET) {
        std::cerr << "Failed to create socket." << std::endl;
        WSACleanup();
        return 1;
    }

    // 设置地址信息    sockaddr_in serverAddress;
    serverAddress.sin_family = AF_INET;
    serverAddress.sin_addr.s_addr = INADDR_ANY;
    serverAddress.sin_port = htons(8080);

    // 绑定套接字
    if (bind(serverSocket, (sockaddr*)&serverAddress, sizeof(serverAddress)) == SOCKET_ERROR) {
        std::cerr << "Failed to bind socket." << std::endl;
        closesocket(serverSocket);
        WSACleanup();
        return 1;
    }

    // 监听连接
    listen(serverSocket, SOMAXCONN);
    std::cout << "Waiting for incoming connections..." << std::endl;

    // 其他操作...

    // 关闭套接字
    closesocket(serverSocket);
    WSACleanup();

    return 0;
}

2. 防护

防护是确保系统安全的关键步骤。在C++中，可以使用加密算法来保护数据传输。以下是一个简单的例子，演示如何使用C++中的加密库进行数据加密：

#include <iostream>
#include <crypto++/aes.h>
#include <crypto++/modes.h>

int main() {
    // 初始化 Crypto++
    CryptoPP::AutoSeededRandomPool prng;

    // 设置密钥和初始化向量
    byte key[CryptoPP::AES::DEFAULT_KEYLENGTH], iv[CryptoPP::AES::BLOCKSIZE];
    prng.GenerateBlock(key, sizeof(key));
    prng.GenerateBlock(iv, sizeof(iv));

    // 加密数据
    std::string plaintext = "Hello, VIPShare!";
    std::string ciphertext;

    CryptoPP::AES::Encryption aesEncryption(key, CryptoPP::AES::DEFAULT_KEYLENGTH);
    CryptoPP::CBC_Mode_ExternalCipher::Encryption cbcEncryption(aesEncryption, iv);

    CryptoPP::StreamTransformationFilter encryptor(cbcEncryption, new CryptoPP::StringSink(ciphertext));
    encryptor.Put(reinterpret_cast<const unsigned char*>(plaintext.c_str()), plaintext.length() + 1);
    encryptor.MessageEnd();

    // 其他操作...

    return 0;
}

3. 数据提交到网站

在监控到相关数据后，可以使用HTTP协议将数据自动提交到指定网站。以下是一个简单的例子，演示如何使用C++中的网络库进行HTTP POST请求：

#include <iostream>
#include <cpphttplib/httplib.h>

int main() {
    // 创建 HTTP 客户端
    httplib::Client cli("https://www.vipshare.com");

    // 设置 POST 请求数据
    auto res = cli.Post("/submit_data", "key1=value1&key2=value2", "application/x-www-form-urlencoded");

    if (res && res->status == 200) {
        std::cout << "Data submitted successfully." << std::endl;
    } else {
        std::cerr << "Failed to submit data." << std::endl;
    }

    return 0;
}

通过C++编程语言的实际应用，我们可以有效地监控局域网络，进行漏洞测试与防护。当监控到相关数据时，利用网络库实现数据的自动提交到指定网站，是确保网络系统安全性的重要一环。通过这些实践，我们能够更好地保护局域网络免受潜在威胁。

本文参考自监控局域网络的软件：https://www.vipshare.com

云原生的本质和最终效果

要明白什么是云原生，就要先弄明白云计算是什么有什么问题，云计算将计算资源、网络、存储等基础设施统一管理，通过资源规模化和自动化管理，实现降低资源的成本和提高资源的管理效率，云计算本质上解决的是资源的自动化管理问题，但数字化和信息化的关键在应用，云计算没有解决应用的管理问题，应用的管理和运维是难题，对人依赖度很高，云原生的出现就是为了解决应用的管理问题，应用管理比资源管理复杂很多，涉及到应用开发、应用架构、应用交付和应用运维等应用层的管理，还要配合应用解决资源自动化管理问题，云原生本质就是解决应用的自动化管理问题。

从效果来看，云原生的最终目标是让开发者聚焦自己的业务，业务之外（基础设施、应用架构、应用运维）的事情不用关心，只需要懂业务就能创造出自己想要的应用，并能按需交付客户。

使用 Kubernetes 落地云原生困难重重

当前云原生相关的技术很多，其中最关键是容器、微服务架构、Kubernetes ，他们颠覆式的解决了应用管理自动化问题。

• 容器技术解决了应用打包和部署自动化问题，通过容器打包保证了应用基础环境的一致性，实现了一次打包，处处运行。同时容器可以定义应用运行资源，部署时按需占用资源，实现从应用角度解决资源管理自动化。

• 微服务架构解决了复杂应用的解耦和治理问题，当业务越大越复杂，微服务架构将业务拆分和解耦成多个模块，并通过服务治理实现微服务运行和管理的自动化。

• Kubernetes解决了应用编排和调度自动化问题，它是应用自动化管理最关键的拼图，底层基于容器、SDN、SDS，能实现各类型应用和微服务部署和运维过程自动化。

为了实现应用管理自动化，还有很多云原生相关的技术，像SDN（网络自动化管理）、SDS（存储自动化管理）、Helm（复杂应用交付自动化）、Service Mesh（无侵入扩展服务治理能力）、Monitoring（监控自动化）、Logging（日志自动化）、Tracing（性能分析自动化）、Chaos engineering（容错自动化）、Gateway（网关自动化）、SPIFFE （应用访问安全自动化）等等，这些技术可以跟Kubernetes结合起来使用，解决应用各个运维特征的管理自动化问题。

上面这些技术主要围绕着Kubernetes，所以落地过程主要是Kubernetes落地，Kubernetes落地过程一般分为两部分，Kubernetes的搭建和Kubernetes的使用。对于Kubernetes搭建，基于以上技术自主搭建完整的Kubernetes集群非常复杂，既要学习这些技术还要了解他们的原理，最困难的是要把他们有机的组装起来。不过大多公司有专职的维护工程师，可以抽出大把时间来学习和尝试。或者，选择公有云厂商提供的Kubernetes商业服务，所以，搭建Kubernetes是有路径落地的。

相比搭建Kubernetes，Kubernetes的使用一般是开发人员，开发人员人数众多，使用习惯和学习门槛决定了开发人员的接受度，而云原生平台的使用不仅要改变开发习惯，还要学习很多新技术，落地过程困难重重。

1. 需要学习很多新概念和技术。 云原生相关的技术和概念有很多，光 Kubernetes就有很多新的概念和抽象，像Workload、Pod、Service、Ingress、ConfigMap、PV等，如果要用好还需要学习Kubernetes周边的很多概念和技术。

2. 已有应用需要改造，开发习惯需要改变。 已有的应用要运行在 Kubernetes上，需要会写 Dockerfile 和 YAML，如果要改造成微服务架构，还需要按照框架的SDK改造代码，跟之前的开发习惯会有很大变化。

3. 如何将应用高效交付给客户，Kubernetes及上面这些技术并没有解决。  应用只有交付给客户才能产出价值，当前交付客户的自动化程度不高，Kubernetes并没有解决交付过程自动化的问题。在 To C的场景，业务频繁迭代，交付的频率很高，需要保质保量。在To B场景，交付更加复杂，不同的客户有不同的要求，需要针对不同客户有不同的交付模式，比如SaaS、私有交付、离线交付、个性化交付等，交付也是成本里的大头。

应用抽象模型是云原生可落地的关键（实现思路）

云原生落地的难点在使用，如果能将云原生底层复杂的技术包装成开发者熟悉的应用层属性和动作，开发者就不用学习新的概念和技术；如果能将业务跟运维能力解耦，跟微服务框架解耦，就能实现开发者按需扩展运维能力和切换微服务框架，实现对业务按需赋能；如果能实现根据不同客户类型，自定义交付流程和自动化交付，就能大大降低交付成本，提升客户满意度；当以上三点都能解决，就可以让开发者聚焦在业务本身，业务之外的事情不用关心，有更多精力关注客户价值输出。

基于以上思考，通过应用抽象模型是个解决思路，对应用整体进行包装和抽象，包含应用运行所需的全部运行定义，与底层技术和概念隔离。向上用户不需要再学习和了解系统级概念和技术，应用内部把业务和扩展能力解耦，使用应用级概念开发和管理，需要扩展服务治理、运维、安全等能力时按需开启插件。向下则包装Kubernetes的概念和抽象，屏蔽掉底层基础设施的差异，实现应用抽象模型可以运行在各类基础设施上。

应用抽象模版核心设计在三方面：

1. 应用级抽象

2. 架构充分解耦

3. 使用应用模版交付

应用级抽象能简化理解和使用

应用级抽象是“以应用为核心”的抽象模型，对用户暴露应用级的概念、属性和动作，底层Kubernetes和系统级的概念和技术，要么完全实现自动化，要么包装成应用级的属性和动作。  为了实现灵活的应用编排和自动化调度，Kubernetes 定义了很多概念，提供丰富的扩展机制，并以YAML的方式跟它交互，Kubernetes的这些可编程的体验，对管理和扩展Kubernetes的人来说，是非常好的特性，但对于普通开发者，门槛太高，并且很多概念和技术跟自己开发的业务并没有直接关系，所以对于普通开发者来说需要更加友好的操作体验，不需要学习就能使用。

应用级抽象和Kubernetes概念 粗粒度的对应关系：

应用级抽象并不是要将Kubernetes概念全部隐藏起来，而是对于不同的使用者，职责不同展现不同的交互界面。 对普通开发者职责是开发业务，只需要关心应用级的概念，提供应用级的操作界面。但对于云原生平台的管理人员，除了关心应用级的概念，还要关心Kubernetes的管理和维护，有能力的话还可以扩展平台的能力，所以对于平台管理人员，提供高级的暴露Kubernetes概念的操作界面，或者直接操作Kubernetes也可以管理平台上的应用，通过这种方式也规避了，由于包装概念产生的“黑箱”导致对平台的可观测性和可掌控性不足。

架构充分解耦，根据使用场景按需组合

基于应用级的抽象，应用模型通过标准的Kubernetes API实现跟基础设施的解耦，所有符合标准Kubernetes API 的基础设施都可以实现对接和部署，比如各公有云厂商的Kubernetes实现、K3s、KubeEdge等，通过这样的解耦，开发者只需要关心业务和能力扩展，不用在关心基础设施的差异，对接应用模型的应用不需要改动就能透明部署到公有云、私有云和边缘设备上，实现了应用级多云。

通常在应用里，还会包括一些跟业务无关的功能，他们的作用是为了让应用更好的运行，比如：服务治理、微服务框架、运维工具、安全工具等，这些能力跟应用有强耦合关系的，需要改代码扩展能力，将这部分能力解耦，应用就只需要关注在业务了，而且扩展的能力有很强的复用性，其他应用也需要。

应用中扩展能力的解耦使用 Kubernetes 的 Pod，Pod中包含一个或多个容器，所有容器共享网络、存储，应用运行在一个容器，扩展的能力通过扩展容器的方式运行，通过共享的网络和存储实现了应用和扩展能力的解耦，这种解耦方式对业务完全无侵入，扩展的能力用插件的形式包装，就可以实现应用按需安装和启动插件，根据网络流向和容器启动顺序可以定义几种类型插件：

按照Pod机制实现的插件只能扩展单个业务容器的能力，而要对应用扩展微服务架构能力，需要对每一个业务容器扩展服务治理的插件，这跟Service Mesh的实现机制一致，Service Mesh的Data Plane需要对每个业务容器注入Proxy，对于完整应用就是扩展Service Mesh能力，对完整应用扩展的能力是应用级插件，根据注入Proxy的差异可以支持多种类型的Service Mesh 实现，比如：Istio、Linkerd、Dapr，应用可以按需开启Service Mesh 能力，或更换实现框架。当应用跟微服务架构解耦，每一个业务容器不再受微服务框架和开发语言限制，每个业务容器只需要专注业务本身，业务容器之间也同步实现了解耦。

通过将架构充分的解耦，解耦后的业务、插件、对接多云的能力都能实现随意组合，开发者选择喜欢的开发语言开发业务组件，根据业务契约编排依赖关系，根据服务治理和运行稳定性要求，按需开启Service Mesh插件和其他运维插件，运行的基础设施环境，也根据实际需要自动对接。

应用模版成为能力复用和应用交付的载体

应用模型以应用模版的形式具象化展现和存储，应用由源码、容器镜像和插件拼装而成，然后一键导出成应用模版，应用模版设计主要围绕使用者，让使用者能用起来，让应用交付并产出价值，从而拉动应用的迭代和开发。从使用体验上，应用模版可以一键安装和一键升级，通过“拖拉拽”的方式实现业务拼装。应用模版有很强灵活性，应用模版支持不同颗粒度大小，模版和模版能拼装出新的模版，新的模版还可以持续拼装，颗粒的大小由使用者决定，由使用者赋予它意义。应用模版可以交付到兼容Kubernetes API的分支版本，实现一键安装和升级，或将应用模版存放到应用市场，实现即点即用的效果。

应用模版需要具备四个特点：

• 模块化，可以形成可复用的能力单元，按需拼装使用场景。

• 自治，自给自足，可以独立安装、升级和管理，确保组合的灵活性。

• 可编排，模版和模版可以拼装出新模版，具备无限拼装能力。

• 可发现，通过内部服务和外部服务两种方式体现，可供业务和技术、开发者和其他应用访问。

通过应用模版实现可复用模块和能力的打包。 应用的架构充分解耦后，业务组件和扩展插件理论上可以复制到其他应用中，但直接复制代码或镜像非常低效，而且还有很多运行环境相关的配置需要考虑，将业务组件和扩展插件打包成应用模版，并将应用模版发布到应用市场供其他人使用，可以最大程度实现模块和能力的复用，减少重复造轮子。

通过应用模版实现SaaS、私有化和离线环境的自动化交付，和个性化场景模块拼装。 应用模板中包含应用运行态所需的全部资源，对接到客户运行环境，就可以实现一键安装和运行，屏蔽了客户环境差异，一套产品模版可以交付所有类型客户，对于离线环境，应用模版以文件的形式导出，到客户离线环境再导入运行即可。对于功能需要个性化的场景，利用应用模版对业务模版打包的能力，先拼装已经模块化的能力，然后再定制化开发，新开发的功能，如果可复用还可以继续发布成应用模版，供后续复用。

不懂 Kubernetes 实现云原生的体验

基于以上的设计思路，让开发者专注于业务本身，回到用户效果和价值体现的原点上，不用关心底层复杂的技术和不相关的概念，全面实现应用自动化。

开发应用的体验：

1. 代码无需改动，就能变成云原生应用。 对于新业务或已有业务，代码不需要改动就能将其容器化。不需要懂 docker 、Kubernetes 等技术，就能将应用部署起来，具备云原生应用的全部特性。

2. 业务积木式拼装编排。 可复用的业务模块积累到应用市场，当由新业务需要开发，基于应用市场已经业务模块，通过“拖拉拽”的方式拼装，然后再开发没有的业务能力，当积累的业务模块越多，开发新业务的速度越快。

3. 开箱即用的Service Mesh微服务架构，并可一键更换Service Mesh框架。 不用学习微服务框架的SDK，通过无侵入的方式实现Service Mesh微服务架构，主流的Service Mesh框架以插件的形式存在，需要时开启，如果觉得不好还可以随时更换。

使用应用的体验：

1. 像安装手机 App 一样安装云原生应用。  云原生应用以应用模版的形式存放到应用市场，当对接各种基础设施或云资源，实现应用即点即用或一键安装/升级。

2. 普通开发者不需要学习就能实现应用运维。  通过应用级抽象，普通开发者了解应用级属性就能实现应用运维，并通过插件扩展监控、性能分析、日志、安全等运维能力，应用运维不再需要专用的SRE。

3. 复杂应用一键交付客户环境。 复杂应用发布成应用模版，当客户环境可以联网，对接客户环境一键安装运行，当客户环境不能联网，导出离线应用模版，到客户环境导入并一键安装运行。

实现方案

基于上面的设计思路，我们在Kubernetes基础上实现了Rainbond，并将它开源。Rainbond提供开箱即用的体验，使用简单，不需要懂容器和Kubernetes，支持管理多种Kubernetes集群，提供企业级应用的全生命周期管理。主要功能包括应用开发环境、应用市场、微服务架构、应用交付、应用运维、应用级多云管理等。

随着云计算的普及，越来越多的企业开始将业务应用迁移到云上。然而，如何构建一套完整的云原生 Serverless 平台，依然是一个需要考虑的问题。

Serverless的发展趋势

云计算行业从 IaaS（基础设施即服务）到 PaaS（平台即服务），再到 Serverless（无服务器）的发展，经历了一个逐渐从底层到上层，从IT基础设施提供商到应用开发者的转移的过程。

IaaS 时代，云计算提供商主要提供基础设施服务，包括计算、存储、网络等，用户需要自己搭建运维应用。这个阶段主要面向IT运维人员和企业内部的应用开发团队。

随着 PaaS 的出现，云计算提供商开始提供更高层次的服务，包括开发框架、数据库、消息队列等，用户只需要关注应用开发，无需关心底层设施。这个阶段主要面向应用开发者和创业公司，可以大大提高开发效率和降低成本。

而 Serverless 的出现，则更进一步解放了应用开发者的手脚，将服务器管理交给云计算提供商，应用开发者只需关注业务逻辑的实现，无需关心服务器的管理和维护。Serverless的出现使得应用开发更加灵活和高效，也降低了开发和运维成本，因此受到了越来越多的关注。

总体来看，从IaaS到PaaS再到Serverless的发展，是云计算服务不断向上层抽象和自动化的过程，提高了IT基础设施和应用开发的效率，降低了成本，推动了数字化转型的进程。随着技术和市场的不断变化，未来云计算服务还将不断地向更高层次的抽象和自动化发展。

自建 Serverless 的意义与困境

建设私有化的云原生 Serverless 平台具有重要的意义和必要性。首先，相比于公共云平台，私有化的云原生 Serverless 平台可以更好地满足企业的特定需求，保障数据的安全性和隐私性，同时也能够更好地管理和控制计算资源的分配和利用。其次，随着数字化转型和云原生技术的普及，企业对于 Serverless 架构的需求也越来越大，建设私有化的 Serverless 平台可以更好地满足企业的需求，提高企业的业务效率和运营效果。

然而，建设私有化的云原生 Serverless 平台也具有一定的难点。首先，需要企业拥有一定的技术实力和人才储备，包括云计算、容器、微服务等多种技术的掌握和运用。其次，需要进行系统的架构设计和资源规划，包括容器集群的搭建、网络的配置、存储的规划等。此外，私有化的Serverless平台需要满足高可用、高性能、高安全的要求，需要进行多方面的测试和优化。最后，建设私有化的Serverless平台需要考虑成本的控制和效益的提升，需要综合考虑多种因素，包括硬件设备、软件开发和维护等成本。因此，建设私有化的云原生Serverless平台需要企业在技术、资源、人才和经济等多方面进行全面的规划和考虑，确保平台的稳定性和可持续性。

ServerLess 的特点

目前，Serverless 并没有一个业界统一的标准规范，因为 Serverless 并不是一种具体的技术或架构，而是一种基于云计算的应用运行和部署方式，这种部署方式凸显出开发人员不必关心服务器等基础设施。一般情况下，我们认为一个云原生的 Serverless 平台应该提供以下能力：

1. 弹性伸缩：平台应该支持应用自动扩缩容，以便应对变化的负载和流量。

2. 容器编排：平台应该支持容器编排，以方便管理应用的生命周期和资源分配。

3. 无服务器计算：平台应该支持无服务器计算模式，以提高开发者的效率和降低成本。

4. 自动化运维：平台应该支持自动化运维，包括自动部署、自动扩容、自动恢复等功能。

5. 服务发现与负载均衡：平台应该支持服务发现和负载均衡，以确保应用的高可用性和稳定性。

6. 日志监控和告警：平台应该支持日志监控和告警，以便及时发现和解决应用问题。

7. 安全管理：平台应该支持安全管理，包括身份认证、访问控制、审计服务等功能，以确保应用的安全性和隐私性。

8. 自动化CI/CD：平台应该支持自动化CI/CD，以便实现快速迭代和部署。

9. 多云支持：平台应该支持多云环境，以便应用可以跨多个云平台部署和运行。

如此多的能力要求，为自建云原生 Serverless 平添了不少难度。那么是否可以选择一个开源的方案来完成这个目标呢？

基于 Rainbond 自建

Rainbond 是一款开源的云原生应用管理平台，它可以帮助用户快速构建和管理云原生应用，其很多功能特性都与 Serverless 的无服务器理念不谋而合。Rainbond 提供了一系列的工具和服务，包括应用编排、容器编排、自动化部署、监控告警、应用管理等功能，可以帮助用户实现应用的快速迭代和部署。此外，Rainbond 还支持多语言、多框架、多云环境的部署，用户可以根据自己的需要选择不同的部署方式。

server-1

原生支持多云管理

Rainbond 可以架设在多种不同的云之上，原生支持多云管理。这种多云管理能力可以帮助用户抹平多种不同云计算供应商之间的差异，提供一致的应用部署、应用管理体验。无论是公有云、私有云或混合云，对用户而言都变成透明层，用户的应用可以借助Rainbond提供的能力完成跨云的快速迁移。

server-2

简化应用部署

Rainbond 支持用户部署由不同开发语言开发而来的应用，这个过程不需要用户编写 Dockerfile，不需要了解容器镜像如何打包。被支持的语言类型包括：Java、Python、Golang、PHP、NodeJS、.NetCore以及静态Html语言。用户在操作时仅需要提供代码仓库地址，或者直接上传 Jar、War 包即可将构建任务交给 Rainbond ，后者会自动识别语言类型，并自动配置语言的构建环境与最终运行环境。构建任务完成后，应用会自动运行起来，整个过程不需要用户过多参与。

部署过程中，用户可以自己选择以哪种 Workload 类型来部署应用，Rainbond 除了支持常见的 Deployment、StatefulSet 之外，也支持部署 Job、CronJob 类型的 Workload。

弹性伸缩能力

弹性伸缩能力是 Serverless 场景中最受关注的能力之一，自动化的弹性伸缩能够提升对计算资源的利用率。用户可以借助这种能力，自动化应对业务的峰谷流量。Rainbond 能够根据 CPU/MEM 资源利用情况进行实例数量上的 1-N 自动伸缩，用户仅需要做非常简单的一次设置即可。在更高阶的场景中，Rainbond 能够旁路感知Http业务的平均响应时间、吞吐率等性能指标，并据此实现自动伸缩能力。

微服务能力

Serverless架构与传统的微服务架构类似，都是基于分布式系统的思想，将一个应用拆分成多个小的、相对独立的服务单元来进行开发、部署和管理。而微服务框架可以帮助开发人员更好地设计和开发这些服务单元，提高系统的可维护性、可扩展性和可靠性。Rainbond内置灵活高效的ServiceMesh微服务框架，能够完成跨语言、跨协议、跨架构的微服务编排，并且提供全面的微服务治理、容错机制等能力。

自动化运维

Rainbond提供完善的自动化运维能力，能够极大的解放开发人员。许多应用运维工作都将由平台来接管，包括定时数据备份、健康检测、故障自愈等。

可观测性中心

可扩展的全方位可观测性能力，提供上至应用组件，下至平台的监控视图。全局日志功能与链路追踪能力，能够帮助开发者快速定位问题。实时告警能力，则保证了每一次异常都会得到开发者的关注。

自动CI/CD

Rainbond 能够对接 Git 或 Svn 类型的代码仓库，简化用户创建应用以及配置自动化 Webhook 的流程。开发者仅需要提交一次代码，就可以触动整个CI/CD链条，自动化完成代码更新后的上线。

一键配置网络入口

用户不需要学习复杂的负载均衡配置，仅仅需要一键，就可以开启 L4/L7 的网关策略，将应用的端口对外暴露，平台将会根据要求自动生成 IP:Port 或域名形式的访问地址。

安全管理

平台中采用双因素认证方式保证登录安全，并提供基于 RBAC 的设计方案来确保对应用的权限控制。除此之外，Rainbond 提供全局的操作日志审计功能，保留用户对应用的每一次操作记录。

Rainbond 作为一个开源的云原生应用管理平台，能够帮助企业应对建设私有化的云原生 Serverless 平台的难点。首先，Rainbond 提供了丰富的组件和工具，使得企业可以轻松构建容器集群、微服务架构、CI/CD流水线等，极大地降低了技术门槛。其次，Rainbond 提供了完善的应用管理和监控机制，包括应用部署、服务编排、负载均衡等功能，大大简化了应用开发和运维的工作量，实现了应用管理的自动化和免运维。此外，Rainbond 提供了网关组件，可通过一键即可对外暴露L4/L7层服务，提高了应用的安全性和可访问性。Rainbond 还支持 Job 任务类型或 CrontabJob 定时任务类型，使得企业能够方便地进行定时任务调度。最重要的是，Rainbond 提供了 ServerMesh 微服务框架和内置的应用编排模型，帮助企业轻松实现应用拓扑的编排和管理，实现应用的快速迭代和更新。此外，Rainbond 还能够对接 Git 类型代码仓库，实现自动化 CI/CD 流程，进一步提高了开发效率和运营效果。

写在最后

通过借助 Rainbond 建设私有化的云原生 Serverless 平台，企业能够更好地应对技术难点，提高平台的稳定性和可持续性。同时，Rainbond 还提供了完善的文档和社区支持，帮助企业更好地了解和掌握相关的技术和应用。因此，借助 Rainbond 建设私有化的云原生 Serverless 平台不仅能够解决技术难点，也能够提高企业的开发效率、降低运维成本，是建设私有化 Serverless 平台的理想选择。

在开始讨论私有云的架构之前我们首先确定一件事情，即没有架构是完美的，总是根据实际业务慢慢优化最终满足或者超越最初需求。
私有云客户与公有云客户最大的不同是——客户对私有的“云”在管理层面上拥有较大的权限，他（她）可以很放心地把有涉及到公司或者单位隐私的东西放进“云”中，出现意外时自己可以要求管理员随时处理。并且私有云就服务器规模、SLA、防火墙、计费、安全性等级要求等方面而言，与公有云的侧重点不大相同，架构上自然也要区别对待。

本稳会从基本原则、架构安全、“云”化架构三个方面叙述基础架构的设计实现，涉及到的技术细节笔者尽量在后面的基础知识章节部分加以叙述。

1、基本架构原则

基础设施架构的核心即是整合计算、存储与网络三种资源，而在配置这些时我们需要在扩展性、稳定性及冗余性达到一定要求。

稳定性

基础架构的稳定性对于一个平台是至关重要的。存储、网络、计算节点自身的稳定性，以及它们之间通信的稳定性，都时时刻刻影响着用户体验。

即使是稳定性非常好的系统，也应该在平时的运维，即监控以及出现故障时的跟踪、定位、解决上花一定功夫。现在国内很多云平台厂商都没有提供服务状态报告，比如可用性、地域延迟、资源统计等，相比国外的主流平台而言仍有很大差距。

扩展性

扩展性包含两个方面：横向扩展（scale out/in）和纵向扩展(scale up/down)。
集群横向扩展主要包括计算节点、存储、网络资源“节点级别”的扩展，比如新添加了服务器、交换机等整机设备。需要注意的是，节点加入集群后，其上的所有业务均能在新节点正常运行；同时，新节点的加入对普通用户来说是透明的，即用户不会感知到集群的横向扩展。

纵向扩展即是整机中加入例如新的CPU、内存、硬盘、网卡等组件以提高单机性能。

平台在进行横向扩展时，也可使用其他平台的资源。比如企业内现有国际品牌的虚拟化产品，如果国内厂商的虚拟化产品能够直接使用原平台的虚拟机、虚拟硬盘甚至是虚拟网络的话，那么对企业来说，这个过渡将会非常轻松。现在能够提供云平台API的厂商比较多，而能够作为参考标准的只有Amazon、OpenStack、VMWare等国际化平台。笔者成文时，中国信息技术标准化组织目前尚未制定出“及时”的标准，但已经成立了很多的工作组，比如服务器虚拟化、桌面虚拟化、云存储等，相信他们也很快推出统一标准。

冗余性

冗余性是稳定性和扩展性的补充。对于私有云而言，成本往往仅能保证稳定性，而在冗余性保障上有较少的支出。当成本不足以满足所有基础资源的冗余性的时候，就要根据具体环境来判断，尽量保持它们不同资源上冗余能力的平衡，最大程度地减少潜在风险。

1.1 合理的存储配置

私有云中存储配置是整个架构的重点，它承担着整个平台的数据，所以这里一般需要进行重点配置。除了传统存储架构外，也有厂商Nutanix为首提出的超融合架构，即存储与网络一样也可以进行软件定义。目前对多数国内私有云厂商来说，超融合的一般实现即是在虚拟化平台中添加分布式存储的后端与前端管理，可对计算节点资源进行复用，从而降低项目整体成本。

不管何种形式，它们对平台的提供的功能都是相同的，接下来笔者针对私有云平台的存储基础架构予以介绍，相关的存储知识读者可以阅读本书的第7章。

接入方式

私有云中的存储配置按照接入平台的方式可分为本地存储和共享存储，而它们本身的组合方式又是自由的，除传统的本地存储和网络存储外，也有NFS存储可以挂载后作为计算节点的本地存储，或者计算节点上的空闲空间组合为分布式存储等方法。图2-1和图2-2分别是本地存储与共享存储的接入方式示例，本地存储即直接使用本地磁盘或者iSCSI、SAS等设备作为镜像存储，虚拟机实例与镜像在同一主机中，而共享存储下虚拟机实例可在任意主机中打开镜像并运行，从而使得虚拟机热迁移成为可能。

图2-1本地存储接入示例

图2-2共享存储接入示例

图2-1中有本地硬盘、共享存储/FC/SCSI存储作为本地存储的两种用例；图2-2中节点1直接使用外部存储作为共享存储，节点2和3提供本地硬盘作为Ceph/Glusterfs的存储后端，再使用Ceph/Glusterfs作为共享存储。存储的接入方式对平台性能、稳定性甚至使用体验上都有直接或间接的影响。

当使用共享存储时：

• 虚拟机可以进行在线迁移，合理利用服务器资源，增加业务连续性；

• 计算节点宕机不会造成虚拟机单点故障，提高稳定性；

• 可以更灵活地应用备份机制，并且扩容相对简单，提高可维护性；

• 可与其它业务或者平台共享存储，提高扩展性；

• 存储与计算节点逻辑、物理都分离时，架构清晰；

• 对网络连接路径较为依赖，计算节点增加时可能需要增加线路隔离流量；

• 可以利用网络缓存机制，减轻启动风暴影响，但对共享存储设备有一定要求；

当使用本地存储时：

• 虚拟机更加独立，某个用户的过度使用不会造成其它虚拟机的读写性能影响，增强用户体验；

• 可以利用更高效的本地缓存机制，减轻启动风暴的影响；

• 存储成本投入较小；

• 计算节点宕机时会造成其上所有机器不可访问，即单点故障损失较大，影响平台稳定性；

• 虚拟机在线迁移有难度，难以平衡集群负载；

• 我们选择接入方式时需要综合考虑业务类型、成本、用户体验、风险控制等等各方面因素，尽量避免对整个平台的稳定性和性能造成负面影响。

存储后端

存储后端即平台存储资源的核心，组成部件不止于机械硬盘、SSD，也包括其通信链路、固件等。存储后端性能与其上的虚拟机紧密相关，当选择不当的时候会降低平台整体性能，而导致用户体验不佳。

图2-3 存储节点物理示意图

多数项目方案中既有高速存储设备，又有相对低速的存储设备，我们要根据“业务”来规划存储使用。接下来我们做一次实验，用数据简单说明虚拟机硬盘格式与物理存储的相互影响，其中我们使用一块SSD代表性能较高的高速存储，一块SAS硬盘代表相对低速存储，这里的“业务”是启动链接克隆方式创建的虚拟机并进入桌面。

“完整克隆”与“链接克隆”

在KVM虚拟化平台中，有两种创建实例的常用方式：完整克隆与链接（增量）克隆，在以后章节中会有详细介绍。

完整克隆即完全复制模板配置信息与硬盘文件，硬盘的复制方式一般为cp或者qemu-img convert。如此创建的实例，其硬盘与模板硬盘相对独立，在服务器存储上拥有各自的扇区位置，所以在读写操作时受机械盘磁头引起的小区域并发问题影响 较小，缺点是创建时需要花费一定时间，不能满足秒级创建的需求。

链接克隆即新建虚拟机时只复制模板配置信息，硬盘文件则是以原硬盘为模板的增量硬盘。如此创建的硬盘对模板硬盘的依赖程度较高，对于硬盘内已有文件的读操作（比如启动系统时）绝大部分在模板硬盘上进行，所以在传统机械盘上多个实例的并发启动风暴更容易在此种格式的硬盘上发生。

本次实验环境中，笔者使用一台双路E5-2630v3、128G内存的服务器，两块企业级SSD（其中一块为服务器系统，另一块虚拟机存储）和一块企业级SAS硬盘（虚拟机存储），将1G内存、单核、全新安装的XP虚拟机作为模板。为了防止虚拟机进入系统后进行文件索引等占用空间的操作，模板虚拟机建立之前开机“静置”了一段时间直到其资源用度无明显变化。

• 企业级1T SAS硬盘虚拟机批量启动实验
  此时新建的实例所和模板都位于SAS硬盘上。同时启动20台虚拟机后，全部虚拟机在第300秒左右进入桌面。启动20台虚拟机过程中的服务器CPU及I/O用度如图2-4所示。

图2-4 于SATA硬盘中启动20台虚拟机的CPU及I/O用度

• 企业级480G SSD虚拟机批量启动实验
  此时新建的实例和模板都位于SSD上。同时启动20台虚拟机后，全部虚拟机在第35秒左右进入桌面。启动20台虚拟机过程中的服务器CPU及I/O用度如图2-5所示。

图2-5 于SSD中启动20台虚拟机的CPU及I/O用度

可以看出，高速设备比低速设备拥有更高的IOPS以及更高的读写速度。目前两者成本相差很多，所以全部使用高速存储会增加很多成本。在实际实施中，高速和低速设备搭配使用，比如将高速设备用于存储模板和某些高IOPS虚拟机，低速设备用于存储普通虚拟机，这样从成本和用户体验综合考量，方可获得比较合理的配置。

1.2 稳定的网络基础

一个优秀的IT架构一定有一个优秀的网络基础。网络在私有云尤其是桌面云中的影响有时比存储更加直接。在搭建私有云的过程中，更多的项目是在已有 IT架构的基础上进行延展，而不是厂商独立的架构，所以对整个用户端网络框架有个清晰认识就显得很重要。在我们接触的项目中，有比较多的问题是网络不稳定、框架不合理造成的。虽然我们在项目中极少拥有对用户网络改造的权力，但是也要在网络上下功夫认真规划，并在关键结点与客户及时沟通，尽量减少网络因素带来的诸多“麻烦事”。

图2-6是以业务为核心的通用私有云架构，图2-7则是从计算节点出发网络视图，它们的共同点都是对网络进行了较为严格的区分，但划分标准不同，读者在很多云平台中都会看到类似架构。

图2-6 业务为核心的通用架构

图2-7 计算节点为中心的网络架构

对于构建一个稳定的网络基础来说，传统OSI七层模型很有参考价值，而侧重协议实现的TCP/IP的四层模型也很实用，在此我们使用它们的混合模型来分层讨论。图2-8是OSI网络模型与TCP/IP模型简图。

图2-8 OSI模型与TCP/IP模型

传统OSI在服务、接口、协议有所侧重，但是它由于历史原因以及实现等问题，现在仅仅被人奉为“经典”，具有的参考价值大于实用价值。而 TCP/IP的实现由于其模型简单，很大程度上促进了互联网时代的来临，但是使用它来描述比如说蓝牙网络，基本上是不可能的了。而混合五层模型即吸收了它们的优点，又一定程度上回避了它们的缺点。下图即是混合网络模型简图。

图2-9 OSI与TCP/IP混合模型

同存储资源一样，我们在构建私有云网络基础的时候也要关注其稳定、扩展、冗余的能力，同时注意成本，以下笔者将从这5层分别进行介绍。

物理层

在物理层，我们需要做出的选择有传输介质和有线/无线传输方式。

表2-1 网络线材分类

在后端资源链路中，一般有计算节点、存储之间，计算节点、网络之间，存储、存储之间以及计算、网络、存储的内部通信链路。其数据量或高或低，对于私有云而言可以采取后端全万兆的链路以减少后端对整个平台产生的短板效应。因为对于私有云而言批量启动是会经常出现的，所以至少计算节点与存储的链路一定要有所保证，从而防止网络带宽成为存储能力的制约影响用户体验。

服务器与前端的链路数据根据私有云业务的而异，主要是控制台画面传输、交互（键鼠输入、外设重定向数据、语音等）、文件传输（云存储）等。一般到客户端汇聚层的链路使用千兆双绞线，到客户端使用千兆/百兆双绞线。

数据链路层与网络层

这两层中我们要关注的部分主要是不同层次的交换机/路由配置、IP、VLAN的划分，除非对于完全自主搭建网络的厂商，否则我们只要了解其基本拓扑和路由配置即可。

目前比较主流的网络规划为环网＋星型拓扑，并且按照核心层、汇聚层和接入层区分职责，如下图所示。

图2-10 星型＋环形网络拓扑

其中有几点需要注意：

• 组网的有多种，不同规模可以使用不同的混合拓扑；

• 在私有云的架构中，网络标签更偏向以功能逻辑而不是以地理位置区分。这点在开源云实现中体现的很明显，比如Mirantis OpenStack的
  网络规划以及oVirt的逻辑网络；

• 由于后端资源链路较多，一般情况下会使用VLAN（tagged/untagged）来进行隔离；

• 非核心资源尽量采用DNS＋主机名的方式进行搭建，防止以后IP变化带来的维护困难；

• Bonding（链路聚合）是比较常用的增加冗余和带宽的措施，但要注意交换机关于bonding负载均衡的策略，防止bonding无实际效果，比如IP、MAC、TCP Port的组合方式；

• 交换机尽量采购同一品牌，以免增加运维人员负担；

• 传输层与应用层

我们需要保持网络稳定高效主要是为了这两层，因为它们对用户接入、桌面协议、业务网络、资源网络、控制协议等有直接影响。
其中，从用户端到云平台需要保持良好通信的有http(s)、spice/vnc等，服务器之间则有ssh、sql、telnet、smtp、pop等之间影响业务等应用层协议。

而在传输层中，经常出现的问题有网络拥堵、过载、超时、延迟等问题。比如当一端等交换机或者设备达不到处理大量报文所需的计算能力时，就会导致丢包或者多次重发的现象；当有错误或者恶意报文进行广播时，局域网所有机器都会返回错误包而导致广播风暴；当有大量机器重启从DHCP服务器获取IP时，也会对服务器造成很大负载；报文的超时时间对应用的影响也很大，过低会导致在网络繁忙时大量应用超时，过高会引起传输效率变低从而影响视频等实时应用卡顿。

在设计时我们需要注意以下几点：

• 终端/服务器的带宽要尽量保证不低于直接连接的网络带宽，否则当网络端（有意/无意/恶意）发送大量报文时，会造成服务器网卡处理能力的大幅下降，影响其上的应用性能；

• 适量增加封包大小，减少数据发送次数，从而降低网卡负担；

• 适量调整报文超时时间，减少网络繁忙时产生拥堵；

• 在可以压缩协传输层议头甚至数据的条件下优先压缩协议头，从而减少报文传输次数降低流量；

总之，私有云网络设计与传统网络架构设计相比，需要考虑的变量更多。尤其近些年软件定义网络的发展，以及OpenStack、VMWare中网络虚拟化的推进，客户对私有云/公有云对厂商的综合素质要求更高了。

1.3 可靠的计算资源

提供考量计算资源的标准，不止于物理服务器的性能、安全、稳定等因素，还有计算节点组成的集群所具有的能力，比如负载均衡、高可用等。接下来，笔者将根据硬件、软件配置并结合私有云的特性进行计算资源服务器的选择，以其达到最优的计算资源配置。

服务器硬件

图2-11 PC服务器一般架构

通常情况下，CPU、内存是决定服务器能够承担多少负载的决定性因素，而存储、NUMA和扩展属性保证着服务器运行的功能性和稳定性。
多数厂商在部署私有云时，往往按照CPU逻辑核总数和虚拟机总核数按 1:X 来分配，当虚拟机有卡顿或者其它情况出现时，再调整比例。而这一点在笔者看来是很不好的习惯，因为它忽略了一些因素，比如CPU最大主频、非NUMA核间数据拷贝代价、虚拟机运行程序时的保证峰值负载等。我们在此使用一个经验公式来计算：

其中，sockets、cores、frequency分别代表服务器的物理CPU数量、单CPU线程数、最大主频，当超线程HT打开（为真）时获得20%的提升，否则不提升，cap代表服务器的能力。读者可以访问Intel ARK网站（或手机APP）查询具体的CPU参数。

假设一个Windows 7桌面普通办公流畅的最小负载为2.0Ghz，使用双路Intel E5-2630 v3，则cap为61.44GHz，即我们这台服务器可以保障30台单核Windows 7桌面流畅运行。由于桌面应用程序往往可以利用多核特性，所以我们会考虑分配其双核甚至四核，同时其单核负载下降，亦可以看做2 * 1 Ghz，加之峰值负载下的机器并发量少，我们可以再适当增加虚拟机数量。在选配CPU时，我们要根据实际负载、桌面应用、成本等因素综合考量，尽量减少 CPU性能的瓶颈或者过剩。

NUMA技术和主板CPU省电选项（C1E等）同样也会影响服务器CPU性能。NUMA技术会大幅提高CPU间通信，换句话说，当有较多进程存在时，利用 NUMA可以减少进程在CPU之间切换的时间，一般建议打开。对于高I/O、低CPU利用率的应用，主板使用C1E或者更深度的电源管理选项（C1/C3 /C6）时会较大程度地影响其性能。目前在KVM中，缺少C1E动态开关的选项，所以建议在BIOS设置中关闭此项。

内存技术也是影响虚拟机的重要因素，目前在KVM中可以使用内存气球、巨页、KSM等技术提高内存使用效率。虽然内存可以超分（overcommit），但我们仍然要保证物理内存不小于所有虚拟机分配内存，因为内存不足导致的问题一般比较严重，对于服务器来说甚然。另外，当内存充足时建议关闭swap分区，因为在数据拷贝期间发生交换将带来比较严重的性能损失。

计算节点的硬盘配置可分为系统盘和数据盘，系统盘即运行虚拟化节点所需操作系统的硬盘，数据盘即用于本地存储或者共享存储的硬盘。当采用共享存储时，可以省去服务器数据盘配置。

扩展插槽中可以添加RAID控制器、JBOD控制器、GPU卡、网卡等高速设备。而USB控制器则用于加密狗、U-Key透传等功能。这两项外设扩展在特定的服务器中可以进行额外扩展。

操作系统

计算资源的操作系统首先要做到效率高、稳定性好、兼容性好，其次是无状态、易维护等。

在效率上我们能进行很多比较系统的优化，比较通用的有进程调度、驱动程序优化、I/O优化等。通用的优化做好以后就可能需要对具体硬件进行针对性的驱动、调度优化。通用的优化是可移植的，而针对具体硬件的优化难以保证，所以我们在这两方面应有所取舍。

稳定性是考量系统的重要标准之一，影响它的因素或是系统本身，或是软件，或是硬件。一般私有云厂商在进行实施之前，如有可能会对服务器进行连续中低压测试，确保其稳定性后再进行软件的部署。而服务器硬件兼容性问题伴随着硬件厂商和操作系统厂商（尤其RedHat）的紧密合作，它的出现情况已经比较少了。但是一旦出现兼容性问题，一般都比较难以排查，往往需要硬件厂商提供协助。

所谓无状态操作系统，即我们需要这个计算节点异常断电重启后无需人工干预继续提供服务。它提供了一种类似还原模式的操作系统，降低了系统损坏后难以修复的几率同时减少了运维负担。其实现方式比较多，包括DOM盘、PXE、SQUASHFS等。

至于易维护性的对象，主要针对服务器的状态监视、系统软件修复/升级。

操作系统的选择

目前主流云平台多基于CentOS/RHEL或者Ubuntu系统。其主要原因就是其生命周期与知识库——CentOS每个大版本是10年左右，Ubuntu/Debian为5年，SUSE为10+3年（期限虽长但对应云平台知识库较少）。当然，影响我们对服务器选择的因素中，软件也占据大部分，比如下图就是虚拟化相关软件的通用架构，其中哪部分使用或高或低配置的服务器甚至虚拟机作服务器还是要调研一番更为妥当。

软件服务

在分布式架构中，不同的软件服务一般部署在不同的服务器上，这样就会使单独的软件服务模块更具可维护性和部分性能上的优势。以IaaS为例，常用的软件服务模块如图2-12所示。

图2-12 开源云平台虚拟化相关功能软件架构

首先，模拟器会对计算节点的CPU特征有一定要求。以虚拟机迁移为例，现在的虚拟化实现不能进行异构迁移，即虚拟机vCPU不能在迁移后改变其CPU特征，这就要求集群中的计算节点使用统一的CPU特征组启动模拟器，并且所有计算节点的的CPU至少属于同一架构。其次，模拟器会对计算节点的CPU性能有一定要求。私有云中常常会有重点业务虚拟机，它们对CPU性能、内存等计算资源有较高要求，此时我们就需要赋予较高资源优先级，保证它们在资源充裕且状态良好的计算节点上运行。然后，如果虚拟机需要使用常驻的外部设备，那么我们就需要进行设备透传或重定向。而现有的模拟器实现不能在设备已与虚拟机连接的情况下进行迁移，这就只能将此虚拟机在固定的计算节点上运行，从而要求此计算节点需要拥有数量合适的外部设备或接口。最后，某些模拟器的性能会受主板设置的影响，比如CPU电源管理，这就要求计算节点需要针对具体的模拟器类型作出相应设置，保证模拟器性能最优。

需要注意的是集群中的网络组件，以Neutron为例，其OVS节点在网络数据包较多的情况下，会对本地CPU造成不小的压力从而引起网络丢包、延迟现象，而针对这点常用的做法是使用单独的网络控制节点和SDN交换机以分离控制层与数据层，从而保障网络性能的稳定。

至于容器，它运行在Linux服务器中时一般不会对CPU有特殊要求，只要保证核数与主频合适即可。而集群组件，比如Nova、Glance、vdsm等，它们对计算资源要求也比较少。

2、架构安全

当人们讨论安全时，首先想到的可能就是一个复杂的密码，还有不同网站使用不同的密码。作为被各种网站注册页面包围的现代人来说，这是一个好习惯。其实，对一个面向终端用户的系统而言，密码只是它复杂又精密的安全机制体现之一。一个系统安全机制实现的复杂度直接关系到用户数据的安全保障程度，它始终以用户数据为核心，以保障系统自身安全的条件下保障用户数据的安全性，图2-13是私有云环境下的用户接入视图。

图2-13 私有云环境用户接入简图

2.1 认证与授权

认证（authentication）与授权（authorization）历来是安全系统重点关注的部分，即使在现实生活中也是这样。认证是发生在用户进入系统时，而授权是在对系统进行操作的过程中。

在传统认证授权系统中，普遍使用AD、LDAP等作为网络信息服务器（NIS），前者是类Kerberos的实现，后者可直接与Kerberos进行结合。私有云需要这种NIS访问方式，以便接入现有业务系统或者启用单点登录（Single Sign On）。Kerberos的认证流程如图2-14所示，其核心是ticket的获取与授权。

图2-14 Kerberos认证过程

可以看到用户与服务的认证授权过程很清晰，实现时注意需要用户/服务端/KDC（相当于AD域控）三者时钟同步。当用户进行登录以后，他使用任何应用都不再需要再次输入密码认证，应用程序通过用户第一次获取的key向服务请求对应的权限，并且所有权限都可以进行细分管理。
虽然Kerberos性能、安全性方面都很优秀，但与应用结合时仍需考虑它引入的运维复杂度问题，尤其是在扩展性方面。

2.2 服务安全

对于用户来说，将数据保存在一个放心的环境里能很大程度上减少他们的担心。对于管理员来说，一旦被入侵，那么损失的不止是用户数据了，更有可能丧失用户对整个平台的信任。接下来我们从三个方面来增加我们服务器安全性。

网络安全

网络安全是我们第一个要考虑的事情。从功能上我们将网络划分为用户接入端网络、传输网络、后端网络。我们很难保证用户接入端网络的安全性，所以普遍做法是在传输网络与后端网络上实施安全防护措施，包括加密传输、防DDoS/CC攻击、流量限制等。在私有云环境中，不仅要对外网入口进行防护，更要对局域网进行监控和防护，我们要采取一定措施进行区分。

加密传输

在私有云平台中，所有服务的TCP/IP连接都可以选择性地使用SSL/TSL进行加密。而在进行SSL/TSL加密传输时，有两点需要注意：确保至少有一个可信的根证书颁发机构颁发的根证书，对于小规模私有云来说，可以使用二级可信证书或者自建可信域；谨慎管理私钥及其备份，防止外泄。

防DDoS/CC/SQL注入

整个平台给用户提供的接入方式很可能是一个Web界面，或者REST API的接口，那么就会与传统Web服务器一样面临着被攻击的威胁。和传统服务一样，我们可以使用专门的硬件/软件防火墙以及负载均衡来处理对访问入口的大量并发请求。SQL注入是目前互联网企业最为关注的攻击手段，。技术细节可以市面参考相关书籍与文章，笔者在此不以赘述。

流量控制

私有云的流量限制条件比公有云宽松一些，但是仍要予以高度重视，否则同样会带来体验乃至安全上的严重后果或者事故。平台入口以外的流量我们可以通过外部防火墙进行处理，虚拟机内部的流量往往通过虚拟化平台的流量控制功能进行限制，有些时候也会引入内部防火墙。平台也要对架构中的异常流量有所感知，以通知相关人员进行维护或者防护。

网络安全方面有很多成熟的方案或者产品，我们应根据它们的效能、管理复杂度、平台兼容性等进行综合选择，尽量减少引入私有云时带来的复杂度和成本。

存储介质加密

在此以常见的智能手机为例，用户保存在手机里的数据包括联系人、音视频、照片等，给手机屏幕解锁后，用户可以访问它们。当手机损坏或丢失后，某些心怀不轨的人可能会利用设备复制出手机的闪存内容进行解读。为预防这种比较极端的情况发生，现在的智能手机操作系统中都会有“加密存储”、“远程抹除”等安全选项，当用户选择进行存储加密时，对存储介质的非法直接访问也将变得异常困难（现在的加密key一般存储在手机CPU中）。

上述的场景应用到私有云时，用户的数据即是虚拟机硬盘以及存储于“网盘”上的内容。

图2-15 用户数据加密主体

服务器操作系统中存储有虚拟硬盘，在这一层进行加密就意味着即使这台服务器硬盘被取出，也很难读取其中数据；KVM下的虚拟硬盘本身在创建时也支持 AES加密选项，但由于其稳定性欠佳已经被社区渐渐抛弃，截止成文时没有任何改进的措施出现；至于虚拟机OS内，它可以加密虚拟硬盘、数据、目录等等，但是需要用户自己进行选择加密的内容。

数据加密解密的同时一定会带来性能上的些许影响，全部使用服务器OS加密硬盘一定不会适用于所有场景，同样强制用户虚拟机OS加密也不会太妥。当面向安全等级特别高的场景时，使用服务器加密一定是有益的，一般场景下我们提供虚拟机OS加密的建议即可。

服务器设备

我们现在也有很多措施可以专门用来加强服务器本身的安全性，不妨尝试从以下两方面入手：

可信平台模块

可信平台模块（TPM，Trusted Platform Module）由计算机工业的可信计算组（TCG，Trusted Computing Group）制定，旨在提供计算机安全加密设备与技术，用来防止密码、敏感数据被窃取的标准设备。下图为某厂商的TPM模块，附加于专用的主板I/O接口。

图2-16 某厂家的TPM模块

它是一个硬件模块，本身提供了各种加解密算法的快速计算，同时可以进行远程认证、数据加密/解密认证，主要应用场景如下：

平台认证

它可以从硬件设备、设备固件、BIOS到操作系统、软件都进行哈希校验，保证系统中没有未经许可的硬件或软件接入。比如接入一个未曾记录过的USB键盘时，它就会记录并按照预配置操作进行处理。

硬盘加密

服务器操作系统可以在其内部使用TPM协助进行硬盘加密，一般需要特定软件实现，比如dm-crypt、BitLocker等。

密码保护

用户的密码、密钥、数据、操作系统等都可以使用它来进行保护。传统软件实现的认证机制往往不能经受字典攻击，而TPM内置了防字典攻击机制，使得所有绕过软件限制的大量尝试登录操作被TPM终结。

目前在私有云中，主流虚拟化平台都提供了对TPM的支持。QEMU中除了TPM透传外，也可以使用QEMU模拟出TPM设备进行加解密。

地理位置标签

使用地理位置标签（Geo-Tag）可以帮助管理人员了解服务器的具体位置，以方便管理维护。它可以配合RFID设备进行短距离细分标识，并且在统一管理平台的帮助下，实现所有设备状态、位置的实时监控。当然它也可以配合TPM组建基于地理位置的可信资源池。

3、“云”化架构

由第一章私有云的定义我们可知，虚拟化只是“云”的实现手段之一，而面对真正的云我们仍需要很多工作。我们接下来讨论的内容就是如何将基础架构“云”化。

3.1 池化资源

池化资源是向“云”迈进的重要一步，这一点我们可以通过社区动态以及商业云产品中窥探到。在前面的基础架构中，我们围绕着计算、存储、网络三个基本元素组建系统，而接下来就需要使用云平台将它们进行“池化”操作，从而提供更具有弹性、更加高效和稳定的的服务。

以服务器为基本载体的三种资源通过各种方式进行组合，提供IaaS、PaaS、SaaS模式的服务。这些服务模式展现给最终用户的有诸如虚拟机、云存储、负载均衡、内容加速、应用框架等具体服务，如图2-17所示。将资源进行池化的好处即是一方面用户不必知道所接受服务的具体来源，同时能够得到稳定、快速的服务响应，另一方面服务提供商对资源也能进行合理的管理与维护。

图2-17 典型“云”服务模型

3.2 SLA管理

SLA（Service Level Agreement）即服务等级协议，它通过对资源的限制、配置、调度而保证服务的高可用。

高可用

高可用可以按照其作用对象可分为服务器、虚拟机以及虚拟机内应用程序。

在服务器层面，我们通过评分、隔离、电源管理等机制保证虚拟机运行在一个稳定的环境中。评分即通过监视服务器的资源当前及历史状态，对其进行综合评价，分数越高具有运行虚拟机的权利。隔离操作一般发生在服务器与集群管理节点失去联系时，为保证服务质量而将其从服务集群中隔离不再运行虚拟机，一般配合电源管理进行操作。

虚拟机层面的高可用往往需要对其添加模拟看门狗。看门狗是一种辅助芯片，在嵌入式系统中常用来监控CPU状态，当CPU停止工作后看门狗就不会再收到CPU发来的心跳信号而将CPU强制重启。对于PC而言，看门狗将系统重启的条件多是蓝屏、死机等。

对于虚拟机内的应用程序的高可用，可以通过外部监控（比如端口状态监测）和内部监控（比如虚拟机代理程序）完成。这方面的监控产品比较多，主流的有 Nagios/Icinga和Zabbix等，它们都需要在虚拟机内按照代理程序，当某一应用被监测到停止响应时，就可以使用管理员提前设置的策略尝试重启此应用。

资源限制

资源限制即是对允许用户使用的最大资源进行限制，包括虚拟机数目、CPU、内存、硬盘、网络等。这里的限制按照对象可以划分为两个方面，一是用户允许使用的总资源配额，二是虚拟机在运行时所允许的资源最大利用率。

比如在一个用户可以自己创建虚拟机的环境中，管理员往往难以控制其创建删除行为，如果能对用户创建的所有虚拟机数目、vCPU数目、内存大小、硬盘大小、网络带宽进行配额限制的话，那就既能满足用户的自主性又可适当减少管理员负担了。这种限制有些类似操作系统中的配额限制，它主要体现在对“量”的限制上。

但是对“量”的限制还不能满足私有云的需求，那么就要从“质”上进行限制了。如果用户拥有足够的服务资源配额，那么当他的虚拟机长期满负荷运行时（比如网络发包、硬盘高IOPS直写、CPU利用率高居不下等），就会对与其处在同一台服务器上的虚拟机造成比较严重的影响。为了其他用户的体验考虑，我们引入了利用率的限制，包括CPU利用率（CPU数目与其利用率乘积）、硬盘利用率（IOPS、MBPS）、网络利用率（百分比）等。

当用户的资源将要超过配额或者较长时间内高利用率使用时，平台同样需要对其发出警告，防止其系统发生崩溃、恶意入侵等意外情况。
读者可能会在很多地方读到关于将PaaS平台搭建在IaaS平台上的资料，但是我们需要了解这样做的原因主要是考虑到了资源的隔离控制，而不是资源用度方面，所以其高可用性较之以物理机直接接驳容器工具方式有一定劣势。

资源配置

资源配置往往是一个动态的过程，它通过一系列策略对虚拟机的CPU、内存、网络、硬盘的使用进行控制，以期最有效地利用服务器资源。
当一个多核虚拟机运行时，它会有多个LWP（轻量级进程，可理解为线程）协同父进程运行。比如一个双路32核的服务器上运行一个单路32核的虚拟机，往往就会有多于33个LWP在运行（可用ps -eLf查看）。而这些LWP在未指定的情况下往往会在核之间漂移，然后由于进程同步和上下文切换对虚拟机性能造成比较大的损失，当使用率提高时也会对其他进程产生比较严重的影响。为了解决这一类性能损失，我们引入p-vCPU绑定与NUMA机制。

另外我们还可对每个虚拟机vCPU进行优先级安排，较高优先级的vCPU拥有更多的CPU时间。这一特性由于其收益较小，在私有云中适合于极端优化场景。

对于内存的配置，我们同样可以利用KSM（Kernel SamePage Merging）配合内存气球技术提高内存使用效率并达到内存“超分”（over committing）的效果。从KSM可以看出其字面意思，即合并虚拟机所占用虚拟机的相同内存页以节约服务器内存占用，如图2-18。内存气球即假设虚拟机的实际占用内存为气球体积，服务器总内存为装有许多气球的盒子，占用内存即为盒子中的空闲体积。当气球变小时，盒子空闲体积变大，就有更多的空间可以供给其他气球及服务器使用，反之亦然，如图2-19。

图2-18 KSM原理

图2-19 内存气球技术

资源调度

资源调度的过程按照虚拟机的生命周期可分为两部分进行，一是用户请求服务后服务资源后池中分配合适的资源提供服务，我们称之为启动策略；二是当提供的服务达到调度阈值后，为了服务的质量保证而进行的自动调度或者手工调度，我们称之为运行时策略。资源调度是考虑一个云平台质量的重要指标。为了实现私有云的资源调度策略，我们需要的操作通常有对虚拟机的迁移、开关机、挂起，以及对服务器的开关机、隔离，再结合定时、分级、排序、统计、反馈机制，套用到不同的场景中去。接下来我们从启动策略、运行时策略开始，讨论它们可能用到的机制和具体操作。

启动策略的实现或简单或复杂，目前在私有云中最基本的有两种：

快速启动

平台首先对服务器按照其所剩资源进行排序，比如第一个列表为所有服务器剩余内存从高到低的排序，第二个列表为所有服务器CPU剩余未分配核数从高到低的排序。当虚拟机请求资源准备启动时，它从第一个列表中发现服务器甲、乙、丙满足其CPU核数要求，从第二个列表中发现服务器甲、丁满足其 内存要求，那么虚拟机就会在服务器甲上启动，原理如图2-20。类似这种快速启动策略实现起来比较容易，效果也能满足大多数场景。

图2-20 快速启动示意图

最优启动

同样地，平台也会对服务器进行排序，但是这次排序除了考虑剩余资源，也会考虑已用资源。当虚拟机请求资源准备启动时，平台根据剩余资源 选择一组可用的服务器，然后再计算出这个虚拟机在这些服务器上运行的话单个服务器的资源百分比是否超过预设阈值，然后它会选择一个资源百分比变化最小的服务器上启动虚拟机，原理如图2-21。最优启动在实现时，往往会结合运行时策略进行调度，尽量减少虚拟机或者服务器的后期运行时调度。

图2-21 最优启动示意图

启动排队

在启动策略中为减少“启动风暴”的发生，我们往往会引入排队机制。每台服务器会根据其当时负载状况选择一定时间窗口内可 以允许多少台虚拟机启动，待这些虚拟机启动完成对硬盘和CPU的负载降低后后，再启动下一批虚拟机。在一个监控机制较完善的平台下，排队机制中的变量（队列长度、窗口时间等）可以根据服务器状态进行动态调整。

运行时策略可以从很多角度进行设计，比如服务器利用率、电源能耗、用户负载等，常用的有如下两种：

• 平均分布：平均分布即要求所有服务器上的负载（虚拟机数目、资源用度）尽量相同，对于负载过高的服务器就会迁移其上的某些虚拟机至其他负载较低的服务器。这样做的目的是降低局部负载，保持虚拟机所处环境的平等。

• 低能耗：这种策略有两种实现，第一种要求所有虚拟机运行所占用的服务器数目尽可能少。它先将虚拟机从多台服务器上集中迁移到某些台服务器，然后再 将其他服务器关机以达到省电的目的。第二种则不要求服务器关机，但是会让闲置的虚拟机释放CPU、内存资源，它通过定期检测桌面连接或应用连接，挂起较长时间无连接的虚拟机。在私有云桌面环境中，第二种实现应用比较广泛。

虚拟机亲和组

虚拟机亲和组即是按虚拟机应用或者关系将其分组，同一组的虚拟机尽量在同一台服务器中运行或者往同一台服务器迁移。应用 环境相似的虚拟机会有很多相同的内存页，那么将它们保持在同一台服务器上运行就会很大程度上地节约资源消耗。集群架构的业务虚拟机有时也需要在同一亲和组 中，比如负载均衡的Web服务器、分布式计算服务器等。

• 弹性伸缩
  弹性伸缩是“云”化的重点之一，主要功能是在基础设施资源固定的情况下，平台可根据用户应用程序的需求对其在用资源进行自动扩充或回收，其实现包括Amazon简单/分步扩展策略、阿里云的弹性伸缩服务等，但这不代表它仅适用于公有云。一般来说，三大主要资源都可以进行弹性伸缩，但它们落实到具体对象上时则主要以虚拟机实例（或者vCPU）数量、容器实例数量、网络质量、存储读写质量等为单位（vCPU、内存热插拔方式的伸缩目前由于操作系统支持受限，所以应用极少），可应用的场景主要有Web服务、分布式计算、存储服务等依托LB（Load Balance，负载均衡）与HA的集群服务（关于LB/HA的技术选型可参考第10章相关内容）。

以应用较多的Web服务为例，它的典型实现示意图如图2-22所示。

图2-22 典型Web集群服务实现示意图

当Web服务网关收到请求以后，它会从LB集群中选择一个Web服务器响应服务，此Web服务器将与HA的数据库服务交互以后再返回信息给用户。如果用户请求过多，每个Web服务器的资源用度超过上限阈值一定时间时，平台就需要新建一台Web服务器并将其注册到LB集群中，如此以来新的请求便会被引导至新加入的Web服务器上，从而使得集群服务处理能力得以提高；反之，当多数服务器的资源用度低于下限阈值超过一定时间时，平台则会从LB集群中移除一台Web服务器以节省资源占用。

这个过程中的资源用度检测、阈值设定、Web服务器数量变化、LB服务器的注册与注销，即是由弹性伸缩服务所提供。

完善的弹性伸缩系统对于监测准确度、阈值选择与设定、阈强度（即高于或低于阈值的持续时间）、响应时间（即伸缩条件被触发后，Web服务器创建/移除、注册/注销过程消耗的总时间）、可伸缩集群类型（Web服务、数据库服务等）、防火墙（有效阻挡攻击流量）等方面都有一定要求。以阈值选择与设定为例，在实现是多以服务器即时并发量、资源消耗等综合考量，如果我们仅仅将指标设置为CPU用度，且阈值设置不合理的话，就可能发生如下现象：已知单位时间内用户请求数一定，那么当一个已经扩展的LB集群整体资源用度低于缩减阈值时，则其中一台Web服务器会被移除，用户请求被单台服务器全部接收导致其CPU利用率上升，如果此时扩展阈值过小系统则会再次向LB集群中添加一台服务器使得CPU利用率再次下降，最后重复前面的步骤导致震荡发生，如图2-23。

居中

图2-23 典型Web集群服务实现示意图

如果读者对此部分设计有兴趣可适当阅读自动化相关书籍，比如《线性系统理论》、《现代控制系统》、《自动控制原理》等，虽然是面向电子电气专业人员，但对IT从业者也颇具参考价值。

4、OpenStack基础架构设计示例

基础架构模型是需要根据业务模型设计的，接下来笔者以OpenStack基础架构为例，首先介绍适用性较广的通用型设计，然后以其为基础拓展至计算或存储密集型的设计。

另外，在部署工具的选择上，笔者推荐初学者使用Mirantis Fuel或RedHat RDO部署OpenStack，它们都使用了自动化部署工具——Puppet，前者相对后者拥有友好的Web界面，所以用户相对较多，在国内也有分支合资公司。

通用型设计

通用型设计即是指用户需求不太明显的情况，我们提供给用户适用性较广的架构以满足其潜在需求。比如用户在内网运行Web服务器但不知何时会面向公网，或者用户是为了某个项目进行实验等等。这种设计所需要的OpenStack组件中，我们对用户的潜在需求进行分析，然后选择安装尽可能多的组件。

存储考虑

提供的存储服务主要包括块存储与对象存储两部分。

块存储服务是整个架构的基础，一般会直接部署Cinder管理块存储服务，其后端有很多商业存储可供选择，同时OpenStack也提供了针对商业存储的插件。如果没有单独的存储设备则考虑在各个服务器上部署多副本的CephFS集群，但服务器上除系统盘外也要有额外的硬盘组RAID 5或6。如果用户希望虚拟桌面的操作更流畅，或者他们需要频繁地创建、删除虚拟机，可考虑划分单独的SSD存储池用于虚拟机镜像存储（Nova、Glance）。如果服务器仅仅用作提供存储服务，从笔者经验来说采用高主频、少核的CPU时性价比较高。

而使用对象存储的目的有两个，一是存储部分虚拟机模板镜像，二是让用户将其作为网盘使用。存储模板镜像时，对象存储架构比较简单，Swift控制节点也可放入主控制器中；当作网盘使用时，那么Swift网关服务器就相当于一个Web服务器，且用户会话时间较长，此时如果并发有一定数量但未具备相当规模时，一般只需加强网关服务器硬件与优化系统配置即可，如果要针对较大规模并发，则需要更改其架构，比如添加单独的负载均衡设备或者组成高可用集群。

网络考虑

在设计基础网络时，一般会针对不同的网络功能区域进行单独设计。

OpenStack目前提供nova-network与neutron两种网络后端，但前者在最近的版本中已被标记为“deprecated（抛弃）”，所以笔者推荐使用neutron以提高系统向后兼容性与扩展性。

通用型设计中，网络一般划分为公共网络、用户网络、管理网络、存储网络等。公共网络即是用于对外服务的网络，这些服务主要用于用户访问（Web、REST API、Spice），连接到这些网络的节点只有Controller、Swift网关、桌面协议代理网关等，同时LB集群节点也会使用此网络。用户网络即是用户的虚拟机或容器实例使用的内部网络，其IP地址位于“虚拟网段”中，或者是与物理交换机相连的“物理网段”中，一些在公共网络中的服务也可在此网络中以提高内部实例访问服务的速度。管理网络即是管理硬件资源时使用的网络，管理员使用工具添加新节点时会赋予其管理网络所在网段的IP。存储网络即是存储节点所使用的网络，它对网络硬件的要求较高，包括带宽、延迟、冗余性等方面。

计算考虑

通常，计算节点所组成的集群按照其逻辑功能或位置划分为多个计算池，且每个池中的资源总量都由管理员定义，比如常驻桌面池、浮动桌面池、研发服务器池、办公服务器池等。考虑到虚拟机实例的可迁移性，同一池中的服务器CPU配置（主频适中、多核）都是相同的，同时服务器都与需接入对应功能区域的网络。

虚拟化的基本特性之一是资源超分，即分配给虚拟机的资源可以超过所在计算节点实际资源，CPU资源、内存资源在OpenStack中的比例默认为16:1、1.5:1。这些比例并不一定适用于实际环境，比如当CPU超分过多时，会导致部分虚拟机因QEMU进程上下文切换成本过高而变得卡顿，当内存超分过多时，如果虚拟机实例实际占用的内存超过hypervisor的物理内存，则有可能发生交换（swap out）动作同样导致部分虚拟机性能下降。

与计算节点紧密相关的控制节点硬件配置一般不需要很高，可参考存储网关节点配置。

架构示例

如图2-23是以提供Web服务虚拟机为主和对象存储为辅服务的OpenStack架构。存储服务由单独的存储服务器集群提供，包括用于计算节点的块存储服务Cinder以及用于云存储的对象存储服务Swift。

网络部分的划分笔者并没有在图中标注，但整体可进行如下划分：外部业务网络包括防火墙、控制器、Swift网关、负载均衡网关（虚拟机），服务器网络包括控制器、Nova计算集群，存储网络包括CephFS存储集群、Nova计算集群、Swift存储网关，虚拟机网络则专门用于虚拟机。

计算服务池分为研发和业务，前者用于研发人员开发、测试、代码/项目管理等，后者则用于运行已经上线的Web服务。由虚拟机组成的Web服务集群接收来自负载均衡设备分发的请求，再选择Web服务器予以响应。图中的负载均衡网关是在虚拟机内以软件形式提供的，它和Web服务器集群的架构与传统架构相同，因为管理员对后者更为熟悉。而高可用的控制器则保证了所有OpenStack组件控制组件的稳定性。由于用户需求中对象存储仅仅作为可选存在，所以此设计并没有添加单独的Swift存储网关负载均衡措施。

图2-23 提供Web服务虚拟机、对象存储服务为主的OpenStack架构示例

计算密集型设计

如果用户的应用是在高性能计算（HPC）、网格计算（GRID）、图文索引等非常依赖CPU性能的环境中时，我们可以对通用型稍作修改以完成应用计算密集型设计，而这其中又可以分别选择Nova或者Magnum提供虚拟机实例或容器实例，以隔离计算资源分别进行计算作业，从而构建出多租户环境的PaaS平台。

计算密集型的设计中，我们会尽量缩短I/O路径以减少数据搬迁带来的时间成本，且由于虚拟机实例或容器实例很少有高可用需求，所以采用本地存储将直接用于存放Nova虚拟机实例镜像与应用程序需要的文件系统，比如HDFS。此时，网络划分相对来说简单一些，但是计算节点则需要拥有独立的数据盘，采用OpenStack 基础设施的Hadoop集群架构如图2-24所示，其中控制节点可选装OpenStack大数据项目Sahara。

这种架构虽然牺牲了虚拟机的迁移特性，但同时正因为这点我们便可以在Nova节点添加物理显卡并透传至虚拟机中，从而提高特定行业领域的分布式计算性能。

图2-24 以OpenStack虚拟机作为基础设施的Hadoop集群

由于虚拟化的性能较之物理机有轻微损失，所以有人考虑使用性能几乎等同于物理机的容器运行分布式计算应用。笔者成文时原生Kubernetes、Docker Swarm、Mesos/Marathon组建的Docker集群并没有多租户功能，而出现稍晚的OpenStack容器服务Magnum则可将Swarm与Kubernetes作为容器集群后端，可同时利用Nova或者Heat提供容器模板，加之其原生的多租户支持而越来越受人关注。其架构可参考图2-25，其中使用Kubernetes作为容器集群服务，两个计算池分别用Nova和Heat提供的容器实例以适应不同的应用场景，其网络同样由Kubernetes提供，存储部分可参考上图。

图2-25 OpenStack Magnum参考架构

存储密集型设计

存储密集型的设计一般可将其理解为用于提供对外存储服务的基础架构，相当于一个独立的存储设备，其中的Nova上的虚拟机仅用作高可用存储管理服务与负载均衡的Swift存储网关，如图2-26所示。

图2-26 存储密集型OpenStack架构

这个架构主要参考了一些存储厂商的软件设计，所有对外暴露的存储服务都由管理入口进行控制，包括RBD、共享文件系统、对象存储以及基于它们二次构建的NFS、iSCSI、CIFS等。其中计算节点性能较弱，仅运行一些功能单一的虚拟机，厂商的实现中甚至将包括控制器、管理入口在内的服务直接部署至存储节点。

5、总结

私有云架构的基础与传统IT架构一样，都是根据需求一步一步扩展。为了保证物理上难以的虚拟机维护的虚拟机稳定运行，我们要求资源的基础架构具有稳定性、冗余性和扩展性。当资源延伸到虚拟机中使用以后，整个架构才开始变的灵活但又不易控制。此时需要我们采取安全防护和资源限制措施，以让它在一个可控的环境中发展。当它发展到一定程度后，我们赋予其“云”的属性，比如资源池化、SLA管理等。至此，我们的基础架构走向正轨，再经历更多意外、添加更多实用技术，然后才变得更加成熟、稳定。

摘要

•帮你速读文章内容

企业评估私有云建设需求需考虑系统利用率、扩容成本、扩展能力、标准化程度、云化难度、成本、安全性、技术路线、业务连续性及高性能计算需求等，确保符合业务需求、技术能力和预算限制。

摘要由平台通过智能技术生成

有用

1 企业如何评估私有云建设需求

企业在评估私有云建设需求时，需要从多个方面进行综合考虑。以下是一些关键步骤和考虑因素：

评估私有云建设需求的步骤

1. 需求和资源使用特点：

• 系统利用率：评估现有IT系统的资源是否得到有效利用，是否存在资源闲置或负载不均衡的情况。

• 建设扩容成本：分析现有IT系统的扩容成本，包括硬件、软件和网络设备的升级和维护成本。

• 扩展能力：评估系统的scale-up和scale-out能力，是否能够满足未来业务增长的需求。

• 信息系统的标准化程度：

• 基础架构环境标准化：评估所需支撑的硬件是专用硬件还是通用硬件。

• 平台环境标准化：评估开发环境、中间件环境以及数据库环境的通用需求和租户限制。

• 应用系统的标准化：评估应用系统的运行环境、是否支持分布式等。

• 云化建设/迁移的难度：

• 硬件支撑环境改造：评估现有硬件环境是否需要改造以适应云计算环境。

• 操作系统平台变更：评估操作系统是否需要变更或迁移。

• API重构、模块化改造：评估应用系统的云化改造难度。

• 成本的评估与考虑：

• 初始成本：评估私有云建设的初始投资，包括硬件、软件、人力和培训成本。

• 运营成本：评估私有云的运营成本，包括维护、管理和升级成本。

• 安全性和合规性：

• 数据安全：评估数据在私有云中的安全性和隐私保护措施。

• 合规性：评估私有云是否符合相关的法规和合规性要求。

• 技术路线选择：

• 技术成熟度和稳定性：评估不同技术方案的成熟度和稳定性，选择最适合企业需求的方案。

• 服务满意度：评估云服务提供商的服务质量和满意度。

• 业务连续性和灾备需求：

• 同城灾备：评估是否需要同城灾备中心提供灾备数据的存储资源。

• 异地灾备：评估是否需要异地灾备中心提供应用级灾备资源。

• 高性能计算需求：

• I/O瓶颈：评估现有云计算解决方案在I/O方面的瓶颈。

• 数据瓶颈：评估数据处理能力是否满足高性能计算需求。

• 资源池跨数据中心调配需求：

• 资源调配灵活性：评估是否需要跨数据中心的资源调配能力。

• 数据与标准化需求：

• 数据需求：评估业务信息系统生产数据和云技术平台运营管理数据的需求。

• 标准化需求：评估云计算概念、定义及内容的标准化程度。

评估私有云建设需求的关键考虑因素

• 业务需求：明确企业的业务需求，包括业务连续性、高性能计算、数据存储和访问需求等。

• 技术能力：评估企业现有的技术能力和人才储备，确保有足够的技术支持私有云的建设和管理。

• 预算限制：根据企业的预算限制，合理规划私有云的投资和成本控制。

通过以上步骤和考虑因素，企业可以全面评估私有云建设的需求，选择最适合自己的云计算解决方案。

2 数私有云平台建设与应用方案参考

免责声明：文字章节为公众号原创，文章中方案展示章节PDFPPT等来源于各文库类平台，源头无从查找，仅供读者

学习、参考，禁止用于商业用途。其版权归作者或项目实施方所有，本公众号不对所涉及的版权问题承担法律责任。若版权方认为本公众号侵权，请联系小编删除。本文章赞赏费，是小编收集整理该资料以及整理资料运营所必需的费用支付，资料索取者请尊重版权方的知识产权，支持版权方和出版社。文章中如有错误及事实错误等，请指出，便于读者获取更准确的信息。