云原生应用架构和原理

云原生各方各面都在讲,为什么现在会这么热?跟容器也不无关系。云原生首先要把传统的大应用拆成小的应用,小的应用肯定适合在容器运营,所以它与容器相辅相成。现在业界有一个误解,部署在容器里的就是云原生,其实这不完全正确。
云原生最重要的是应用框架,就是你的应用要改造成适合云原生的。这里包括两方面:一个是程序应用框架本身就适合在云上面运行;二是应当有一个云部署环境。(PS. 容器肯定也是一个比较关键的技术要点。)
传统应用的需求是比较固定的,互联网应用的需求是持续发展的,最典型的就是我们的手机应用,需要持续不断的在升级,所以它的主要要求是敏捷。以前,做项目要半年,现在可能几周、几个月就要上线一个新版本,你要上线就要做测试,从开发到测试整个需要持续,就有了持续集成、持续交付这个概念。还有一点就是访问量大了平台还要相应变大,所以应用平台的弹性非常关键的。互联网业务是二十四小时不停的,随时会有人上网,所以就要求24小时在线服务,无论是部署应用或是系统升级,都不能不断业务,这就带来了应用发布的灰度发布要求,以及系统在线升级的要求对于系统在线升级,Pivotal Cloud Foundry有一个公有云,类似于AWS。这个云从2013年运行到现在,升级了无数的版本,快的两周升级一次,慢的一季度升级一次,PCF从运行之初到现在产品的升级从来没有停顿过。
对于上述提到的问题你需要的就是一个云原生架构,它有两个方面,应用框架和平台。灰度发布、弹性都是由平台来提供,有些跟应用程序框架相关的则是框架提供。

云原生应用的特征

云原生应用的特征首先要符合十二要素
十二要素是云原生的重要理论之一,对于十二要素,举一个最简单的例子,日志。按照云原生十二要素的要求要把日志做成事件流,不要写到日志文件。写到日志文件,放到云上,就要放到一个特定的路径或者一个目录下,对于整个日志的采集是比较困难的事。但是如果放在流的话,PaaS平台就会接管这个流,这样的话只要日志是流式放到云上就不用管了,平台会自动把日志采集过来。
其次,要有微服务,就是程序要是一个微服务的程序,不能再是传统的单体服务,或者我们讲的巨石应用;
第三,自服务的敏捷基础设施,应用部署在云上需要资源、需要虚拟机、需要CPU、需要内存,这些它要能自供应。开发者只要把自己的要求提出来,比如我要跑个应用需要五个容器,不用关注需要多少虚机,系统发现虚机不够的时候会自动创建,这一点也是非常关键的;还有就是基于API的协作、反脆弱性等等,综合来说有几个方面:程序架构、监控、自动恢复。

云原生应用架构和原理

PCF提供对CNA的支撑:PCF从开发到测试能自动供应环境和服务,满足自动化的要求,按需的、自动化地进行弹性伸缩,而且有自愈能力,还有自动的路由/负载均衡。
云原生非常关键的一点是要有平台的支撑,这个平台就是PaaS平台。它的出现其实是要解决三大问题:
第一,业务敏捷性。这个就是说你要开发敏捷,部署敏捷,支持移动计划等等。
第二,应用和系统的可用性。应用出现故障,容器出现故障,虚拟机出现故障平台都能自动恢复。
第三,运维自动化。有了运维自动化才能做DevOps,这就是PaaS云业务的驱动力。

PaaS的架构模型与业务价值

传统应用迁到云上的几个方面:
第一,应用的改造。
第二,应用平台要基于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怎么实现一键部署的原理。

Pivotal Spring微服务框架

