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