前几章将有特点的公有云计算平台都介绍了一下，这里费下嘴，不是说只有这些云平台，实际上有很多，到现在Bat、360等都得云计算平台有涉及，方向、功能大体相似，我们常用的网盘算是其中之一。通过前面云计算的介绍，云计算相关的虚拟化、并行计算、主机管理等技术，我们也积累很多东西，现在就开始应用到实践中。
笔者认为可以按照数据的使用方式，将应用分为三种：以计算为中心的应用（统计计算，模拟计算，图像、信息管理系统，这类单个计算所需数据量小，数据传输代价小，能够实时处理），以数据为中心的应用（互联网搜索公司、数据挖掘、人口统计、日志分析，输入数据量较大，传输代价高，需要分布式并行处理），需要兼顾数据与计算的应用（采用分而治之的方法，根据不同的功能模块采用不同的技术）。
对于这么应用，我们有不同的架构选择，以计算为中心的应用架构选择，除了本机采用多线程编程外，通常可以把计算所需的数据分发到多台计算机上同时计算，一般这样的应用计算所需数据量较小，数据传输花费时间少，侧重于并行计算，而不必关注数据存储问题，前端因特网应用可以使用负载均衡器，后台的大计算量可以选择Platform Symphony等软件来解决。
以数据为中心的应用架构与以计算为中心的最大区别就是计算所需的数据”量“，当需要传输的数据量很大时，数据传输的时间远远大于处理的时间，单纯提高速度就没有了实际用处，于是，Google提出了MapReduce计算框架，他将数据最初产生时就分布存放在分布式文件系统中，每一个数据存储节点同时也是计算节点，大大节省了数据传输时间，提高了计算速度，算是目前较为有效的离线处理方案，后来就有了实时处理数据框架Spark，所以以数据为中心的应用可以采用MapReduce架构（比如hadoop实现）构建应用计算环境。
需要兼顾数据和计算的应用架构选择，比如Google的搜索页面，它采用前端页面使用负载均衡器提高用户的响应速度，后台大数据量计算采用MapReduce架构解决，总之，就是分而治之，转化为以数据和计算为中心。
其实，MapReduce框架并不能解决所有的问题，大致有这么三点：一、目前很多应用都是集中式存储的，出于各种考虑，多数用户不会使用HDFS这种分布式文件系统，那样就使用不了MapReduce框架；二、现有的MapReduce实现，数据都是分散式存储的，这样势必给数据的传输和同步带来新的问题；三、MapReduce计算节点是和数据相关联的，需要将数据分发到所有的工作节点上，而实际情况是，一般数据只存在整个集群的部分节点上，这样有时就不能充分的利用计算资源。
除了MapReduce框架的问题，现有的云计算技术还存在很多问题。因为我们说了那么多的云计算产品，他们都是针对某一方面问题而产生的解决方案，当整合时，各种问题也就随机产生：一、NoSQL数据库API不兼容，不同厂商提供的数据库操作方式不一样，同样的插入功能不尽相同，尽管他们在设计上相似。这种不同会导致当选择了某种特殊NoSQL数据库开发应用后，很难将应用迁移到其他云计算平台上；二、各公共服务提供商所提供的服务不同，具体的看下图：
针对上面提到的问题现状，我们也有相应的解决办法。我们知道在传统的关系型数据库中,也遇到过同样的问题，当时是创建了SQL标准数据库访问语言，开发了hibernate，DataNucleus等轻量级的ORM开发组件，同样，对于新兴NoSQl数据库，针对java语言，几乎所有的NoSQL数据库都支持JPA标准，注意这是个标准。
JPA（Java Persistence API）实现了存储对象向不同数据库存储的相互转化，总体思想和现有的Hibernate、DataNucleus等ORM框架大体一致，总的来说，JPA包括以下两方面技术：一是ORM对象关系映射，ORM简而言之就是将java类中字段、名称和数据库的列名、表名关联在一起，JPA支持XMl和java Annotation（注解式编程）两种元数据的形式；二是统一标准的数据库编程接口，JPA提供统一的数据库编程接口标准来操作实体对象，执行查询，插入，删除，更新等操作，以笔者经验，JPA能很好解决90%的数据库操作，对于个别的大数据量、特定的操作需要开发人员自己完成。具体JPA的实现操作我会专门一文来介绍。
最后就是实战基于云计算平台的文件共享系统需求分析，请看下回分解。
原文：http://blog.csdn.net/zeb_perfect/article/details/42297163
