我眼中的云端架构.docxVIP

我眼中的云端架构背景在看阿凡达的时候，感叹着他们接口的统一，和获取知识的便利性。有时候在想，现在很多企业所做的工作，不就是要提供这类服务吗。设想一下，我们有一朵公有云，存储了用户的数据、逻辑关系，提供标准的通讯接口，然后大家各自开发丰富的展现逻辑，让云端变的丰富多彩。这次很荣幸能接到这个议题，谈谈我个人对这朵云的理解。每个人心中都有自己的一朵云，在我设想中，应该存在这么一种公有服务，它能够帮助用户随时随地的获取自己的数据，与朋友交流，获取好友最新状态。在这服务之上，我们有这么一个平台，它能够给用户提供二次开发的接口，让开发者根据用户数据开发丰富的展现层，并且提供这些展现层的运行平台。我们需要的云端服务为了完成这个功能，我们需要什么准备？云存储：提供用户数据的存储功能。让用户方便的获取自己的数据。通讯系统：提供以Mail，IM为基础的通讯方式通知系统：好友行为推送，能够把握好友最新动态，或者告知好友你在干什么。在这三个基本服务之上，用户可以开发大量的运用。比如“音乐盒”用于在线播放云存储的MP3，图片系统用于管理、分享，美化自己的照片……然而，用户开发完逻辑应用之后，需要机器运行这个运用。因此，第四个基本服务运行平台孕育而生，它提供所有云应用运行的基本资源，包括内存、CPU、操作系统等。这四个基本要素构建成一个面向终端用户的操作系统平台（也就是我们的云），它能够随时被访问，通过浏览器或者手机的App。满足用户在任意时刻团购，玩三国杀，看视频，听音乐等需求。为了方便开发者开发更多的应用，我们抽象一种编程模式，提供丰富的SDK，加速运用的开发。由于云端服务，有很大一部分会被手机等嵌入式设备访问，于是需要各种平台的编程框架（android、IOS）。编程框架将更加关心业务逻辑，屏蔽分布式细节和运维问题。在满足这些开发便利性的前提下，为鼓励用户开发，提高APP质量和数目，需要一套良好的收费系统，帮助开发者更好的盈利。围绕这这朵云，一点点的展开，发现想说的东西太多，今天我们就谈谈其中的两个核心架构：云端存储和运用运行平台（App Engine）。为什么要选这两个？因为云的核心就是存储和计算，其它都构建在存储和计算之上的基础服务和用户运用。云端存储架构云端存储主要是为了存储用户数据，方便用户访问。它涉及了三方面的技术底层架构。包括：分布式存储、文件目录管理、用户权限系统下载优化：各地CDN支持、客户端下载技术（P2P）数据访问前端优化底层架构设计的要点首先我们比较一下跟传统离线存储的设计指标差异单个文件体积不大存储互联网用户的数据，注定文件不会很大。我们只要支持0-100G左右的单文件大小即可。为什么用户文件会到100G？因为我们要保证用户能分享高清电影。另外相对于海量的容量，如果单文件过小，那么海量空间也没啥意义。多媒体是促进磁盘发展的动力。文件数会很多跟GFS不一样，云存储的文件数是海量的。因为每个人都会存储他们的文档、mp3、图片……这注定了单机保存全部文件的node是不可能的。需要目录管理我们需要呈现传统操作系统类似的目录管理方式。另外根据云存储文件数量多的特点，我们要提供可靠的检索做文件管理。读写模式特殊性用户对文件的访问模式是一次写入，多次读取，读取支持随机位置的读取（比如视频从中间开始播放）等。另外考虑在用户带宽条件下，100M的文件也算是大文件了，我们要需要支持断点续传功能。另外，存在对单文件的高并发访问。检索和访问的实时性用户上传的数据，在上传成功之后，就应该能访问到完整的数据。并且在检索的时候就能够体现出来。因此不仅要求存储系统要求实时性，而且检索系统也有要求实时性。归纳一下，因为文件太小导致文件数过多，需要专门的目录存储；针对文件的访问模式，我们需要设计一个比较合理的文件格式；提升检索的实时性。文件格式介绍一个文件需要的存储数据：Meta信息和数据块。Meta信息存储这个文件的详细信息，包括文件名、大小、文件类型（doc或者mp3）、MD5、创建者、具体数据块的存放位置、数据块大小，以及该文件格式的版本信息等。数据块是真正存储的文件数据。我们将一个完整的文件，物理切成多块。比如一个1G的文件，我们按照1M为块大小，切成1024块，然后将1024个块数据散列到N台机器中去。从而保证文件具备高并发的特点，而且也能够方便的为整个集群提供扩展能力。然后我们会将这1024个块的具体位置记录到文件的meta信息中，方便访问。因此，我们需要一个逻辑文件的访问入口（WebServer），和存储这些数据块与Meta信息的集群Chunk Cluster和Meta Cluster。将一个不大的文件分散到各台机器上存储有什么好处？方便做负载均衡和集群扩容将热门文件的流量分散到各台机器上，使热门文件的高频访问对后端影响降低。这个文件格式的设计，