webhosting,云空间和网盘有什么区别

webhosting，云空间和网盘有什么区别？

云空间和网盘是两个相关但不完全相同的概念，它们都涉及到云计算和数据存储。下面是它们的区别：

云空间（Cloud Storage）：云空间是指在云计算平台上提供的用于存储和管理数据的服务。它是一种通过互联网将数据存储在远程服务器上的解决方案。用户可以通过网络访问和管理这些数据，而不需要依赖本地存储设备。云空间通常由云服务提供商提供，例如Amazon Web Services（AWS）、Microsoft Azure、Google Cloud等。

特点：

可扩展性：云空间可以根据需要轻松扩展存储容量，而不需要更换硬件设备。

可靠性：数据通常在多个服务器和地理位置上进行备份，以确保数据的安全性和可用性。

可以用于存储任何类型的数据，例如文档、照片、视频等。

一般来说，云空间并不是免费的，用户需要根据存储容量和使用量付费。

网盘（Cloud Storage Service or File Hosting Service）：网盘是云空间的一种具体应用，它是一种在线存储服务，允许用户上传、存储和共享文件。网盘服务通常提供桌面客户端和移动应用程序，使用户可以方便地上传和访问存储在云端的文件。用户可以通过分享链接或授权他人访问来共享这些文件。

特点：

网盘是云空间的一种特定用途，专注于文件存储和共享。

大多数网盘服务提供商都提供一定的免费存储空间，并可通过付费方式获得更大的存储空间。

网盘服务通常具有文件同步功能，可以确保多个设备上的文件保持同步。

总结：云空间是一种通用的概念，涵盖了用于存储和管理数据的各种云服务。而网盘是云空间的一种特定应用，专注于文件的在线存储和共享。网盘是云空间的一个子集，而云空间则涵盖更广泛的数据存储和管理服务。

如何建设IDC数据中心机房？

Internet Data Center互联网数据中心，简称IDC数据中心，它是传统的数据中心与Internet的结合，它除了具有传统的数据中心所具有的特点外，如数据集中、主机运行可靠等，还应具有访问方式的变化、要做到7x24服务、反应速度快等。下面就由广州莱安智能化系统开发有限公司来简单介绍一下：

IDC是一个提供资源外包服务的基地，它应具有非常好的机房环境、安全保证、网络带宽、主机的数量和主机的性能、大的存储数据空间、软件环境以及优秀的服务性能。设计集建筑、结构、电气、暖通空调、给排水、消防、网络、智能化等多个专业技术于一体，应具有“良好的安全性能，可靠而且不能间断”的特点。

它可以为企业和各类网站提供专业化的服务器托管、空间租用、网络批发带宽甚至ASP、EC等业务。简单地理解，IDC是对入驻(Hosting)企业、商户或网站服务器群托管的场所；是各种模式电子商务赖以安全运作的基础设施，也是支持企业及其商业联盟（其分销商、供应商、客户等）实施价值链管理的平台。形象地说，IDC是个高品质机房，在其建设方面，对各个方面都有很高的要求。

IDC的建设主要在如下几个方面：

一、网络建设

IDC主要是靠其有一个高性能的网络为其客户提供服务，这个高性能的网络包括其- AN、WAN和与Internet接入等方面。 IDC的网络建设主要有：

（1）IDC的- AN的建设，包括其- AN的基础结构，- AN的层次，- AN的性能。

（2）IDC的WAN的建设，即IDC的各分支机构之间相互连接的广域网的建设等。

（3）IDC的用户接入系统建设，即如何保证IDC的用户以安全、可靠的方式把数据传到IDC的数据中心，或对存放在IDC的用户自己的设备进行维护，这需要IDC为用户提供相应的接入方式，如拨号接入、专线接入及VPN等。

（4）IDC与Internet互联的建设。

（5）IDC的网络管理建设，由于IDC的网络结构相当庞大而且复杂，要保证其网络不间断对外服务，而且高性能，必须有一高性能的网络管理系统。

二、服务器建设

IDC的服务器建设可分为多个方面，总体上分为基础服务系统服务器和应用服务系统服务器，主要有：

