B-Cloud 的体系结构

    下图是B-Cloud 的部署图，以此来作为讲解其体系结构的基础。

<!-- @page { margin: 2cm } P { margin-bottom: 0.21cm } -->

      前面已经介绍过， B-Cloud 定位于 PAAS ，也就意味着此平台也提供了一个开发框架（我称之为 GreenTea ），此框架是我做软件开发中逐步积累的一个框架（零零散散写了快 7 年了，并在此基础之上开发过数个应用）。 GreenTea 框架的客户端可支持多种形式，目前实现的有： JSP+Taglib ， Swing ， Web2.0 这三种客户端形式。此框架将会在 Google Source 进行开源。稍后我会上传一个示例程序，更详细的介绍我将在其特定的题目中介绍。

     <!-- @page { margin: 2cm } P { margin-bottom: 0.21cm } -->

      从上图可以看出，除了客户端之外，整个体系由以下几个部分组成：

<!-- @page { margin: 2cm } P { margin-bottom: 0.21cm } -->

1. 应用与资源管理控制台，顾名思义，这个部分主要负责两块内容。其一，应用的注册，版本的管理，应用的发布、扩容、版本的控制。其二，资源的注册、管理和分配。这里资源包括：服务器实例，数据库，文件系统等等。

1. 任务分配器的作用主要是负载均衡和版本控制。当客户端发送过来 HTTP 请求时，任务分配器负责选择合适的版本及服务器实例，并将请求转发过去，这个和普通负载均衡器完成的功能是类似的，但区别在于其和应用实例之间是自动配置的，不需要运维人员参与其中（多数负载均衡器是静态配置的）。除此之外，升级的控制也在此处完成。这是一个很有吸引力的特性，比如：应用升级时，可以做到平滑升级（用户可以不感知应用的版本变化），部分升级和多版本共存。详细信息将在后面的特性介绍中进行描述。
   
   

2. 应用农场，一个农场可以有多台服务器，服务于不同应用的不同版本。服务器实例最好做成统一标准的“集装箱”，便于在各个服务器之间进行动态切换，相互替代。服务器实例可以运行一个或者多个应用实例，具体运行的是哪个实例需要通过“应用与资源管理控制台”进行分配，即服务器实例是虚拟的计算资源。应用发布的过程可以简化为如下步骤：

   • 将一台标准的服务器注册到“应用与资源管理控制台”；

   • 在“应用与资源管理控制台”注册一个应用及其对应的版本；

   • 使用“应用与资源管理控制台”提交一个发布请求，控制台将从注册的“服务器实例”中选择一个或者多个 进行发布。

3. 其他资源，其中包括数据库，文件系统，高速缓存等等。理论上讲，服务器也属于一种资源，由于略为特殊，将其划为一类。

   1. 从上面的结构图中可以看出，这里解决数据库的可扩展性采用的方式是：支持多种部署结构（和我采用的 GreenTea 框架有一定关系），支持常用的：主从库，一主多从，多主多从等拓扑结构。这个地方可能会有些争议，目前比较流行的云计算平台（如： Google App Engine ）多采用非关系型数据库（如： CouchDB 等）来代替关系型数据库，这种数据库的好处是理论上可以无限扩展（ Scale ）。我承认其优势，而且 B-Cloud 平台也可以对其进行支持。但是请不要忘记，就企业应用而言，现在还不能抛弃（甚至轻视）关系型数据库。无论从开发人员还是遗留资源的角度，关系型数据库都是非常重要，不可或缺的。

   2. 对于文件系统的情况，即可以采用本地文件系统，也可以采用当前流行的分布式操作系统，如 GFS ， Hadoop 等等。我已经在 GreenTea 框架的上对文件操作提供了一个简单的抽象（类似于 java.io.File 的接口），可满足大多数情况。此接口可以无缝地切换使用的文件系统（将非分布式的文件系统替换为分布式的），并在一定程度上减少了资源泄漏的可能。

 

      从结构图上很容易看出来， 系统是基本不存在单点失效的情况。您或许觉得资源与应用控制器那个地方可能存在单点失效。但我认为这个问题不大，第一，这个地方完全可以通过集群部署的方式进行解决；第二，即使这个地方单点失效了，也不会影响任务分配器，应用服务器和其后面的资源的运行，只是不能通过管理界面对应用实例进行调整罢了。如果失效了，只要重新启动即可。

      再次阐述一下 B-Cloud 的目标， 就是使用普通的软件和硬件来构建高可靠的，可扩展的，具有良好升级性的应用程序 。从上面的结构图中可以得出结论，一个应用可以同时有多个运行实例，因此不存在单点失效，满足了第一个目标。应用服务器是横向扩展是自动的，不需要运维人员的维护的，满足了第二个设计目标。应用的实例可分属于不同的版本，这个情况任务分配器会根据应用的设定选择合适的服务器实例，这些应用实例之间的 Session 是共享的，可以进行平滑的升级，满足了第三个目标。