Spring Boot跟十二要素密切相关,遵循了一些十二要素的要点。它将你的代码打包为可运行的包,比如通过Java就可以启动,程序到哪里都不需要去改。它不生成war包/Ear包,而是生成整个运行环境,直接把服务器嵌进去,还内置了很多监控,而且是端到端的业务监控。如果大家做云原生开发,一定要研究Spring Boot框架。
除了Spring Boot, Spring Cloud框架也是微服务的重要框架,目前Spring Cloud推出了20多个框架,有些已经成熟,有些还在成熟过程中。一个成熟的例子就是Spring Zipkin,它是做微服务监控的。我们做微服务一个很大的问题就是调用链的链接,像在Netflix,一个页面点击会穿到几十个服务,极端的时候的有上千个,到底相互之间是如何调用的,是怎样的一条调用链呢?Zipkin就是做这样的事情,它可以知道你是怎么调用的。我们以前做开发是一个大程序,调用都是在内部,比较容易监控。现在微服务化,一个调用从这个服务跳到另一个服务,很难监控,所以这个时候需要另外一套工具来做监控它的调用链。
Netflix微服务框架,是基于Spring做的,开源之后,我们基于它的开源又做了Spring Cloud的开源,就是Spring Cloud微服务的基础框架。目前,服务注册、服务发现、配置服务和熔断监控这几个在微服务里做的非常成熟了。微服务在任何时候动态部署一个服务都是可以动态发现。比如应用实例的自动发现,就是注册的时候有实例信息,调用方可以动态发现新增实例,就会自动调到新增实例。
另外值得一提的服务是配置集中管理。前面十二要素里讲,所有的配置不要写配置文件,是通过配置管理放到配置服务器里。配置、属性都不放在文件里,这是怎么做的?程序启动的时候,Spring会去自动加载你的配置,如果配置发生变化,它怎么动态地知道?这里有一个刷新的机制——当动态把一个配置服务改了,一刷新,配置服务器就会自动通知配置客户端去更新配置,这是一个很好的架构。最笨的方法是每次读写配置都去查配置服务器,保证了时效性,牺牲了性能,另外一种方式还要定时去查或是过期配置,中间就会错过一些更新的配置。

在介绍一下异常隔离, 一个调用链,一个服务坏了会影响到前面所有的调用,怎么控制调用出现异常而把影响隔离在最小的范围内呢?就要借用熔断开关的机制。

PaaS/CaaS的技术发展和分析

最后我们来谈谈PaaS/CaaS行业的最新发展。PaaS和容器发展可谓势如破竹,最新的技术发展包括以下几个方面:
第一,容器标准化。我们不要再执著于用哪个容器,不止是Pivotal,包括Google都在推动这个标准化。竞争更多的是在容器的集群管理、资源调度上。但是集群管理、资源调度的选择比较多,比如Docker的有Mesos\K8s\Swarm等,生态圈多,多往往也就是杂,生态圈多有好处也有坏处,选择多了对选择者来说是个难题,考验选择者的眼光,如果眼光好,选择未来有发展前景的集群管理的话,你就做对了;如果眼光不是太好了,可能三年后在竞争中失败了,前面做的工作就报废了。所以这个是非常关键的,当然CF的PaaS没有这个问题,就是一个选择。比如去年Mesos很热,今年它的风头就被k8s盖过了。
第二,技术发展比较快的是运维自动化和监控。像无Agent的非侵入式监控、APM、日志采集和深度分析也是目前比较关键的领域。

微服务框架进展速度很快,Spring Cloud从去年的几个框架到现在二十几个,未来还会越来越多。现在Spring 微服务框架基本属于业界垄断性的优势,就像10年前的Spring MVC,而且Spring微服务框架作为Spring大框架集合的一部分,天然就有海量的群众基础。
PaaS/CaaS多集群管理也发展很快,以前PaaS都是一个点一个点建,集群不大,现在集群越来越多了,怎么多集群管理?K8s和CF这方面今年都有较大进展。此外还有生产可用的功能性增强,无论CaaS还是PaaS发展的年限都不长,都是从简单功能开始,缺乏一些企业生产级的功能,比如像各种安全性的支持, CF发展的时间更长,在实际的生产应用更多,生产级的功能也趋于丰富了。