关于Cloud Foundry技术全貌及核心组件剖析

　　CloudFoundry是一个PaaS平台，至于什么是Paas, 可以wiki一下，你可以顺便看看 Iaas, Paas还有Saas 。本次课课家教育平台小编将为大家带来关于Cloud Foundry技术全貌及核心组件剖析，大家要仔细阅读~

　　知识分享：

　　开发框架的选择性：

　　当前大多数PaaS云平台只支持特定的开发框架，开发者只能部署平台支持的框架类型的应用程序。Cloud Foundry云平台支持各种框架的灵活选择，这些框架包括Spring for java，.NET，Ruby on Rails，Node.js，Grails，Scala on Lift以及更多合作伙伴提供的框架(如Python，php等)，大大提高了平台的灵活性。

　　应用服务的选择性：

　　CloudFoundry云平台将应用和应用依赖的服务相分开，通过在部署时将应用和应用依赖的服务相绑定的机制使应用和应用服务相对对立，增加了在PaaS平台上部署应用的灵活性。这些应用服务包括PostgreSQL，MySQL，SQL Server，MongoDB，Redis以及更多来自第三方和开源社区的应用服务。

　　部署云环境的选择性：

　　灵活性是云计算的重要特点，而部署云环境的灵活性是PaaS云平台被广泛接受的重要前提。用户需要在不同的云服务器之间切换，而不是被某家厂商锁定。Cloud Foundry可以灵活的部署在公有云、私有云或者混合云之上，如vSphere/vCloud，AWS，OpenStack，Rackspace等多种云环境中。

　　通过以上三个维度的开放架构，Cloud Foundry克服了多数PaaS平台限制在非标准框架下且缺乏多种应用服务支持能力的缺点，尤其是不能将应用跨越私有云和公有云进行部署等不足，使得Cloud Foundry相比其他PaaS平台具有巨大的优势和特色。

　　Cloud Foundry为开发者构建了具有足够选择性的PaaS云平台，它同时支持多种开发框架、编程语言、应用服务以及多种云部署环境的灵活选择.

　　开发框架的选择性：

　　当前大多数PaaS云平台只支持特定的开发框架，开发者只能部署平台支持的框架类型的应用程序。Cloud Foundry云平台支持各种框架的灵活选择，这些框架包括spring for java，.NET，Ruby on Rails，Node.js，Grails，Scala on Lift以及更多合作伙伴提供的框架(如Python，php等)，大大提高了平台的灵活性。

     本文在从架构组成、核心模块功能、源代码分析等角度来全面剖析Cloud Foundry，同时会结合各行业的典型案例来讲解Cloud Foudry在具体应用场景中的表现。

　　架构设计及核心组件：从总体上看，Cloud Foundry的架构如图1所示。

　　图1 Cloud Foundry架构图

　　经过一年多的发展，Cloud Foundry的组件增加了很多。但核心组件并没有变化，增加的组件是原架构基础上的细化和专门化。Stager组件解决了打包(Stage)过程需要操作大量文件且操作时间长的问题，所以它作为独立进程，使打包工作异步进行，不阻塞作为核心组件的Cloud Controller。

　　下面是对Cloud Foundry核心组件的描述。

　　Router。顾名思义，Router组件在Cloud Foundry中是对所有进来的请求进行路由。进入Router的请求主要有两类。

　　第一类是来自VMC Client或者STS的，由Cloud Foundry使用者发出，叫做管理请求。这类请求会被路由到Cloud Controller组件处理。

　　第二类是对所部署的App的访问请求。这部分请求会被路由到App execution，即DEA组件中。简单地说，所有进入Cloud Foundry系统的请求都会经过Router组件。Router组件是可扩展的，由多个 Router共同处理进来的请求。但如何对Router做负载均衡不属于Cloud Foundry的实现范围。Cloud Foundry只须保证所有Router都可以处理任何请求，而管理员可用DNS实现负载均衡，也可部署专用硬件来实现，或者简单点，弄个Nginx做负载均衡。

　　在第一个版本中，Router工作由router.rb来做，所有请求都必须经过Ruby代码处理转发。这个设计简单直接，只是容易引起性能问题，新版中做了如下改进，如图2所示(左侧为第一版本，右侧为新版)。

　　图2 Router工作过程(新旧版对比)

　　使用Nginx的Lua扩展，在Lua中加入URL查询和统计的逻辑。

　　如果Lua不知道当前的URL应该路由给哪一个DEA，则会发一个查询请求到router_uls_server.rb(也就是图2中的“Upstream Locator SVC”)。

　　router_uls_server.rb是一个简单的Sinatra应用，它存储了所有URL与DEA IP:Port对应关系。另外，它也管理了请求的Session数据。

　　这样一来，大量的业务请求在Lua查询过并保存位置后，都由Nginx直接转发，不再经过Router，性能和稳定性都大幅提高。

　　Router的设计中有个难点：我们知道HTTP请求是有上下文的，那如何保证请求的上下文完整呢?简单来说，就是如何保证有上下文的请求每次都可以找到同一个DEA处理?Cloud Foundry是支持Session的，当Router发现用户请求中带了Cookie信息，它会在Cookie里暗藏一个应用实例的id。当有新请求时，Router通过解析Cookie得到上次的应用实例，然后转发到同一台DEA上。这信息与上面的查询类似，会先存在于Upstream Locator SVC中，当Lua知道后会保存在Nginx内部提高效率。

　　小结：kFeedback开发、部署过程中朋友们肯定也会遇到一些问题，也正常。如果大家想要了解相关方面的更深层的内容的话，请关注课课家教育平台!