一般情况下,开发者从无到有开发一个可用于公网访问的HTML5的App应用的流程是这样的:配置开发环境、开发应用、本地调试、租用公网服务器、注册域名、远程部署、远程调试,就算是一个很有经验的开发者,这整个过程还是需要花费不少时间,尤其是面对一个不断更新修改的应用。
WeX5作为HTML5 App的开发工具,很有必要为WeX5开发者提供一个从开发到部署、运维的一体化云平台,实现WeX5之上的DevOps,让开发者更专注于应用开发,而不再关注应用的部署运维。而WeX5也因此由比较纯粹的应用开发工具演变为“开发云”。
对于WeX5开发云来说,在实现DevOps时,其需求场景有两大特点:首先,开发者众多,用于测试演示的应用多,但是访问很少,并发低,资源利用率很低,同时又要求很高的响应速度,另一方面,WeX5开发云还提供在线设计IDE,这类IDE容器非常耗费资源,但是并发占用率不高,用户连续长时间使用的可能性也不大。
这就要求我们的WeX5开发云在有限的成本支撑下能够尽可能地提高资源利用率,并且保障应用的可用性,经过一番努力,我们探索出以下几条途径:
-
智能路由
-
自动启停
-
资源调控
-
动态应用部署
-
容器资源池
首先我们来看下WeX5开发云的基础架构层次,主要是让大家对整体架构有个映像,跟今天主题其实关系不大。
其中,IaaS层由阿里云支持,Monitor层采用Open-Falcon、Prometheus实现,Container Cluster采用Rancher+Docker实现,Controller Gateway由AutoStart、Regulator、IDE Pool、Proxy等组件组成。
下面来详细介绍下我们是如何提高资源利用率的:
应对场景
:统一的访问入口对接各个子网络,环境与环境之间隔离,并且多个子网关之间要能够做到一定程度的负载均衡。
实现逻辑
:创建应用的时候,会根据LoadBalancer集群的负载情况,选择一个负载较少的LoadBalancer作为该应用的路由网关,提供负载均衡及路由转发功能。控制网关接收到访问请求后,根据请求域名与LoadBalancer的映射关系,将请求转发到该LoadBalancer上。如上图所示,ENV_01与ENV_02的Docker网络是隔离的,在同一个环境中,请求域名与LoadBalancer的绑定可以动态调配。
应对场景
:目前WeX5开发云上的应用以开发者测试演示应用为主,这类应用的特点是数量多、访问少,甚至有很多应用创建后访问一两次,就再也没有访问,长此以往,这类应用会逐步占用大量的物理资源,如果按传统方法,直接将这些应用清除,又难以保证不会影响开发者的下一次使用,这就要求我们寻找一个既能为开发者不可预期的访问提供支持,又能保证资源的的最大化利用的解决方案。
实现逻辑
:应用创建后系统默认应用是停止状态,控制网关接收到第一次访问的时候,会调用Rancher API启动该应用,并且在redis中为该应用记录一个生存时间,在该时间范围内,认为该应用是健康运行的,再次接收到的请求立即转发并刷新生存时间。若一段时间没接收到访问请求,生存时间结束,触发事件调用Rancher API接口停止该应用,释放物理资源。
应对场景
:为了最大化地利用物理机的资源,WeX5开发云引入了自动启停技术,物理资源会处于超售状态,超售能够降低成本,最大化地利用物理机的资源,但同时也会带来资源争取的情况,甚至会因为节点上运行状态容器的资源消耗量超出系统负荷,导致节点宕机。
实现逻辑
:Redis中记录应用最后一次访问的时间,Open-Falcon中监控各个Host主机的物理资源,当某项物理资源指标达到预设阀值的时候,触发事件调用Regulator API,计算该主机上最后一次访问时间最早的若干个应用,并调用Rancher API接口将其停止,释放资源。
应对场景
:开发测试过程中的应用往往需要频繁更新调整,对于有依赖关系的应用来说,频繁的中断服务会影响这些应用的可用性,即使是通过灰度滚动升级,也需要不断地调整链接参数。
实现逻辑
:采用Rancher中的Sidekick机制,将整个的Wex5应用分为Wex5 App容器(负责运行时环境)、MySQL容器(负责数据存储)与Deployer容器(负责提供用户数据),当应用代码文件等有更新时,提交到Deployer并执行重启,即可完成整个Wex5应用的更新升级并且保证服务的不间断运行。