（1）基础系统服务器：这类服务器是保障IDC为用户提供各种服务的前提，这类服务器有DNS服务器、目录服务器、网络管理服务器、防火墙服务器、各类安全服务器、IDC系统性能监控服务器等等。

（2）数据库服务器：它是保证IDC可以为用户提供各种应用服务的基础，IDC的数据库服务器必须能支持大容量访问、多种数据库等。

（3）数据备份服务器：它是IDC为客户提供安全服务的内容之一，保证客户的数据安全可靠。由于IDC的服务器种类繁多、有多种数据库，所以数据备份要支持多机型、多种数据格式等等，而且容量要大。

（4）应用服务器：是IDC为用户提供相关应用服务的服务器。由于IDC的业务扩展，所以应用服务器应具有很好的扩展性，以及支持各类应用软件的数量要多。

（5）服务器的负载均衡：这是IDC提供高性能、高可靠性服务的重要方法之一，服务器的负载均衡可由硬件设备（如网络交换设备）或软件的方法实现。

三、存储系统的建设

存储系统是IDC的重点建设内容之一，作为一个IDC，其存储系统是相当庞大的，特别是在现在的企业中，数据的容量以由GB级增长到TB级，如此大的数据需要有一个更加安全、可靠的存储系统，由于访问的数量也是相当庞大的，所以对存储系统的效率也有很高的要求；而且存储系统应具有很好的扩展性，以满足IDC的发展的需求。

四、软件系统的建设

软件系统的建设是IDC需要大量投入的方面，它是在前面网络、服务器和存储系统建设的基础上，IDC开展对外服务的手段。IDC在软件建设的主要有：

（1）Web系统：IDC开展Web-Hosting服务内容之一，Web系统软件应支持在一个系统上能建立为多家企业服务的Web系统功能等。

（2）电子邮件系统：电子邮件系统应支持多种电子邮件协议，如SMTP、POP3、IMAP4、Web-Mai- 和Voice-Mai- 等，同时电子邮件系统应有很好扩展性等。

（3）数据库系统：IDC应建立多厂家的数据库系统，如应有Orac- e、Informix、SQL Server、SyBase等厂家的数据库，以满足不同用户的需求。

（4）安全系统：如防火墙软件（硬件防火墙除外）、防黑客入侵、防病毒软件等。这是保证IDC为用户提供安全服务器的前提。

（5）数据备份软件:支持多备份设备、多种厂家的机器、多种数据库等等。

（6）应用开发系统：IDC应提供相应的开发系统平台，提供相应的开发工具，满足用户或IDC开发相应应用的需求。

五、IDC自身服务系统建设

IDC是靠其优质的服务来占有市场和赢得客户的，为了做到优质高效服务，IDC在其自身服务器系统的建设上也必须有大量的投入。IDC自身服务系统主要有：

（1）客户关系管理系统(CRM): CRM是IDC与客户建立良好关系的基础服务系统，它为IDC提供的用户的发展动态以及用户的新的需求等。

（2）计费系统：计费系统是IDC收入的保证。

（3）网络与服务器管理系统：IDC有庞大的网络和服务器系统，要管理好这些系统，必须有一个功能强大的网络、服务器和应用管理系统，此能保证IDC对外的服务质量。

（4）IDC的内部管理系统：保证IDC内部各部门能够统一协调工作，完成高质量的服务。

六、机房场地建设

机房场地的建设是IDC前期建设投入最大的部分。由于IDC的用户可能把其重要的数据和应用都存放在IDC的机房中，所以对IDC机房场地环境的要求是非常高的。IDC的机房场地建设主要在如下几个方面：

（1）机房装修：机房装修主要考虑吊顶、隔断墙、门窗、墙壁和活动地板等。

（2）供电系统：供电系统是IDC的场地建设重点之一，由于IDC的大量设备需要极大的电力功率，所以供电系统的可靠性建设、扩展性是极其重要的。供电系统建设主要有：供电功率、UPS建设（n+1）、配电柜、电线、插座、照明系统、接地系统、防雷和自发电系统等。（3）空调系统：机房的温度、通风方式和机房空气环境等。

