有段时间没写文章了，很快就大学毕业了，放松了一段时间，大四的生活过得有些惬意，放松的太久了，重新紧起
来有些难，但是内心一直在不断的鞭策自己，今天忍不住了，决定重新开始写文章。告诉大家这个博客还要继续更新，
没有荒废掉。
这篇文章简单记录一下我的云计算平台实践，云计算这个概念，总是被不断的提起，在大三的时候就关注过一段时
间，但是当时一直停留在理论阶段，没有做什么实际的东西，所以就一直没有写任何关于云计算的东西，因为我一向是
先实践，然后总结，再写文章。大四前半段，带着我的团队把一个项目的二期开发做完，然后下半段先是考了一个烦人
的考试，然后才着手将我的云计算平台实践出来，平台的功能很少，因为只是自己做着玩，初衷是希望能够为学校实现
一个云存储平台的，统一学校的数据源，方便学校今后的网络建设和科研，为学校多做些贡献。但是学校手头也紧，公
费买个服务器都困难，只想安于现状。所以后来只能自己做着玩了，不能因为没有实际需求就不做了。
这个云存储平台是服务即平台模式的实践，提供WebService和API供其他应用系统调用，实现了20个接口，因为只
是模拟用的，数据模型做了简化，只保留核心字段。架构基于Hadoop+Hbase+EJB，大二的时候学了EJB但一直没有实
践过，一是因为没有遇到必须用这个技术的项目；二是考虑到技术门槛，不方便后面的维护。实现平台过程中遇到一个数
据节点不能为0的错误，因为报错实在是不太明确，让我一直以为是配置文件的问题，困扰了一段时间，后来发现是关于
用户权限的linux间无密码互访有问题造成的，这个问题本身简单，但是因为报错不明确，误导了我的判断。
云计算技术还在发展中，随着很多公司的采用，已经趋于成熟。任何技术都需要通过实践来发现问题解决问题。目前
来看，云存储一定程度上可以取代关系型数据库，关于数据库事务和高级查询可以借由第三方组件实现。松散的数据结构
更加利于敏捷实践，数据模型的字段可以更灵活的变更，我的云存储平台数据就是把教务系统的一些关系型数据模型过渡
到基于键值对的松散结构中的。对于一些本身就具有映射关系的字段，甚至可以简化到一个键值对关系中来。把所有关系
型数据都打散成为松散数据，确实是很颠覆传统思维的。但是有的时候逆向思维正是解决瓶颈问题的办法，比如关系型数
据库很难低成本的做到在限定时间内从几TB的数据中，排序并拿出TOP50W的数据。
Hbase本身的一些机制，可以从分布式文件存储层面就为所有数据提供缓存，对于一次写入多次读取的数据效果尤其
显著。我虽然没有看过twitter的数据层实现，但是如果让我设计，我会把最占用存储空间的数据部分，也就是一次写入多
次读取的微博和评论内容部分写入NoSQL中，稳妥起见把其他对安全性要求高的隐私数据部分写入MySQL，但是我仍然
可以把常用字段也同步到NoSQL中去以便提高系统性能。这可以看做是云存储最常见的一种实践方式。云存储的另一种常
见实践则是基于文档化的分布式存储，把视频，图片，音乐，文件以键值对的形式存储，这些媒介的共同特点都是占用空
间大，一次上传，多次读取。这两者其实可以归为一类。即使是多次写入，少量读取的数据也可以实现一个数据缓冲层，
应对频繁变更，然后定时定量持久化数据。所以存取比重不会影响对云存储的使用，因此才有了我之前把关系型数据模型
完全转化到松散型的做法。
利用Hbase本身的一些设计特点可以让我们从松散表结构设计上提高系统的性能，比如family列相同的部分会在物理上
存储在更近的节点上，所以在从关系型到松散型过渡的时候，可以把family列设置为表名，把label子列设置为属性字段，
这样同一个表的数据可以在物理上更加紧凑，便于系统更快的取出同一数据模型的相关属性。family列的定义和修改需要对
Hbase作类似于传统数据库的数据定义，而label列则不需要定义直接可以使用，通过这个特性可以使表结构字段动态化，从
而在数据持久层面实现动态化。对于功能独立的本身具有键值映射关系的属性则可以不使用上述的做法，而采用family列存
储键属性名称，label列存储键属性值，value列存储值属性的值的方法。这是松散模型设计可以采用的一种实践策略。
在业务服务层面分离成两个层，一个层作为数据操作层，负责对数据操作和事务处理，另一个层作为业务服务层，负责
业务逻辑的拼装、数据验证、身份验证等工作。接口设计方面要保证接口的合理性，清晰性，重用性。目前能想到的就是这
些了。
架构如图：