B-Cloud 的特性
<!-- @page { margin: 2cm } P { margin-bottom: 0.21cm } H2 { margin-bottom: 0.21cm } H2.western { font-family: "Arial", sans-serif; font-size: 14pt; font-style: italic } H2.cjk { font-family: "宋体"; font-size: 14pt; font-style: italic } H2.ctl { font-family: "Tahoma"; font-size: 14pt; font-style: italic } -->
王婆卖瓜，我先自夸一番，先简单地介绍一下 B-Cloud 的主要特性。这些主要特性都是在不增加开发和部署的方式和难度的情况下即可实现。
升级
升级，坦率地说，我认为 这是企业私有云的一个非常 重要的特性。以前，我们升级版本的时候往往会很痛苦，运维人员不得不等待用户 下班了之后再进行切换（否则肯定是骂声一片了）。 B-Cloud 平台可以平滑的进行升级（当然，这种升级需要考虑新老版本是否兼容 ！），即在不影响在线用户的情况下，进行版本升级。
目前， B-Cloud 包容如下升级特性：
-
平滑升级：升级时提供给用户服务是不中断的，用户是不感知的。
-
部分升级：可对某个版本进行试点运行（比如：按照指定 的 IP 地址进行版本分配）。
-
支持多版本同时在线。
动态扩展（Dynamic Scale ）
动态扩展，这个词包含了两个关键词，动态和扩展。静态的扩展使用 Cluster 的方式是很容易 做到的 ，但是做到动态化就比较困难了，多数 Cluster 的配置往往都需要管理员参与，手工配置 。扩展则可以分为几个层面，按照运算能力（ CPU, 内存），网络带宽，文件系统，数据库存储。服务器的动态扩展不必说了， 非常明显。 针对数据库的情况需要特殊说明一下，目前大多数云计算都采用了非关系型数据库作为存储以达到无限可扩展性（ scale ）的目的。但是，使用“非关系型数据库” 在目前的 企业应用中很难成为实现，准确地 说短期内很难实现。问题是非常明显 的：这种 面向文档的数据库需要改变开发 ，部署和维护的方式，对已经存在的系统无法兼容 ，等等。特别是企业应用 ，仍然需要以关系型数据库为主。因此，这个地方的动态扩展性是不适宜使用文档数据库 （对于绝大多数应用，无限扩展也是意义不大 的）。 所以，在数据库层面 是通过支持多种数据库拓扑结构来达到扩展的目的。 B-Cloud 的可以支持 一主多备，或者多主多备等多种拓扑 结构， 可满足绝大多数的需求。当然， B-Cloud 也支持面向文档的数据库。
高可靠性（High Availability ）
有很多手段可以达到高可靠性，但是要找到一种廉价的，方便的方式并不是很容易，往往需要多种 手段相配合 ，操作系统层面的，中间件层面的，数据库层面的，不一而足。 Cluster 是一种方式，但是 Cluster 的动态性较差，需要过多的人工参与，“动态”是其最大的死穴 。
灵活性（Flexible ）
B-Cloud 没有对运行环境和软件做过多的假设，这样就充分地保证了他的灵活性。体现如下：
-
支持多种应用服务器，并可混合部署，即 ：一部分应用服务器是 Tomcat ，一部分应用服务器是 Resin 。
-
支持服务器虚拟化和非虚拟化。
-
数据库可 支持单数据库， Cluster 数据库 ，主从等多种拓扑结构
-
支持分布式文件系统和非分布式文件系统
-
多客户端： Web2.0 、 JSP 、 RIA 、 RichClient （注：此特性由 GreenTea 框架决定）
-
支持 多种通信协议： HTTP 、 JSON 、 XMLoHTTP...
-
未来 可集成其他框架，如： Spring ， Hibernate 等
低标准，高速度，轻量级（ Plain ，Fast ，and Light Weight ）
看到这个特性的时候，如果你是销售人员，估计你已经开始骂娘了。这个你也好意思往上写，要老子出去的时候怎么吹水（口吐莲花）！老子销售的时候怎么也得说才是全宇宙最先进的设计理论， NN 层架构设计，使用最先进的服务器，光安装程序就“ N”G,@#@$#@#$!$%^$%^&%$%$ 。 我想大家听过“群体智能”这个概念（群居性生物通过协作表现出的宏观智能行为特征被称为群体智能）。这是我的目标，通过多个简单的服务器实例个体，来达到总体性能上质的飞跃。因此，目前采用的尽可能少的依赖 ，保证程序的可靠和稳定。当前框架使用的主要技术指标和第三方类库包括 :
-
JAVA SE 6
-
Tomcat 6.0
-
Apache commons
-
系统大小 < 10M
-
Jar 包个数 < 20 个
-
启动速度小于 20S 。
-
本地测试，即不需要发布到应用服务器上即可进行服务器端程序的测试 。
自适应（ Self-Adapting ）
在应用启动的同时，系统也启动了若干后台任务。有个任务负责监控 系统的 压力情况，并根据配置 自动调整服务器实例的个数。另外，也是 为了保证高可靠性，系统也会 自行调整运行的应用实例数量。
标准化（ Standardization Based ）
标准化的革命，在国内最著名的就是始皇帝搞得那些东东了，统一文字，统一钱币，等等。国人还是比较感性的，不像老外 ，什么都喜欢用数字度量，就连最虚无缥缈的智商都可以按数字排序。这样的好处是毋庸质疑，如果我测量了一台服务器的大体性能，如果压力增加了，我再 配置多台服务器就 OK 啦，很容易度量和测算。更为关键的，标准化了之后，服务器之间可以相互替代，某些应用可能只在一年中的某个时间才会大量使用，这样我们就可以其空闲的时候 借用这台服务器的运算和存储能力。标准化的好处我不说大家也都应该很清楚啦。