（4）安全系统：门禁系统、消防系统和监控系统。

（5）布线系统：机房应有完整的综合布线系统，布线系统包括数据布线、语音布线、终端布线。

（6）通信系统：包括数据线带宽、语音线路数目等。

油猴好用的插件？

下面是一些油猴的好用插件：

1. AdBlock Plus: 去广告插件，可帮助用户在浏览器上屏蔽网页广告。

2. Enhancer for Youtube: Youtube 增强插件，用于增强 Youtube 视频播放体验，例如添加字幕、自动播放列表等等。

3. Resurrect Pages: 快速恢复删除的网页，可快速打开已经被删除的网页。

4. AutoPagerize: 自动翻页插件，可自动加载下一页数据，免去手动翻页的繁琐。

5. Distill Web Monitor: 网页监视器，可监控网页的内容变化和更新，例如新闻网站、在线商店等等。

6. Grammarly: 语法检查插件，可自动检查英语语法和拼写错误，提高英语写作水平。

7. Tampermonkey File Hosting: 脚本文件主机，可将用户的脚本文件存放到云端，方便备份或共享。

以上是一些常用的油猴插件，可根据个人需要进行选择和安装。

Serverless是什么？

原文地址：https://www.toutiao.com/i6727815175841251852/

作者 | 阿里中间件高级技术专家许晓斌

《Maven实战》作者，曾负责 AliExpress 微服务架构演进，现在负责阿里集团 Serverless 技术研发落地。

导读：从 2016 年 AWS 发布 Lambda 以来，全世界的开发者和云厂商对 Serverless 的热情在不断高涨。假设不想在开发应用程序并将其部署在服务器上的过程细节上花费精力，是否有一种简单的架构模型能够满足我们这种想法呢？答案已经存在，这就是今天软件架构世界中新鲜但是很热门的一个话题——Serverless（无服务器）架构。本文作者将利用自身多年的研发经验，带领我们深入了解 Serverless 行业的发展！

《喧哗与骚动》是我喜欢的作家威廉·福克纳的一部小说，小说用多个家庭成员的意识流，从不同的视角描绘了一家三代的悲剧。这部小说有意思的地方在于：对于同样一件事情，从不同人跳跃的意识中能看到迥然相异的景象。

今天大家理解 Serverless 也有点这个意思，因此我以此为题，展开分析。文章只代表作者本人观点。

Serverless is like teenage sex

不知道大家有没有听过这样的话：

Big data is like teenage sex: Everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it.我们把 Big data 换一下：AI is like teenage sex: Everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it.我们把 AI 换成 Serverless：Serverless is like teenage sex: Everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it.

从中可以总结出以下几点：

所有人都在说 Serverless；几乎没人知道怎么落地 Serverless；但是大家都觉得其他人在大力做 Serverless；所以大家都宣称自己在做 Serverless。

Serverless 和很多词如微服务一样，是没有精确定义的，也没有事实的标准。什么是事实标准？Kubernetes 是事实标准；对 Java 程序员来说 Spring Boot / Spring Cloud 是事实标准。

事实标准就是一种思想/方法论得到了广泛落地，占领了市场。落地通常意味着两个点：

它是开放（开源）的。因此不会有 vendor lock-in，所有人可以放心用；有大量的成功案例。很多人将其用到关键的商业系统中，因此得到了广泛验证。

今天 Serverless/FaaS 领域有这个东西吗？还没有。

Serverless 的愿景

下面是来自 Google Trends 的一个图，其中红色是 Microservices，蓝色是 Serverless。

从 2016 年 AWS 发布 Lambda 以来，全世界的开发者和云厂商对 Serverless 的热情在不断高涨，这说明大家对 Serverless 所描绘的愿景都非常 buy in。这个愿景是什么呢？

愿景是无服务器？但工程师们都知道服务器本质上是存在的，最多是加一层抽象，让我们看不到服务器，但它依旧很好的发挥作用。

我个人觉得有关 Serverless 愿景，描绘最清楚的是一个比喻，这个比喻来自 UC Berkeley 在今年2月发表的那篇论文：

