传统应用迁到云上的几个方面:
第一,应用的改造。
第二,应用平台要基于PaaS才能发挥最大的价值。
第三,基础设施应当使用PaaS来驱动IaaS。
PaaS的架构模型非常强调监控,监控是从IaaS层、PaaS层、APM、平台对应用无源的监控,甚至应用流量的监控,全部都要有。监控的目标是什么?是为了运维自动化。只有发现问题才能自动恢复,如果你连一开始都没有发现问题,怎么让它自动恢复?说来说去运维就三件事情:
第一,PaaS可以对故障自动恢复。解决故障问题当然故障恢复不是说重启试试这么简单,至少还要Session不丢失。
第二,应用上线、部署应用、升级应用。每次上线运维人员都如临大敌,就怕一个配置错误导致上线出差,PaaS提供了像灰度发布、回滚等等来实现自动化发布。
第三,添加资源。业务量大了就要扩资源,扩资源装机器、装OS、装软件、改配置,工作量也让人生畏,而PaaS通过自动弹性伸缩解决资源扩张问题。这三件事自动化了,运维的很多工作就自动化了。
![]()
云原生应用的容错性设计
第一,你要知道它的故障在哪,这就说明要有好的监控;第二,自动恢复能力要强; IaaS层和PaaS层的监控、PaaS各个逻辑层的监控是一层一层递推的,通过PCF平台你可以聚合各项监管指标,光是容器这一层就提供了两百多个监控指标。
云原生应用的日志设计
日志监控往下发展,就是把日志和监控结合起来。以前,日志和监控完全分开,监控看当前的,日志看历史的,其实二者是完全可以结合的。如果发现错误关键字,可以看日志有哪些地方涉及到这些关键字,在什么地方,跟性能有没有关系,通过平台一目了然。这就是平台要遵循十二要素的原因,它能采集你的日志,做日志和监控的聚合分析。
综上所述,PaaS的价值链是怎么递推?首先是两个方面:应用转成云原生,基础设施升级到PaaS平台。然后可以达到应用零运维、运维自动化的价值,再往前就可以达到Devops、持续交付/持续部署、敏捷业务等价值。
现在,Cloud Foundry在做一个更创新的事情,就是通过机器学习来识别故障模式。其实这个是非常有价值的。做机器学习最缺的是足够多的数据样本,而Cloud Foundry所有的日志可以采集过来,还有监控的数据可以采集到,所以它可以真正意义上地采集海量的数据,使得机器学习有足够的样本提升效果....
Cloud Foundry的架构是一个相当完整的PaaS架构,模块丰富,每个模块都部署在一个或多个虚拟机上。这些虚拟机是自动创建的,由PaaS管理他的生命周期。它的应用部署跟Docker镜像部署不太一样,它是把程序包直接部署。
一个命令行或是一个点击就可以部署,它通过Router到云控制器,云控制器会把程序包传到它的存储服务里,同时启动一个组装器。组装器会按照应用构建包的指令来构建应用,首先看是什么应用,它告诉它怎么构建。然后,就会把镜像构建出来,接着它便告知云控制器说构建好了,云控制器找到一个Diego虚拟机把这个镜像运行起来,起来之后就会注册到路由器,Router探测这个应用是不是正常起来了,正常起来就会对外公开它的服务。这是全自动化的,你只是用了一个命令行,就把你的程序从根程序到运行环境了,这个是Cloud Foundry怎么实现一键部署的原理。