CaaS在微服务开发运维中的最佳实践

一个请求进来以后会在每个节点上都会有一个类似路由器这样一个东西,这个路由器的东西可以把请求分发到集群里面任何一个其他的节点上,这样的好处就是不是一个集中式的东西,这有点像负载均衡,也有点像全员参与的负载平衡.如果 CaaS 平台已经用了 Docker1.12 天生就有这个能力了.

2.3 服务发现与负载均衡

如果有人说现在还没到 Docker1.12,那么可以通过一个内部的负载均衡和服务发现结合起来,完成两件事情.一个是服务发现一个是负载均衡,外面的请求进来以后,怎么定位后面的服务实例,请求是由谁来完成的,这是发现服务,可以理解为一个数据库.

后面所有的实例启动以后都会向发现服务报告一下我在这儿.我的IP地址等各种信息,路由器根据的负载把请求传送到一个具体的服务实例上面,这本质上讲是负载均衡,实际上完成了服务发现的功能,这是一个比较容易理解的架构.

我们不喜欢用户写一段脚本自己编排运维这些东西,所以我们说在部署模板描述文件里能不能把这种东西描述出来.

举例,如果接触过 Docker 的会知道这是一个 Docker 的部署模版,描述了一个服务,这是镜像,这些服务之间什么关系,如果没有接触过 Docker,你就可以理解成这就是一个部署模板.

在部署模板中大家都知道是声明式的,而不是编程式的,怎么样用声明式的方式描述刚才我说的这些关系,这些关系就是说现在已经有了的这些基础架构.

首先用户写的这个服务,我对外的80端口被声明成一个；其次就是自动伸缩的能力,右边两个绿色的,我们真正用户提交上来的服务,启动的时候部署的时候直接起两个实例.

还有就是 probe url,让系统平台怎么知道容器里的应用是活着的,这里很简单直接访问80端口根目录,只要是200我就是活着的,如果测试80端口没反应,说明应用就死掉了,以后的流量就别往这儿来了.

我们不需要用户自己写一段脚本做配置,也不需要在服务上挂一个钩子的东西,只需要一个声明的方式表达我想要的结果.解决了在外面我服务发现的问题,这个服务请求一旦进来以后,我就到了后面就是一个负载均衡,从这个页面可以看出一个很也意思的概念—架构即代码.

说明：架构即代码—就是说我描述的不是过程,我要描述的是最终结果,最终结果可以像代码一样被管理起来,这里就反映出这样的一些概念.

2.4 日志集中和分析

刚才是服务发现和服务路由的情况,如果用了 Docker 如果做了微服务以后,日志管理和监控这件事情怎么做.原来如果有五台十台服务的时候,出了问题自己上服务器上拉日志.自己也可以搭建一个 ELK,主要解决的是集中的问题.

作为容器服务平台,就要替用户解决日志集中的问题,把集中的的日志文件通过一个管道送给分析服务,如果容器里应用直接往标准输出写日志,系统会自动把这些日志集中起来.

如果应用把日志写到文件目录里,这个能不能抓去呢?也可以,只要声明一个日志目录的一个标签,说明日志在某某路径之下,那么容器服务也会自动把这些日志收集起来.

日志收集好了,还要分析.日志的集中和分析方案非常多,假定用户在应用已经有了自己的日志和监控,是不是必须放弃掉原来的用系统的这个呢?不是,Docker 很重要的一点是生态,有很多这样的一些开源工具也可以完成这样的任务,都是可以和系统接起来的.

2.5 监控与弹性伸缩

弹性伸缩这件事情实际上听起来很高大上,但是实际上真正运行起来有非常多的复杂性,这里展现的就是如何弹性伸缩,监控系统会把所有的这些指标都监控起来,包括容器的、虚拟机的、网络的,还有其他的服务都监控起来.

定义一个策略,一旦某种情况发生以后需要做什么事情,也是用声明的方式.上面第一句话的意思是平滑后的CPU利用率超过的70%后,可以按照按两个容器的步长增加的速度来扩展.这里没有指定下限,所以这个策略只涨不跌.

我们看这个图,对请求处理上是分布在两个不同的节点上的.云监控发现CPU指标达到了设定的阈值后会通知集群,集群的控制节点会起两个容器.这两个容器是平台调度的,会选择最合适的负载能力的节点去做,这个图里面有两个节点,都有资源,所以这两个新的容器就会被平均分配在这上面.

3、CaaS在微服务运维开发中的作用

3.1 SLA保证

下面这块对大家的影响平常显示不出来,如果出现问题有巨大的作用,这就是 SLA 的保证. SLA 的意思就是作为一个服务提供商,怎么保证实现我说的要做的一些业务指标承诺,比如实现高可用.

（编辑：东莞站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!