简单来说就是：我们今天对云资源的操作方式，就类似于几十年前早期程序员写汇编的方式。

如果你没写过/学过汇编语言，或者已经忘了汇编语言，我特地找了本书拍了一段内容下来：

是不是对图中的这些寄存器、栈、程序计数器、以及相关的汇编指令感到很陌生了？如果让你用这样的语言写业务逻辑，那效率必然会变得非常低。幸好我们有 Java，Go，JavaScript 这样的高级语言，而这些高级语言还配套了相关的编译器/虚拟机，编译器/虚拟机能够高效地把面向业务的高级语言翻译成面向机器的汇编/机器码。

今天，虽然基本的计算机体系结构没有发生本质的变化，但我们的程序所运行的环境，相比较20年前，已经发生了本质的变化。20 年前的程序大都跑在单机上，今天我们的程序都要为了跑在云上而设计了。为了让程序跑在云上，我们就需要配套的工作，包括云资源（容器、缓存、队列）的申请和回收、包括弹性伸缩的控制，等等。这些事情和业务逻辑没有任何关系，但研发/运维同学却为此花费了大量的时间。

我想做一个不太成熟的类比：单机时代，操作系统管理了硬件资源，贴着资源层，高级语言让程序员描述业务，贴着业务层，编译器/VM 把高级语言翻译成机器码，交给操作系统；今天的云时代，资源的单位不再是 CPU、内存、硬盘了，而是容器、分布式队列、分布式缓存、分布式文件系统，而云上的 OS 这个角色，基本上可以说是被 Kubernetes 生态给占了，那么云上的编译器/VM 呢？开发语言和框架呢？好像还没有。

今天我们把应用程序往云上搬的时候（a.k.a Cloud Native)，往往都会做两件事情：

第一是把巨型应用拆小，微服务化；第二就是摇身一变成为 yaml 工程师，写很多 yaml 文件来管理云上的资源。

本质上大家都在把面向单机体系架构编写的应用程序，硬搬到云体系架构上。我认为这里存在两个巨大的 gap，这两个 gap 在图中用灰色的框表示了：

1.编程语言和框架；

目前主流的编程语言基本都是假设单机体系架构运行的，面对分布式问题的时候，再叠一层框架上去。其对应的资源也依旧停留在单机体系结构的那些资源上（当然这里是有例外的，比如 erlang/OTP 天生就是为分布式设计的）。

云时代，首先基本的资源单位发生了变化，从原来的 cpu、内存变成了容器、函数、分布式队列等等；其次，云天生分布式，因此单机时代大行其道的同步模型就不再适合。

2.编译器。

程序员不应该花大量时间去写 yaml 文件，这些面向资源的 yaml 文件应该是由机器生成的，我称之为云编译器，高级编程语言用来表达业务的领域模型和逻辑，云编译器负责将语言编译成资源描述。

我个人很看好 Erlang 的 Actor 模型，这个模型在其他语言上也有实现，例如语法参考 Ruby 并运行在 Erlang OTP 上的 Elixir，JVM 上的 Akka，以及 .NET 上的 Orleans。不同于其他语言的设计，Actor 模型从一开始就是基于分布式的前提做的设计，因此这种模型如果把其对应的资源管理换成纯粹的云资源管理，我觉得是有极大可行性的。

如果用一句话来总结，我觉得 Serverless 的愿景应该是：

Write locally, compile to the cloud.大家在忙什么

除了抬头看天，说了一大堆美好的愿景，还得低头走路，先看看这条路上其他人在做什么。我整理了一下最近一年 Serverless 领域行业发生的一些比较重要的事件。回复关键字 serverless 获取 Serverless 领域近一年行业发展回顾。

为了能够稍微清晰一点地去看这一大堆的产品和技术，我简单的把 Serverless 领域做的事情分了三个层，自下而上分别是资源层、DevOps 层和框架及运行时层。

资源层关注的是资源（如容器）的生命周期管理，以及安全隔离。这里是 Kubernetes 的天下，Firecracker，gVisor 等产品在做轻量级安全沙箱。这一层关注的是如何能够更快地生产资源，以及保证好安全性。

DevOps 层关注的是变更管理、流量调配以及弹性伸缩，还包括基于事件模型和云生态打通。这一层的核心目标是如何把运维这件事情给做没了（NoOps）。虽然所有云厂商都有自己的产品（各种 FaaS），但是我个人比较看好 Knative 这个开源产品，原因有二：

第一是其模型非常完备；第二是其生态发展非常迅速和健康。很有可能未来所有云厂商都要去兼容 Knative 的标准，就像今天所有云厂商都在兼容 Kubernetes 一样。

以下是 Knative 近一年的贡献者及贡献数量的增长情况，数据来自演讲「Knative a Year Later: Serverless, Kubernetes and You」。

框架和运行时层呢，由于个人经验所限，我看的仅仅是 Java 领域，其实核心的还是在解决 Java 应用程序启动慢的问题（GraalVM）。当然框架如何避免 vendor lock-in 也很重要，谁都怕被一家云厂商绑定，怕换个云厂商要改代码，这方面主要是 Spring Cloud Function 在做。

刚需在哪里

产品想要成功，需要有核心竞争力，这个核心竞争力往往就是，你解决了一个用户很头疼、但其他产品没有解决的问题。我姑且把这样的问题称为用户的刚需。那么 Serverless 能解决哪些用户的什么刚需呢？我先对用户做一些简单的分析：

很多技术产品基本都是经历了如下四个阶段：

初创期：一个小团队围绕新的业务做试错，从无到有，技术上什么能快速上线用什么；

这个时候团队规模很小，可能两三个人，所有代码放在一个应用内，不需要分布式，不需要隔离。

成熟期：业务成功了，用户在不断增多，业务也变得越来越复杂；

这个时候团队的规模增长到数十到上百人，团队还处在一个部门，相互之间有足够的信任，沟通带宽也有足够的保证。一个应用的模式已经不能满足协作的需要，架构师开始做应用拆分，系统成了分布式的，按照业务的划分做了进程级别的隔离。

平台期：业务太成功了，就希望把已经沉淀的能力赋能给其他类似的业务；

相比较于成熟期，这时候有了一些新的变化。首先是参与开发的人数增长得更多了，往往是数百上千；其次大多数参与开发的成员已经不再是核心产品团队的成员，他们往往在不同部门了，相互之间的信任已经大大减弱，沟通带宽也开始显著变窄。

由于核心团队对于其他部门的开发缺乏组织管控能力，因此技术上的隔离要求被提上优先级，以避免平台上的开发者不小心拖垮平台本身。伴随着隔离，成本的问题也被提上日常，当平台上数百个插件和平台本身跑在同一个进程内的时候，资源天然是被复用的，只要模糊地计算下整体即可；当数百个插件被隔离到独立的容器中运行的时候，他们的资源占用就需要额外的调度系统去控制和优化。

云产品期：平台太成功了，就希望做成云服务，赋能社会上类似的业务，发挥更大的价值。

如果说在平台期，隔离还只是个重要但非必须的要求的话（很多平台就没有真正做好隔离），云产品期的产品必须具备非常强的隔离能力。平台期做隔离最大的诉求是稳定性（不被平台上的开发者搞垮整个平台），而云产品期做隔离的最大诉求是安全性。正如图中所示，产品上的开发者已经和产品团队不在一个组织了，而且这样的开发者还可能是恶意的，因此除了容器的隔离，还需要虚拟机级别的隔离，网络的隔离等等。

随着技术产品由小长大，不断成功，参与的开发者不断增长，核心团队对这些开发者的控制力越来越弱，沟通带宽不断缩减，信任不断降低，进而导致了稳定性和安全的风险不断上升，这就要求隔离能力不断加强。而随着隔离的引入，以及使用资源的不断增长，成本就成了一个不得不面对的问题，为了更优地分配资源，解决成本问题，就对调度提出了要求。

因此，对于处在平台期和云产品期的产品来说，技术上的隔离能力及调度能力是他们的刚需。

框架和运行时的创新

前面所说的刚需都是集中在稳定性、安全性及资源成本的角度来讨论的。除此之外我们还需要讨论另外一个话题，那就是开发效率，而开发效率具体到技术是体现在框架上的。

我们可以进一步的把框架分成两类：

1.面向技术问题提升开发效率的框架：如 Spring 通过依赖注入解决对象组装问题；HSF 解决分布式同步通讯问题；RocketMQ 解决分布式异步通讯问题；Hystrix 解决分布式通讯引入的网络不可靠问题等等。通过使用这些框架，技术的天然复杂度在很大程度被屏蔽掉了。

2.面向业务问题提升开发效率的框架：阿里的很多业务平台团队都会根据自己的场景（如交易、店铺、供应链）开发业务型框架，赋能开发快速迭代业务。

通常，面向技术问题的框架会有一个团队研发，而面向业务问题的框架则由各类业务平台团队提供，这再一次证明了康威定律的正确性。康威定律翻译成中国的土话差不多就是“屁股决定脑袋”，技术型团队不愿意碰业务问题，而业务平台团队的框架在解决技术问题方面也显得没有技术团队专业，最终的结果是：两种框架割裂得比较厉害。

大家可能听过这么一个故事：

有一条恶龙，每年要求村庄献祭一个处女，每年这个村庄都会有一个少年英雄去与恶龙搏斗，但无人生还。又一个英雄出发时，有人悄悄尾随。龙穴铺满金银财宝，英雄用剑刺死恶龙，然后坐在尸身上，看着闪烁的珠宝，慢慢地长出鳞片、尾巴和触角，最终变成恶龙。

虽然看起来很夸张，但在我看来，这一定程度上体现了一些大中型研发组织主流框架的现状：这些框架在组织发展的历史上发挥了极其重要的作用，然而到了今天，随着云服务不断地成熟，大家都在提云原生，都基于云在构建业务系统的时候，需要框架还在强制用户绑定语言（如 Java），还没做好服务化，把逻辑塞进用户的应用中。有的甚至要求用户的代码必须部署到平台的巨型应用中。

这些限制短期内实现了业务目标，交付了业务价值，但从长期看基本上浇灭了业务开发做框架创新的热情，他们更习惯于等待“位于正确定位的团队”去解决问题，而“处于正确定位的团队”同学呢，可能一时半会还没感受到那些问题。不出意外的话，专注组织内短期业务价值的框架，被推到云上、推到社区、面向更普适通用诉求的时候，获得的认可就会差很多。

传统的框架和运行时，只管理单机层面的资源，而当所有人都用云服务构建自身业务的时候，框架和运行时需要管理的就不再是单机资源，而是云资源了。在这方面行业里已经有了不少产品，比较知名的有 Terraform 和 Pulumi，但我觉得还不够，我觉得理想的云原生框架应该是这样的：

能够帮助开发屏蔽云资源的管理。开发都不喜欢像写汇编一样写 yaml，因此框架需要负责资源的分配、回收，编排等等；纯异步的，事件驱动的。这是云天生的分布式特性决定的，如果编程语言范式还是同步的模型，这个框架就没法实现了；没有 vendor lock-in。不绑定实际的云厂商，唯有厂商中立的开发框架才能被广泛使用，框架定义了编程 API，具体的厂商可以提供相关的 driver；同时具备云资源管理和大规模软件开发必须的编程范式。这里的编程范式可能描述不当，但我找不到更好的词，面向对象设计是最主流的编程范式，Spring 就是围绕这个编程范式展开的。在一个框架中解决两个问题，会给开发极好的体验。小结

Serverless 这个领域看起来极其美好，一旦深入去做了才发现实际非常复杂。这个复杂体现在涉及的工程技术比较广，也体现在用户的期望差异很大，更体现在大家对未来的判断还有很大的差异。

在和团队一起深入这个领域的时候，我也需要不断整理自己的所闻所见、所思所想，因此我计划产出一系列文章，拿出来和大家分享，和大家探讨，这是第一篇，有兴趣的同学可以进群讨论。