大会实录|清华徐葳:人工智能让数据中心更好运维

杨y 发表了文章 • 0 个评论 • 2 次浏览 • 3 小时前 • 来自相关话题

 
嘉宾介绍:徐葳,清华大学交叉信息研究院助理院长,青年千人学者,博士生导师,UC Berkeley 计算机系 PhD,曾供职于 Google。主要方向为基础架构的监控,日志等,目前以分布式系统以及人工智能等方向为主、包括人工智能、隐私保护、反欺诈等内容。
以下为徐葳在数人云PaaS Innovation 2017,构建灵动新IT大会上的演讲实录。清华大学数据中心运维那点事儿

我(徐葳)显然是个科研人员,同时还管理很多行政事务等,但有些人“命不好”,就是系统管理员的命。所以花了很多时间去管一个IT系统,学院的机房、云平台,基本上夜里大家都睡了,还要登陆上去看看日志,该修点什么就修点什么,我这个人有个毛病,就是看不得机器坏了,看不得什么东西不行,就得马上修好。

清华有系统管理员,就如同我一样都有系统管理员病,很喜欢做系统管理,但他们都是白天上班,因为没有加班费,所以不好意思让人晚上加班,所以晚上一般都由我来管。

这个数据中心做的是人工智能,现在人工智能很热,科研领域清华做的非常前沿,这是最最聪明的应用,但是跑在最最傻的基础架构上。

因为曾经供职于Google,非常想在清华复制一套Google的架构,但这并非一两个人就能开发出来。所以,即便在Google,唯一不能用的地方就是系统运维领域,这是灯下黑,这也是本次讲演的主题叫:“数据中心与智能”。
今天给大家分享几个方面:
首先,数据中心运维,这是和百度合作的一个数据分析的事情,会给大家展示几个有意思的结果。其次,讨论下现在的新架构,Deep Learning深入学习,如何维护这个框架,怎么把数据中心改造成可以进行支持。最后,数据中心现在如此复杂,怎么能再利用一些人工智能的东西放在数据中心里帮助运维。
如何平衡硬件+软件+运维?

首先,这是和百度合作的一件事,百度有很多的机器,有个部门叫硬件运营部,他们收集了很多故障报修,各种产品线,各种不同的产品报修了硬件,硬件运维部就派人去处理一下,大部分处理的方法就是找厂商换新的。所以叫做出了问题的Ticket,几年内积累了29万个,我们可以帮助它的地方是,到底什么东西坏了,拿出来看看,什么时候报修的,大概什么故障,什么部件坏了,这里有很多结果,但因为时间关系,就不挨个赘述了。

报修了一个故障,多长时间会修?如同百度这样管理非常好的公司,报修之后多长时间会有人去处理?不是说修好它,修了不一定能够修好,但至少是去修了,该换什么就换什么,硬盘报错,坏了,就换一个硬盘。

具体时长看起来会非常奇怪:平均需要42天报完错可以修,中位数的修理时间是6.1天,其中有10%的是140天之后仍然没有修,但是没人修并不代表永远都不要这个东西了,过了200天以后仍然有人去处理它,而并没有忘记。
感觉这个时间过长,到底是因为什么?因为机器太多了?又或者系统管理员太忙了?其实未必。

因为如百度、Google这样的公司,系统架构非常容错,硬件出问题是不可避免的,它坏了,既然能容错,就像四个轱辘掉了一个还能跑,为什么要去修呢?所以逻辑是有一个超级容错的系统,在运维时对故障就没有那么敏感。从好的方面来说,可以省钱,因为一次修一个也得跑一趟,修若干个也得跑一趟,因此还不如一次批量的修。
当然硬件损坏无法避免,是否能降低一些容错的复杂性呢?大家目前越来越多的都在讨论这件事,就是三者的平衡,运维的可靠性、软件的成本、硬件的成本之间的三者平衡,现在越来越重要了。

另外,不管如何运维,运维的系统都是非常重要的,任何运维都不是登到界面上去敲几行命令,然后就派出一一件事,这个都是无法做到的,所以不管如何,系统的运维,从一个地方生成这样配置的操作,从一个地方生成的部署,都很重要。
以上讲的是硬件、软件、运维,这三个部分成本如何平衡,现在这个状态下,尤其是大规模的数据中心,有可能和过去小的企业数据中心不同。基于数人云的Docker管理环境

现在深度学习火了,每个人都想要深度学习的机器。最开始一个人要的时候,没关系,从桌面虚拟机集群拆出两台来,装上GPU,自己去用。现在这样的人多了,装了60几块GPU仍然不够,所以这种集群如何共享这60几块GPU,非常麻烦。

后面做了一个什么事情呢?找数人云做GPU虚拟化,虽然GPU支持虚拟化但太贵所以不买,买的都是消费者级别的GPU,因为便宜。当它不支持虚拟化时联合容器,所以将GPU集群上放上了Docker,又找了数人云,帮助开发一个数人云的管理系统,是基于Mesos的开源软件。同时写Mesos的人是我在伯克利的同学,因此对它的印象很好。

将来的就是这样的架构,好处是解决了一个问题,即服务封装,DeepLearning这事真的不复杂,如果你玩过,会发现很简单,其实就是找一个开源的软件框架,上面有很多模型,将其下载下来,都是开源的,这些模型甚至都是训练好的,可以跑人脸识别应用,或者跑其他的什么识别应用,虽然没有专业跑的好,但也不会太差。
但它的问题在于是基于框架,尤其在中国,版本不一样,升级版本升级的特别快,随便动一个升级,其他人都烂了,而不同人就要不同的版本,为什么,因为它下的那个模型是基于某个特定版本开发的,在别的版本上跑不出来,所以在这种情况下,大家去到无数多个配置好的镜像和环境,这个场景挺好,Docker、数人云有它的界面,将这个东西配置好,这种Docker配置的这种Docker,只有这个Docker里面用的是那种版本的东西,因为Docker是一层一层的,不用做那么多镜像,只有一点点区别没有关系,那么多借点有一点点区别,占不了那么多空间,好多镜像,各自用各自的Docker。
所以这解决了一个叫软件分发部署的问题,但有一个问题,总得有训练数据,有点什么东西在里面,完成后改了配置等等,这些东西不可能存回到那个镜像里头去,就想那怎么办呢?可能过了两个星期之后还用呢?所以就不上Docker,留着,等两个星期后再说,但两个星期后做别的项目去了,机器就卡在那里,所以这是个问题,存储它的周边结果存在哪里,是个好大的问题。
简单的方法,有OpenStack,集群上500块硬盘总是有的,挂上NFS,每台机器上面有一个Ceph的NFS,把这些东西对接好,想把这个东西存在那个上面保证安全的,关了以后重启时再挂回来,设计了这样一套存储。
那有什么问题呢?DeepLearning的模型也很大,有些人直接在上面跑,本想让它存储一个备份数据用,跑到上面做一下其实还是存在本地。

所以后来自己改造了存储的架构,做了一个开源项目Alluxio,也是伯克利实验室的一个同学做的。

Alluxio缓存非常有用,它还为Ceph和NFS适配了一个接口,还有Hadoop集群,HDFS里面也有几百块盘,将这三种东西适配城了两个借口,适合放在Docker里面,也适合放在Hadoop里面,且它加了些缓存,这样用机器人内存吸收了很多流量,上图就是大概的基本架构。

HDFS也可以支持,同时也能顺便支持Hadoop,但是如果有一些大的文件,愿意用HDFS的,就用HDFS。

有写机器内存还蛮多的,就是当年趁内存时买了一些内存,还是很有用的,可以将内容缓存住。分布式内存很有意思。用人工智能帮助数据中心运维

最后说一下很多做DeepLearning的程序,这张图片解释了一个词“复杂”,OpenStack觉得自己很干净,为什么?拿个笔都能画出来,但是这张图很复杂,复杂的原因不光是因为有这么多图,凡是看见的都是数据库,数据库是一个持久性的状态,每个组件里都有自己持久的状态,那如怎么保证一致?讨论了这么久分布式系统的一致性,它一旦跨了组件,尤其是跨了开源项目,谁也不会再说这件事。

但若组件坏了,里面还有一个复杂的结构,它一层一层的封装起来,所以什么东西坏了,你可能根本不知道,没坏的时候什么都特别好,但坏了就会很麻烦。
我是个很好的系统管理员,这点特别有信心,但是搞不定这个,因为我不是每天都在配这个,记不得这些东西到底在什么地方,随便查一个什么东西,后面的参数那么长,咱们记不住,但别人天天都在做当然可以记住。

那么,如何能动呢?我们说通过挖掘日志、系统里的状态、跑一些系统里的命令、看一些系统里的数据库,在里面找一些相关的事情,这是纯从样子上找到的,跟语义没有关系。比如ID长那样,那个ID就是ID,IP地址就是IP地址,将这些东西都找在一起,把这些关联性插在一起,就能生成知识图。

另外,为什么三台机器一起坏了,有可能用户只看到一台机器坏了,但其实另外两台也是如此,因为它坏的原因是一个物理机,要坏肯定是三台一起坏,所以都可以找到系统里的一些东西,这有多少个节点?看这个系统看三天,120台物理机不算大,待该有60多个存储的借点,120多个虚拟机的节点,大概出来的结果是几千万个状态,如上图所示,所以可以想象为什么这东西老坏。

最后总结一下,运维是个什么样的过程?刚才说到DevOps,过去的系统管理员如何适应DevOps是一个非常大的挑战,因为DevOps,运维的人是靠开发程序来自动化运维数据中心的,这是必然的趋势,听起来都对。但DevOps推广起来非常难。
DevOps想要推行,一定要把DevOps这些东西的接口配置到过去的系统管理员能懂的那些地方,基本的意思是,预生几个命令行,别说那么多分布式的东西,感觉就是几个配置文件,点点什么东西,这个接口怎么配置,是一个非常大的挑战。
以上是小数整理的徐葳教授在PaaS Innovation 2017上的演讲实录,后台回复“1116”即可下载本次大会的PPT资料。 查看全部
 
嘉宾介绍:徐葳,清华大学交叉信息研究院助理院长,青年千人学者,博士生导师,UC Berkeley 计算机系 PhD,曾供职于 Google。主要方向为基础架构的监控,日志等,目前以分布式系统以及人工智能等方向为主、包括人工智能、隐私保护、反欺诈等内容。
以下为徐葳在数人云PaaS Innovation 2017,构建灵动新IT大会上的演讲实录。清华大学数据中心运维那点事儿

我(徐葳)显然是个科研人员,同时还管理很多行政事务等,但有些人“命不好”,就是系统管理员的命。所以花了很多时间去管一个IT系统,学院的机房、云平台,基本上夜里大家都睡了,还要登陆上去看看日志,该修点什么就修点什么,我这个人有个毛病,就是看不得机器坏了,看不得什么东西不行,就得马上修好。

清华有系统管理员,就如同我一样都有系统管理员病,很喜欢做系统管理,但他们都是白天上班,因为没有加班费,所以不好意思让人晚上加班,所以晚上一般都由我来管。

这个数据中心做的是人工智能,现在人工智能很热,科研领域清华做的非常前沿,这是最最聪明的应用,但是跑在最最傻的基础架构上。

因为曾经供职于Google,非常想在清华复制一套Google的架构,但这并非一两个人就能开发出来。所以,即便在Google,唯一不能用的地方就是系统运维领域,这是灯下黑,这也是本次讲演的主题叫:“数据中心与智能”。
今天给大家分享几个方面:
  • 首先,数据中心运维,这是和百度合作的一个数据分析的事情,会给大家展示几个有意思的结果。
  • 其次,讨论下现在的新架构,Deep Learning深入学习,如何维护这个框架,怎么把数据中心改造成可以进行支持。
  • 最后,数据中心现在如此复杂,怎么能再利用一些人工智能的东西放在数据中心里帮助运维。

如何平衡硬件+软件+运维?

首先,这是和百度合作的一件事,百度有很多的机器,有个部门叫硬件运营部,他们收集了很多故障报修,各种产品线,各种不同的产品报修了硬件,硬件运维部就派人去处理一下,大部分处理的方法就是找厂商换新的。所以叫做出了问题的Ticket,几年内积累了29万个,我们可以帮助它的地方是,到底什么东西坏了,拿出来看看,什么时候报修的,大概什么故障,什么部件坏了,这里有很多结果,但因为时间关系,就不挨个赘述了。

报修了一个故障,多长时间会修?如同百度这样管理非常好的公司,报修之后多长时间会有人去处理?不是说修好它,修了不一定能够修好,但至少是去修了,该换什么就换什么,硬盘报错,坏了,就换一个硬盘。

具体时长看起来会非常奇怪:平均需要42天报完错可以修,中位数的修理时间是6.1天,其中有10%的是140天之后仍然没有修,但是没人修并不代表永远都不要这个东西了,过了200天以后仍然有人去处理它,而并没有忘记。
感觉这个时间过长,到底是因为什么?因为机器太多了?又或者系统管理员太忙了?其实未必。

因为如百度、Google这样的公司,系统架构非常容错,硬件出问题是不可避免的,它坏了,既然能容错,就像四个轱辘掉了一个还能跑,为什么要去修呢?所以逻辑是有一个超级容错的系统,在运维时对故障就没有那么敏感。从好的方面来说,可以省钱,因为一次修一个也得跑一趟,修若干个也得跑一趟,因此还不如一次批量的修。
当然硬件损坏无法避免,是否能降低一些容错的复杂性呢?大家目前越来越多的都在讨论这件事,就是三者的平衡,运维的可靠性、软件的成本、硬件的成本之间的三者平衡,现在越来越重要了。

另外,不管如何运维,运维的系统都是非常重要的,任何运维都不是登到界面上去敲几行命令,然后就派出一一件事,这个都是无法做到的,所以不管如何,系统的运维,从一个地方生成这样配置的操作,从一个地方生成的部署,都很重要。
以上讲的是硬件、软件、运维,这三个部分成本如何平衡,现在这个状态下,尤其是大规模的数据中心,有可能和过去小的企业数据中心不同。基于数人云的Docker管理环境

现在深度学习火了,每个人都想要深度学习的机器。最开始一个人要的时候,没关系,从桌面虚拟机集群拆出两台来,装上GPU,自己去用。现在这样的人多了,装了60几块GPU仍然不够,所以这种集群如何共享这60几块GPU,非常麻烦。

后面做了一个什么事情呢?找数人云做GPU虚拟化,虽然GPU支持虚拟化但太贵所以不买,买的都是消费者级别的GPU,因为便宜。当它不支持虚拟化时联合容器,所以将GPU集群上放上了Docker,又找了数人云,帮助开发一个数人云的管理系统,是基于Mesos的开源软件。同时写Mesos的人是我在伯克利的同学,因此对它的印象很好。

将来的就是这样的架构,好处是解决了一个问题,即服务封装,DeepLearning这事真的不复杂,如果你玩过,会发现很简单,其实就是找一个开源的软件框架,上面有很多模型,将其下载下来,都是开源的,这些模型甚至都是训练好的,可以跑人脸识别应用,或者跑其他的什么识别应用,虽然没有专业跑的好,但也不会太差。
但它的问题在于是基于框架,尤其在中国,版本不一样,升级版本升级的特别快,随便动一个升级,其他人都烂了,而不同人就要不同的版本,为什么,因为它下的那个模型是基于某个特定版本开发的,在别的版本上跑不出来,所以在这种情况下,大家去到无数多个配置好的镜像和环境,这个场景挺好,Docker、数人云有它的界面,将这个东西配置好,这种Docker配置的这种Docker,只有这个Docker里面用的是那种版本的东西,因为Docker是一层一层的,不用做那么多镜像,只有一点点区别没有关系,那么多借点有一点点区别,占不了那么多空间,好多镜像,各自用各自的Docker。
所以这解决了一个叫软件分发部署的问题,但有一个问题,总得有训练数据,有点什么东西在里面,完成后改了配置等等,这些东西不可能存回到那个镜像里头去,就想那怎么办呢?可能过了两个星期之后还用呢?所以就不上Docker,留着,等两个星期后再说,但两个星期后做别的项目去了,机器就卡在那里,所以这是个问题,存储它的周边结果存在哪里,是个好大的问题。
简单的方法,有OpenStack,集群上500块硬盘总是有的,挂上NFS,每台机器上面有一个Ceph的NFS,把这些东西对接好,想把这个东西存在那个上面保证安全的,关了以后重启时再挂回来,设计了这样一套存储。
那有什么问题呢?DeepLearning的模型也很大,有些人直接在上面跑,本想让它存储一个备份数据用,跑到上面做一下其实还是存在本地。

所以后来自己改造了存储的架构,做了一个开源项目Alluxio,也是伯克利实验室的一个同学做的。

Alluxio缓存非常有用,它还为Ceph和NFS适配了一个接口,还有Hadoop集群,HDFS里面也有几百块盘,将这三种东西适配城了两个借口,适合放在Docker里面,也适合放在Hadoop里面,且它加了些缓存,这样用机器人内存吸收了很多流量,上图就是大概的基本架构。

HDFS也可以支持,同时也能顺便支持Hadoop,但是如果有一些大的文件,愿意用HDFS的,就用HDFS。

有写机器内存还蛮多的,就是当年趁内存时买了一些内存,还是很有用的,可以将内容缓存住。分布式内存很有意思。用人工智能帮助数据中心运维

最后说一下很多做DeepLearning的程序,这张图片解释了一个词“复杂”,OpenStack觉得自己很干净,为什么?拿个笔都能画出来,但是这张图很复杂,复杂的原因不光是因为有这么多图,凡是看见的都是数据库,数据库是一个持久性的状态,每个组件里都有自己持久的状态,那如怎么保证一致?讨论了这么久分布式系统的一致性,它一旦跨了组件,尤其是跨了开源项目,谁也不会再说这件事。

但若组件坏了,里面还有一个复杂的结构,它一层一层的封装起来,所以什么东西坏了,你可能根本不知道,没坏的时候什么都特别好,但坏了就会很麻烦。
我是个很好的系统管理员,这点特别有信心,但是搞不定这个,因为我不是每天都在配这个,记不得这些东西到底在什么地方,随便查一个什么东西,后面的参数那么长,咱们记不住,但别人天天都在做当然可以记住。

那么,如何能动呢?我们说通过挖掘日志、系统里的状态、跑一些系统里的命令、看一些系统里的数据库,在里面找一些相关的事情,这是纯从样子上找到的,跟语义没有关系。比如ID长那样,那个ID就是ID,IP地址就是IP地址,将这些东西都找在一起,把这些关联性插在一起,就能生成知识图。

另外,为什么三台机器一起坏了,有可能用户只看到一台机器坏了,但其实另外两台也是如此,因为它坏的原因是一个物理机,要坏肯定是三台一起坏,所以都可以找到系统里的一些东西,这有多少个节点?看这个系统看三天,120台物理机不算大,待该有60多个存储的借点,120多个虚拟机的节点,大概出来的结果是几千万个状态,如上图所示,所以可以想象为什么这东西老坏。

最后总结一下,运维是个什么样的过程?刚才说到DevOps,过去的系统管理员如何适应DevOps是一个非常大的挑战,因为DevOps,运维的人是靠开发程序来自动化运维数据中心的,这是必然的趋势,听起来都对。但DevOps推广起来非常难。
DevOps想要推行,一定要把DevOps这些东西的接口配置到过去的系统管理员能懂的那些地方,基本的意思是,预生几个命令行,别说那么多分布式的东西,感觉就是几个配置文件,点点什么东西,这个接口怎么配置,是一个非常大的挑战。
以上是小数整理的徐葳教授在PaaS Innovation 2017上的演讲实录,后台回复“1116”即可下载本次大会的PPT资料。

微服务架构企业级增强产品:数人云推出统一配置中心Hawk

杨y 发表了文章 • 0 个评论 • 2 次浏览 • 3 小时前 • 来自相关话题

11月16日,数人云在PaaS Innovation大会上,正式发布企业应用架构管理体系EAMS,这是数人云轻量化PaaS平台的重要产品体系,也是数人云向微服务方向延伸,践行微服务落地的战略调整。传统企业对微服务应用的管理需求日益强烈,微服务也成为云计算原生应用的标准开发框架,是落地敏捷开发和部署的关键。如今,EAMS产品家族又多了一位核心成员——数人云统一配置中心Hawk。

互联网企业和传统金融等行业具有业务配置复杂,配置数据量大,配置容易出错等特点,如何能将配置数据与程序包解耦,避免对环境的依赖成为一大难点。特别是引入微服务后,业务配置数量急剧增加,出错概率也同步增加,如果能统一管控,支持多环境管理成为运维的一大难点和痛点。

基于微服务理念打造的分布式统一配置中心Hawk支持多种类型配置如Spring Cloud、Dubbo、Kubernetes Configmap、Logback、Linux Environment等等,具有完善的配置管理流程、配置实时推送、支持多集群多环境、多版本控制,更提供配置细力度的管理如灰度管理、任意版本重置等丰富功能。整个体系兼容开源社区的Spring Cloud Config以及Kubernetes的Configmap,极大降低使用者的学习门槛以及降低业务对于平台的耦合。相应的管理流程也规范了配置的使用和降低因为配置带来的发布错误等。

Hawk的主体架构








在功能方面,数人云分布式统一调度平台Hawk具备完善的企业级功能:

配置流程管理:完善的配置流程管理,确保配置下发前必须获得确认和授权。
认证与授权:提供 LDAP 集成,以及多角色权限管理。
支持操作审计:确保配置操作有据可查。
支持多种配置文件:支持Spring Cloud Config、Dubbo、Logback、Linux Environment、Nginx、Tomcat等等,并持续增加中。
支持Spring Cloud服务治理配置和管控:支持Spring Cloud自有的Hystrix的微服务治理如熔断、Fallback等等。
无缝集成 Kubernetes 的 Configmap 以及 Secrets:无缝集成 Kubernetes 的 Configmap 以及 Secrets 的配置管理,并提供增强的企业管理流程。
支持配置实时推送以及实时生效:配置变更能触发应用实时生效,避免应用重启来激活配置,从而降低服务中断的风险。
支持多版本管理:支持多版本管理,并支持历史版本的激活。
支持多配置集群、多环境配置。
优美的监控台:提供多维度 Dashboard 以及监控视图,支持配置灰度和回滚。
支持配置灰度和回滚。
支持数据全局备份和恢复:进一步提升配置数据的容灾能力
提供OpenAPI:支持多系统集成的便利手段、支持配置应急预案处理






数人云的轻量级PaaS平台,在容器平台的基础上延伸出丰富的产品线,致力于成为云时代的新PaaS,为客户快速打造互联网应用的系统和架构支持。在开发以及运维层面,分布式统一配置中心Hawk是EAMS体系的进一步增强。据悉,数人云EAMS体系下,一系列开发管理框架以及智能管理工具尚在持续研发中,以期帮助客户降低运维难度和复杂度,快速应对业务迭代,帮助客户构建敏捷IT能力。 查看全部

1.png



11月16日,数人云在PaaS Innovation大会上,正式发布企业应用架构管理体系EAMS,这是数人云轻量化PaaS平台的重要产品体系,也是数人云向微服务方向延伸,践行微服务落地的战略调整。传统企业对微服务应用的管理需求日益强烈,微服务也成为云计算原生应用的标准开发框架,是落地敏捷开发和部署的关键。如今,EAMS产品家族又多了一位核心成员——数人云统一配置中心Hawk。

互联网企业和传统金融等行业具有业务配置复杂,配置数据量大,配置容易出错等特点,如何能将配置数据与程序包解耦,避免对环境的依赖成为一大难点。特别是引入微服务后,业务配置数量急剧增加,出错概率也同步增加,如果能统一管控,支持多环境管理成为运维的一大难点和痛点。

基于微服务理念打造的分布式统一配置中心Hawk支持多种类型配置如Spring Cloud、Dubbo、Kubernetes Configmap、Logback、Linux Environment等等,具有完善的配置管理流程、配置实时推送、支持多集群多环境、多版本控制,更提供配置细力度的管理如灰度管理、任意版本重置等丰富功能。整个体系兼容开源社区的Spring Cloud Config以及Kubernetes的Configmap,极大降低使用者的学习门槛以及降低业务对于平台的耦合。相应的管理流程也规范了配置的使用和降低因为配置带来的发布错误等。

Hawk的主体架构


2.png



在功能方面,数人云分布式统一调度平台Hawk具备完善的企业级功能:

配置流程管理:完善的配置流程管理,确保配置下发前必须获得确认和授权。
认证与授权:提供 LDAP 集成,以及多角色权限管理。
支持操作审计:确保配置操作有据可查。
支持多种配置文件:支持Spring Cloud Config、Dubbo、Logback、Linux Environment、Nginx、Tomcat等等,并持续增加中。
支持Spring Cloud服务治理配置和管控:支持Spring Cloud自有的Hystrix的微服务治理如熔断、Fallback等等。
无缝集成 Kubernetes 的 Configmap 以及 Secrets:无缝集成 Kubernetes 的 Configmap 以及 Secrets 的配置管理,并提供增强的企业管理流程。
支持配置实时推送以及实时生效:配置变更能触发应用实时生效,避免应用重启来激活配置,从而降低服务中断的风险。
支持多版本管理:支持多版本管理,并支持历史版本的激活。
支持多配置集群、多环境配置。
优美的监控台:提供多维度 Dashboard 以及监控视图,支持配置灰度和回滚。
支持配置灰度和回滚。
支持数据全局备份和恢复:进一步提升配置数据的容灾能力
提供OpenAPI:支持多系统集成的便利手段、支持配置应急预案处理

3.png


数人云的轻量级PaaS平台,在容器平台的基础上延伸出丰富的产品线,致力于成为云时代的新PaaS,为客户快速打造互联网应用的系统和架构支持。在开发以及运维层面,分布式统一配置中心Hawk是EAMS体系的进一步增强。据悉,数人云EAMS体系下,一系列开发管理框架以及智能管理工具尚在持续研发中,以期帮助客户降低运维难度和复杂度,快速应对业务迭代,帮助客户构建敏捷IT能力。

演讲实录 | 招银云创:容器PaaS正在让开发人员再也看不到IaaS

杨y 发表了文章 • 0 个评论 • 11 次浏览 • 2 天前 • 来自相关话题

嘉宾介绍:陈沙克,招银云创战略研究院总监,从2010年开始从事云计算相关工作,做OpenStack七年有余,目前在招银云创负责PaaS相关工作。此文为陈沙克在数人云PaaS Innovation 2017,构建灵动新IT大会上的演讲实录。

招银云创是招商银行的全资子公司,代表招商银行进行科技的输出,致力于将招行30年的经验和技术积累输出给广大金融企业,帮助同业同行快速的金融创新。

容器快速交付提高金融的互联网化

金融行业特性与其他行业在思维方式上有很大不同。

金融是强监管行业,尝试新技术面临监管的要求。那么,强监管下如何跟上变化的需要呢?这里面展开可以有很多故事。在Fintech互联网金融影响下,银行在监管上其实有所放松。其次,银行业有非常严格的安全性要求。由于历史原因,银行内部IT系统非常复杂,通常每家银行都有上百个系统。








中国的银行体系非常庞大,这可能跟金融行业外朋友的感知不同。这些银行包括农村信用社、农村银行、城市商业银行等,他们都有巨大的IT系统托管需求。招银云创就是服务以上这些客户。








随着银行业务的发展,之前系统托管和所服务的客户都是场地托管,系统灵活性不足。但随着互联网以及业务的发展,客户开始提出一些定制化的需求,对银行业务的开展产生巨大挑战。








互联网化的金融IT需求如何应对?客户定制化需求如何满足?金融行业云在互联网金融汹涌来袭的背景下,面临巨大挑战。有同行强调,银行要做金融的互联网,而不能由互联网来主导金融。其实,今天在金融行业的人都应该有这个想法。

招银云创PaaS平台希望将各种行业的应用放在PaaS平台上,帮助企业更快地落地。假如银行有100多个项目同时开发,对于前面提到的大多数银行来讲是不现实的,希望有一个平台能帮助企业实现快速交付。

如何才能做到快速交付?招银云创认为,只有标准化形成规模,才能够将很多东西以一种标准化的形式提供出去,同时也要满足企业未来发展的需求。容器就是一种在标准化和简单化之间找到平衡的技术。








成熟的容器正在让开发人员再也看不到IaaS

现在简单介绍一下招银云创PaaS平台的架构。对于银行来说,金融行业全部应用都是基于JAVA来开发。但现在,新的应用都要求基于Spring Cloud框架来开发,只有用Spring Cloud框架开发,放在PaaS平台上才能体现出优势。容器的管理平台现在已经比较成熟。Kubernetes在新一轮的编排工具大战中胜出,但仅仅一个Kubernetes满足不了金融PaaS的需求,容器周边还需要诸多辅助系统,从而让开发和运维人员更好地使用。







在过去的两个多月,招银云创一直在推动将自己的Spring Cloud应用迁移到PaaS平台。这次迁移团队也积累了很多经验和教训。

首先,配置管理。Spring Cloud的配置管理是用git来管理的。当把应用搬到PaaS平台上时,运维人员会向开发人员提出配置管理的要求,比如要求开发人员对配置要统一管理,不能到处放置配置文件。








开发人员很乐意接受这个建议。以往推PaaS平台时,对开发人员的工作改动量很大。现在,新的PaaS平台开发人员感受到的,不是改动多少代码,而是带来多少便利,以及给出很合理的需求。

招银云创希望在整个Spring Cloud里面配置管理,不仅可以用Git管理,而且开发自己的配置管理中心来完善PaaS平台。

日志管理向来复杂,银行的日志则会更加复杂。原因在于,日志含有大量交易信息,这些信息不仅需要保留,而且要检索。除了系统日志,还包含应用的日志,应用日志量非常庞大,甚至达到每天T级别的日志量,尤其采用微服务后。那么,这些日志应该如何处理呢?













招银云创希望日志管理简单化。对于传统的金融行业来讲,技术没有那么丰富,采用的技术眼花缭乱任何团队想完全Hold住都有压力。招银云创同时希望日志标准化,实现日志的统一管理。招银云创的应用多是自己开发,对应用的日志输出做出要求,这样整个PaaS平台能够真正用起来。

如今,监控已不像以前那么眼花缭乱,Prometheus也实现了一统江湖。加之官方的展示,基本满足招银对监控屏展示的要求。








持续集成则跟开发密切相关。以前在做OpenStack时,经常谈到怎么用OpenStack虚拟机来做持续集成,那个过程很痛苦。因为虚拟机的启动、安装、部署代价非常高,持续时间周期很长。在OpenStack上做开发,如果要跑一两个小时才能出结果,这在传统企业是根本无法接受的。采用容器的CI以后,这种局面得到彻底改观。所有的提交以及镜像发布到测试,可以做到分钟级解决。借助各种内网的源,整个镜像和发布过程很快。







对于新的PaaS平台来说,重点工作之一是通过发布管理去发布。PaaS平台偏运维,在招银云创内部,运维人员能够深切地感受到对自身带来的巨大帮助,以前纯手工的过程全部自动化完成。在过去的两个月,招银云创内部推动PaaS平台积极性最高的也是运维人员,实现了从手工到完全自动化,甚至智能化。招银云创已经做到代码一提交,马上去做镜像,然后推送到发布的一体化流程,这在以往不可想象。在没有容器之前,哪怕采用Spring Cloud开发应用,也无法发挥它的特点。







回到镜像管理,镜像管理能够看到很多方案,但对企业来说,镜像积累到一定程度,变成企业的资产,日后有可能代替电子仓库。云创镜像积累的很好,一些不同版本都能够得到快速满足,实现快速迭代,满足开发需求。







经过两个月PaaS平台的使用,运维人员感触最深的是“开发人员已经看不到IaaS平台了”。为什么这么说?以前开发人员经常要在IaaS平台里面启动各种虚拟机,来进行测试、完善。用了PaaS平台后,开发、发布、交付生产线,都已经不需要关注底层是虚拟机还是物理机,只需要关注一个PaaS平台。





  查看全部

1.png



嘉宾介绍:陈沙克,招银云创战略研究院总监,从2010年开始从事云计算相关工作,做OpenStack七年有余,目前在招银云创负责PaaS相关工作。此文为陈沙克在数人云PaaS Innovation 2017,构建灵动新IT大会上的演讲实录。

招银云创是招商银行的全资子公司,代表招商银行进行科技的输出,致力于将招行30年的经验和技术积累输出给广大金融企业,帮助同业同行快速的金融创新。

容器快速交付提高金融的互联网化

金融行业特性与其他行业在思维方式上有很大不同。

金融是强监管行业,尝试新技术面临监管的要求。那么,强监管下如何跟上变化的需要呢?这里面展开可以有很多故事。在Fintech互联网金融影响下,银行在监管上其实有所放松。其次,银行业有非常严格的安全性要求。由于历史原因,银行内部IT系统非常复杂,通常每家银行都有上百个系统。


2.png



中国的银行体系非常庞大,这可能跟金融行业外朋友的感知不同。这些银行包括农村信用社、农村银行、城市商业银行等,他们都有巨大的IT系统托管需求。招银云创就是服务以上这些客户。


3.png



随着银行业务的发展,之前系统托管和所服务的客户都是场地托管,系统灵活性不足。但随着互联网以及业务的发展,客户开始提出一些定制化的需求,对银行业务的开展产生巨大挑战。


4.png



互联网化的金融IT需求如何应对?客户定制化需求如何满足?金融行业云在互联网金融汹涌来袭的背景下,面临巨大挑战。有同行强调,银行要做金融的互联网,而不能由互联网来主导金融。其实,今天在金融行业的人都应该有这个想法。

招银云创PaaS平台希望将各种行业的应用放在PaaS平台上,帮助企业更快地落地。假如银行有100多个项目同时开发,对于前面提到的大多数银行来讲是不现实的,希望有一个平台能帮助企业实现快速交付。

如何才能做到快速交付?招银云创认为,只有标准化形成规模,才能够将很多东西以一种标准化的形式提供出去,同时也要满足企业未来发展的需求。容器就是一种在标准化和简单化之间找到平衡的技术。


5.png



成熟的容器正在让开发人员再也看不到IaaS

现在简单介绍一下招银云创PaaS平台的架构。对于银行来说,金融行业全部应用都是基于JAVA来开发。但现在,新的应用都要求基于Spring Cloud框架来开发,只有用Spring Cloud框架开发,放在PaaS平台上才能体现出优势。容器的管理平台现在已经比较成熟。Kubernetes在新一轮的编排工具大战中胜出,但仅仅一个Kubernetes满足不了金融PaaS的需求,容器周边还需要诸多辅助系统,从而让开发和运维人员更好地使用。

6.png



在过去的两个多月,招银云创一直在推动将自己的Spring Cloud应用迁移到PaaS平台。这次迁移团队也积累了很多经验和教训。

首先,配置管理。Spring Cloud的配置管理是用git来管理的。当把应用搬到PaaS平台上时,运维人员会向开发人员提出配置管理的要求,比如要求开发人员对配置要统一管理,不能到处放置配置文件。


7.png



开发人员很乐意接受这个建议。以往推PaaS平台时,对开发人员的工作改动量很大。现在,新的PaaS平台开发人员感受到的,不是改动多少代码,而是带来多少便利,以及给出很合理的需求。

招银云创希望在整个Spring Cloud里面配置管理,不仅可以用Git管理,而且开发自己的配置管理中心来完善PaaS平台。

日志管理向来复杂,银行的日志则会更加复杂。原因在于,日志含有大量交易信息,这些信息不仅需要保留,而且要检索。除了系统日志,还包含应用的日志,应用日志量非常庞大,甚至达到每天T级别的日志量,尤其采用微服务后。那么,这些日志应该如何处理呢?


8.png


9.png



招银云创希望日志管理简单化。对于传统的金融行业来讲,技术没有那么丰富,采用的技术眼花缭乱任何团队想完全Hold住都有压力。招银云创同时希望日志标准化,实现日志的统一管理。招银云创的应用多是自己开发,对应用的日志输出做出要求,这样整个PaaS平台能够真正用起来。

如今,监控已不像以前那么眼花缭乱,Prometheus也实现了一统江湖。加之官方的展示,基本满足招银对监控屏展示的要求。


10.png



持续集成则跟开发密切相关。以前在做OpenStack时,经常谈到怎么用OpenStack虚拟机来做持续集成,那个过程很痛苦。因为虚拟机的启动、安装、部署代价非常高,持续时间周期很长。在OpenStack上做开发,如果要跑一两个小时才能出结果,这在传统企业是根本无法接受的。采用容器的CI以后,这种局面得到彻底改观。所有的提交以及镜像发布到测试,可以做到分钟级解决。借助各种内网的源,整个镜像和发布过程很快。

11.png



对于新的PaaS平台来说,重点工作之一是通过发布管理去发布。PaaS平台偏运维,在招银云创内部,运维人员能够深切地感受到对自身带来的巨大帮助,以前纯手工的过程全部自动化完成。在过去的两个月,招银云创内部推动PaaS平台积极性最高的也是运维人员,实现了从手工到完全自动化,甚至智能化。招银云创已经做到代码一提交,马上去做镜像,然后推送到发布的一体化流程,这在以往不可想象。在没有容器之前,哪怕采用Spring Cloud开发应用,也无法发挥它的特点。

12.png



回到镜像管理,镜像管理能够看到很多方案,但对企业来说,镜像积累到一定程度,变成企业的资产,日后有可能代替电子仓库。云创镜像积累的很好,一些不同版本都能够得到快速满足,实现快速迭代,满足开发需求。

13.png



经过两个月PaaS平台的使用,运维人员感触最深的是“开发人员已经看不到IaaS平台了”。为什么这么说?以前开发人员经常要在IaaS平台里面启动各种虚拟机,来进行测试、完善。用了PaaS平台后,开发、发布、交付生产线,都已经不需要关注底层是虚拟机还是物理机,只需要关注一个PaaS平台。

14.png

 

大会演讲PPT|数人云王璞:《云计算之PaaS进化:潮涌、碰撞、变革》

杨y 发表了文章 • 0 个评论 • 26 次浏览 • 5 天前 • 来自相关话题

 
11月16日,由中国开源云联盟WG6容器工作组和数人云联合主办的“PaaS Innovation 2017,构建灵动新IT”大会在北京召开。数人云CEO王璞博士做了以《云计算之PaaS进化:潮涌、碰撞、变革》为主题的开场演讲。以下是本次演讲的PPT:
 





























  查看全部

幻灯片1.JPG


幻灯片2.JPG


幻灯片3.JPG


幻灯片4.JPG


幻灯片5.JPG


幻灯片6.JPG


幻灯片8.JPG


幻灯片9.JPG


幻灯片10.JPG


幻灯片11.JPG


幻灯片12.JPG


幻灯片13.JPG


幻灯片14.JPG


幻灯片15.JPG


幻灯片16.JPG


幻灯片17.JPG


 
11月16日,由中国开源云联盟WG6容器工作组和数人云联合主办的“PaaS Innovation 2017,构建灵动新IT”大会在北京召开。数人云CEO王璞博士做了以《云计算之PaaS进化:潮涌、碰撞、变革》为主题的开场演讲。以下是本次演讲的PPT:
 
幻灯片18.JPG


幻灯片19.JPG


幻灯片20.JPG


幻灯片21.JPG


幻灯片22.JPG


幻灯片23.JPG

 

《企业级容器云平台》联盟标准在数人云PaaS Innovation大会发布

杨y 发表了文章 • 0 个评论 • 22 次浏览 • 5 天前 • 来自相关话题

11月16日,由中国开源云联盟WG6容器工作组和数人云联合主办的“PaaS Innovation2017,构建灵动新IT”大会在北京成功举办。会上,中国开源云联盟权威发布了企业级容器云平台标准。这是继去年由中国开源云联盟发布首个国内容器白皮书之后,容器技术发展的又一里程碑,标志着容器技术进入成熟稳定落地阶段。

近年来,容器技术逐渐成为继虚拟化技术之后对云计算领域影响深远的技术变革。容器技术从2013年传入国内,为各行业应用云计算提供了新思路,逐渐被研发人员和企业客户所接受。不断成熟的容器技术也对云计算的交付、效率和PaaS平台构建产生着深刻影响。容器已经成为企业落地微服务架构,实现DevOps理念的重要支撑技术。

企业级容器云平台标准权威发布


在发布环节,中国开源云联盟秘书长周平、常务副秘书长杨丽蕴、中国电子技术标准化研究院云计算标准资深专家陈志峰、CNTV运维总监王雷、Intel高级工程师杜永丰、数人云CTO肖德时作为代表共同进行了发布。







中国开源云联盟常务副秘书长杨丽蕴致辞

容器标准的编制由中国开源云联盟牵头并完成,参与单位包括数人云、Intel、央视网、腾讯云、阿里云、华为、联想、网易云等十数家联盟单位。其中数人云为容器工作组组长单位,Intel和CNTV为副组长单位。

容器云平台是Gartner提出来的云管理平台的衍生,共有两方面功能。第一,功能需求,管理容器运行引擎、容器网络,容器编排。第二是非功能需求,可用性,兼容性,安全和易用性,负载优化。容器云平台最终的目标是,应用在云平台上运行时取得最优化的效果。

该标准草案的制定参考了CNCF的理论框架,对容器所涉及的基础设施、运行时环境、容器编排和管理、中间件及DevOps、云管理平台、监控日志追踪等功能组件都定义了清晰的要求。同时,对容器的非功能特性,如性能、兼容性等,也提供相应的规范条款。

标志容器技术进入成熟落地阶段

云计算和 DevOps 都是 “敏捷 IT” 理念下的技术组合,目的在于快速开发并交付业务,而且大规模稳定运行。敏捷的挑战主要来自“高速度”和“低风险”。面对互联网海量用户和海量数据的挑战,未来速度和风险的矛盾将愈演愈烈。其次,互联网和大数据对于传统IT从架构到运维都是“从零到一”的过程,相关经验一直由互联网企业和开源社区掌握。传统 IT 厂商从产品到实践无法提供能落地的支持,企业往往陷入难以起步、一试就错的困境,难以进入通过快速迭代来培养队伍的正向循环。

企业级容器云平台包括三个层面的功能:针对异构资源纳管的容器运行环境,针对微服务和分布式架构支撑的基础架构 PaaS (iPaaS — infrastructure PaaS)和帮助用户快速搭建分布式应用的应用 PaaS (aPaaS — Application PaaS)。

标准草案的发布,旨在顺应国内企业从传统单体架构向微服务架构转变的趋势,满足传统企业业务高速发展的需求。随着开源技术的发展,推动容器技术的成熟稳定和不断落地,敏捷IT有了实现的可能和契机。以Docker为代表的容器技术近几年迎来发展热潮,其轻量化、快速部署、可移植等特性受到追捧。

此次容器云平台标准的推出,标志着容器技术发展日渐成熟,将加速容器云在国内企业的落地。当技术沉淀到标准中,形成容器PaaS的相关标准,企业应用有准可依,技术产业化进程将会大大加速。

关于中国开源云联盟

中国开源云联盟(简称“COSCL”)由Intel、新浪网、中标软件和上海交大于2012年8月共同发起创立,是中国最早专注于OpenStack的专业联盟,一直致力于在中国推动OpenStack技术开发、操作系统支持、性能优化、规模部署等工作。

2016年,在工业和信息化部信息化和软件服务业司的指导下,中国开源云联盟正式挂靠中国电子技术标准化研究院,推进联盟后续工作。中国电子技术标准化研究院作为工信部直属的电子信息领域标准化研究机构,一直致力于联合产业界推动开源软件技术和开源标准化工作的发展,探索开源标准与国家标准、国际标准的有机结合,并努力推动开源标准化工作思路和模式的创新。

关于WG6容器工作组

WG6—容器工作组由中国电子技术标准化研究院主办,数人云任工作组组长,CNTV,Intel任副组长,包括国电通、国航、去哪儿网、阿里云、VMware、华三等在内的多个单位参与,主要目的是推动容器开源技术在国内的落地;提升容器开源技术在国际容器社区的贡献比例,推动国内用户落地容器技术规范的标准化(包括网络、存储、安全、测试、扩展性、可用性、应用场景等)。

关于数人云

数人云成立于2014年,创始团队来自谷歌、红帽和惠普,作为领先的云计算开源技术实践者,数人云致力于帮助传统企业提升IT对业务的支撑能力,帮助客户统一管理资源和应用,加速应用交付、提升运维效率,建设新一代基于云计算技术的IT架构体系。

数人云重点聚焦打造基于容器的极轻量级PaaS平台,在实现应用全生命周期管理的同时,管理海量监控、日志等产生的各类数据,自动分配应用资源、对业务运行状况进行自动分析。数人云产品体系创新性地升级为企业应用架构管理体系(EAMS),实现业务、应用、架构和IT管理四者和谐统一,满足企业双态IT需求,实现IT敏捷化自动化。借鉴国外SRE的实践经验支持DevOps落地,提升企业IT工业化程度,构建灵动新IT。

数人云为中国开源云联盟理事单位、Linux&CNCF基金会成员,并加入OCI(The Open Container Initiative)联盟,携手与国内外云计算伙伴共同推动云计算领域容器等开源技术的落地与发展。 查看全部
11月16日,由中国开源云联盟WG6容器工作组和数人云联合主办的“PaaS Innovation2017,构建灵动新IT”大会在北京成功举办。会上,中国开源云联盟权威发布了企业级容器云平台标准。这是继去年由中国开源云联盟发布首个国内容器白皮书之后,容器技术发展的又一里程碑,标志着容器技术进入成熟稳定落地阶段。

近年来,容器技术逐渐成为继虚拟化技术之后对云计算领域影响深远的技术变革。容器技术从2013年传入国内,为各行业应用云计算提供了新思路,逐渐被研发人员和企业客户所接受。不断成熟的容器技术也对云计算的交付、效率和PaaS平台构建产生着深刻影响。容器已经成为企业落地微服务架构,实现DevOps理念的重要支撑技术。

企业级容器云平台标准权威发布


在发布环节,中国开源云联盟秘书长周平、常务副秘书长杨丽蕴、中国电子技术标准化研究院云计算标准资深专家陈志峰、CNTV运维总监王雷、Intel高级工程师杜永丰、数人云CTO肖德时作为代表共同进行了发布。

QQ图片20171117150919.png



中国开源云联盟常务副秘书长杨丽蕴致辞

容器标准的编制由中国开源云联盟牵头并完成,参与单位包括数人云、Intel、央视网、腾讯云、阿里云、华为、联想、网易云等十数家联盟单位。其中数人云为容器工作组组长单位,Intel和CNTV为副组长单位。

容器云平台是Gartner提出来的云管理平台的衍生,共有两方面功能。第一,功能需求,管理容器运行引擎、容器网络,容器编排。第二是非功能需求,可用性,兼容性,安全和易用性,负载优化。容器云平台最终的目标是,应用在云平台上运行时取得最优化的效果。

该标准草案的制定参考了CNCF的理论框架,对容器所涉及的基础设施、运行时环境、容器编排和管理、中间件及DevOps、云管理平台、监控日志追踪等功能组件都定义了清晰的要求。同时,对容器的非功能特性,如性能、兼容性等,也提供相应的规范条款。

标志容器技术进入成熟落地阶段

云计算和 DevOps 都是 “敏捷 IT” 理念下的技术组合,目的在于快速开发并交付业务,而且大规模稳定运行。敏捷的挑战主要来自“高速度”和“低风险”。面对互联网海量用户和海量数据的挑战,未来速度和风险的矛盾将愈演愈烈。其次,互联网和大数据对于传统IT从架构到运维都是“从零到一”的过程,相关经验一直由互联网企业和开源社区掌握。传统 IT 厂商从产品到实践无法提供能落地的支持,企业往往陷入难以起步、一试就错的困境,难以进入通过快速迭代来培养队伍的正向循环。

企业级容器云平台包括三个层面的功能:针对异构资源纳管的容器运行环境,针对微服务和分布式架构支撑的基础架构 PaaS (iPaaS — infrastructure PaaS)和帮助用户快速搭建分布式应用的应用 PaaS (aPaaS — Application PaaS)。

标准草案的发布,旨在顺应国内企业从传统单体架构向微服务架构转变的趋势,满足传统企业业务高速发展的需求。随着开源技术的发展,推动容器技术的成熟稳定和不断落地,敏捷IT有了实现的可能和契机。以Docker为代表的容器技术近几年迎来发展热潮,其轻量化、快速部署、可移植等特性受到追捧。

此次容器云平台标准的推出,标志着容器技术发展日渐成熟,将加速容器云在国内企业的落地。当技术沉淀到标准中,形成容器PaaS的相关标准,企业应用有准可依,技术产业化进程将会大大加速。

关于中国开源云联盟

中国开源云联盟(简称“COSCL”)由Intel、新浪网、中标软件和上海交大于2012年8月共同发起创立,是中国最早专注于OpenStack的专业联盟,一直致力于在中国推动OpenStack技术开发、操作系统支持、性能优化、规模部署等工作。

2016年,在工业和信息化部信息化和软件服务业司的指导下,中国开源云联盟正式挂靠中国电子技术标准化研究院,推进联盟后续工作。中国电子技术标准化研究院作为工信部直属的电子信息领域标准化研究机构,一直致力于联合产业界推动开源软件技术和开源标准化工作的发展,探索开源标准与国家标准、国际标准的有机结合,并努力推动开源标准化工作思路和模式的创新。

关于WG6容器工作组

WG6—容器工作组由中国电子技术标准化研究院主办,数人云任工作组组长,CNTV,Intel任副组长,包括国电通、国航、去哪儿网、阿里云、VMware、华三等在内的多个单位参与,主要目的是推动容器开源技术在国内的落地;提升容器开源技术在国际容器社区的贡献比例,推动国内用户落地容器技术规范的标准化(包括网络、存储、安全、测试、扩展性、可用性、应用场景等)。

关于数人云

数人云成立于2014年,创始团队来自谷歌、红帽和惠普,作为领先的云计算开源技术实践者,数人云致力于帮助传统企业提升IT对业务的支撑能力,帮助客户统一管理资源和应用,加速应用交付、提升运维效率,建设新一代基于云计算技术的IT架构体系。

数人云重点聚焦打造基于容器的极轻量级PaaS平台,在实现应用全生命周期管理的同时,管理海量监控、日志等产生的各类数据,自动分配应用资源、对业务运行状况进行自动分析。数人云产品体系创新性地升级为企业应用架构管理体系(EAMS),实现业务、应用、架构和IT管理四者和谐统一,满足企业双态IT需求,实现IT敏捷化自动化。借鉴国外SRE的实践经验支持DevOps落地,提升企业IT工业化程度,构建灵动新IT。

数人云为中国开源云联盟理事单位、Linux&CNCF基金会成员,并加入OCI(The Open Container Initiative)联盟,携手与国内外云计算伙伴共同推动云计算领域容器等开源技术的落地与发展。

数人云王璞:PaaS蝶变背后是三大技术趋势和三大落地方法

杨y 发表了文章 • 0 个评论 • 16 次浏览 • 5 天前 • 来自相关话题

11月16日,由中国开源云联盟WG6容器工作组和数人云联合主办的“PaaS Innovation 2017,构建灵动新IT”大会在北京召开。本次大会由于汇聚了前瞻的PaaS洞察,着眼PaaS技术创新和演进趋势;梳理PaaS落地行业痛点,分享金融标杆客户最佳行业实践、重磅发布企业级容器云平台标准及推导PaaS落地方法,而广受业界瞩目。来自行业的专家、媒体朋友、生态伙伴,以及金融、能源、快消、制造等传统行业客户300余人参加了此次大会。








企业IT变革:轻量化、敏捷化、开源化

数人云CEO王璞博士做了以《云计算之PaaS进化:潮涌、碰撞、变革》为主题的开场演讲。传统商业正在被技术深度改变,互联网与传统行业结合的模式探索开始在各行业展开,新金融、新零售、新制造等新的业态不断涌现。在探求数字化转型过程中,无论是技术、人员,还是体制、运营管理,都并非简单的架构调整即可为之,传统业务和互联网场景应用将长期双态并存。

在互联网+重构业务形态的驱动下,传统企业纷纷开拓互联网业务来加大自身的行业竞争优势,这给复杂的响应缓慢的传统IT架构带来严峻挑战。企业IT部门和IT管理者疲于奔命。

王璞在演讲中指出,轻量化、敏捷化和开源化是近年企业IT架构三大最重要的技术演变趋势。






首先,应用容器化、架构微服务化,使得企业级应用变得越来越轻。其次,传统企业开始践行DevOps理念,打造开发运维一体化。将整个从开发到运维的全生命周期整合为统一的流程,研发人员可以专注业务开发本身,无需关注底层技术细节。运维人员大量采用自动化运维平台和工具,运维效率显著提升。由此,敏捷开发和业务敏捷性有了实现的可能。

第三,IT基础设施软件全面拥抱开源。开源技术能够增强企业的自主可控能力,开源可拓展的IT成为企业CIO和其他IT管理者在进行技术选型和新项目建设时的重要选择方向。同时,开源技术更新迭代频繁,也对企业级IT在技术选型上提出了挑战,需要不断在各种技术之间取长补短。

PaaS技术变革:应用容器化、服务网格化、生态行业化

PaaS正在成为云计算市场中增长最快的一极。尽管在大众的印象中,云计算三层之前始终是两家独大,不过最近几年,PaaS表现出强劲的发展势头。据IDC最新的全球半年度公有云服务支出指南,2017年PaaS支出增速五年复合年增长率为32.2%。







PaaS通过技术不断创新积累,深入到企业应用领域,赢得市场,为应用交付、资源管理、运维效率、业务支撑提供了基于新一代IT架构的重要支撑体系。凭借团队在互联网应用架构和企业级IT的丰富经验,并扎根行业,做深做透客户业务特性,王璞在演讲中指出,当前PaaS呈现出应用容器化、服务网格化和行业生态化三大技术趋势。

容器经过4年的迅速发展,已经成为云计算原生应用的标准交付方式,能够对底层基础架构资源实现快速、标准化和更轻量级的管理。其次,微服务将成为云计算原生应用的标准开发架构,传统企业客户对微服务应用的管理需求日益强烈。敏捷开发和部署举步维艰,其中最大的障碍是应用太复杂,以至于单个开发者很难搞懂。微服务架构下,技术选型去中心化,团队可以自由选择合适的技术栈。同时,当需要对技术栈进行升级,面临的风险也小得多。

在以微服务和容器技术为核心的技术转型下,新一代服务网络技术方兴未艾。服务网格技术在云环境下,能够对应用进行更好地管理。开发人员在开发应用时,不必考虑后端管理上的诉求,让开发变得更透明。另外,服务网格技术对后期应用程序的管理维护能够提供更丰富的手段,以及更细粒度的管理。

行业生态化也是PaaS演进的一大重要趋势,企业级IT服务逐步向行业云过渡。数人云通过与生态伙伴合作共同落地私有云、行业云,整合行业内云产业链上IaaS、PaaS和SaaS三层资源,为企业客户提供整体解决方案。王璞强调,在行业云发展的过程中,不仅业务特性突出的SaaS具备行业属性,偏下层的IaaS和PaaS同样具备行业属性,如此更好地实现企业IT资源和服务整合。

PaaS表现出强劲的发展势头,也是行业生态化使然。随着企业应用市场的爆发和成熟,SaaS对PaaS层的要求越来越高,应用要打通、跨层、效率、协作等,这在客观上推动了PaaS体量猛增。

PaaS落地:数人云DataMan OS+EAMS

数人云是国内轻量化PaaS的首倡者,具备PaaS层面丰富的产品线,通过DataMan OS和EAMS两大产品帮助企业客户建立标准化、统一化、模块化的企业级IT体系,落地敏捷IT能力。








DataMan OS是数人云产品的底座,利用容器实现应用标准化交付和统一化运维管理,为用户IT系统带来高可用、弹性伸缩。

EAMS产品基于Spring Cloud微服务开发框架,实现针对微服务应用的统一化服务治理、业务应用模块化,落地敏捷开发,帮助传统企业落地贯穿应用全生命周期的DevOps最佳实践。

“企业要获得敏捷IT,落地DevOps能力,从开发源头上,首先必须进行开发框架的标准化。微服务开发框架解决了应用的复杂性,推而广之,实现测试和运维的标准化,敏捷支撑上面的业务应用和场景。”王璞说道。

数人云始终围绕PaaS和应用来帮助企业客户交付IT能力。将关注的重心转向微服务架构的逻辑在于,架构对于企业IT来说是最根本的,关乎到长期的IT环境的先进性和高效,保障应用的持续迭代,业务快速响应。一个有长久生命力的系统必然有一个设计高明的架构,架构必须具备灵活性,同时易用性、安全性、稳定性恒久不变。“微服务架构是云时代的IT架构,在云化转型的时代,企业客户最匹配的就是微服务云计算原生架构。”








在云生态方面,数人云先后与宇信科技、高阳金信等金融领域领先IT解决方案提供商,以及首都在线等基础IaaS厂商结成合作伙伴,共同深挖行业,为客户交付从应用到平台更完善的IT能力,推动企业云化转型。

招银云创:容器已成熟采摘正当时

招银云创是招商银行的全资子公司,致力于将招商银行IT系统30年稳定运行的成功经验和金融IT成熟解决方案开放给金融同业。招银云创战略研究院总监陈沙克受邀在此次大会上做了《容器已成熟 采摘正当时》的主题演讲,分享招银云创的容器PaaS实践。

他指出,金融行业云有突出的行业特性:强监管、强安全和高复杂度。随着Fintech驱动业务创新和互联网的普及,银行IT不仅要支撑传统核心业务,系统定制化满足大客户需求,而且要重视发展2C业务。

面对互联网化IT和客户定制化双重需求,招银云创构建的容器PaaS平台包括SpringCloud开发框架、容器运行时管理平台和容器周边管理配套工具三方面。回顾招银云创PaaS经验,陈沙克强调,目前招银云创最关注的是容器周边管理工具,这是“企业用好容器的关键”。容器让金融行业云应用变得标准化、简单化,打造了快速应变,构建开放、弹性、安全可控新型IT,满足了银行业务的创新需求。对于招银云创来说,容器和PaaS正在让“开发人员再也看不到IaaS”。

作为PaaS Innovation大会的联合主办方,中国电子技术标准化研究院软件工程与评估中心主任、中国开源云联盟秘书长周平莅临现场并致开幕辞,他分享了开源技术如何推动产业创新,以及国内开源技术现况,并与开源云联盟容器工作组成员单位共同权威发布《企业级容器云平台》联盟标准。容器标准的发布意味着容器技术迅速成熟,进入全面落地阶段,产业化进程将大大加速。

此外,大会还邀请到了国家青年千人计划学者、清华大学交叉研究院助理院长徐葳,他在《数据中心和“智能”》的主题演讲中,和与会嘉宾分享了GPU容器集群、AI等更智能数据中心的最新研究成果。

在大会最后的圆桌环节,嘉宾们就PaaS认知、传统企业如何切入PaaS、PaaS在企业数字化转型中的作用,开源技术商业化,以及如何看待云计算风口等话题展开了热烈的圆桌讨论。在全面云化的今天,PaaS作为平台层崛起风口已现,上下游合作伙伴将一起携手推进传统企业上云,为传统企业提供更多贴近业务场景的技术、应用和解决方案。

关于数人云

数人云成立于2014年,创始团队来自谷歌、红帽和惠普,作为领先的云计算开源技术实践者,数人云致力于帮助传统企业提升IT对业务的支撑能力,帮助客户统一管理资源和应用,加速应用交付、提升运维效率,建设新一代基于云计算技术的IT架构体系。

数人云重点聚焦打造基于容器的极轻量级PaaS平台,在实现应用全生命周期管理的同时,管理海量监控、日志等产生的各类数据,自动分配应用资源、对业务运行状况进行自动分析。数人云产品体系创新性地升级为企业应用架构管理体系(EAMS),实现业务、应用、架构和IT管理四者和谐统一,满足企业双态IT需求,实现IT敏捷化自动化。借鉴国外SRE的实践经验支持DevOps落地,提升企业IT工业化程度,构建灵动新IT。

数人云为中国开源云联盟理事单位、Linux&CNCF基金会成员,并加入OCI(The Open Container Initiative)联盟,携手与国内外云计算伙伴共同推动云计算领域容器等开源技术的落地与发展。 查看全部
11月16日,由中国开源云联盟WG6容器工作组和数人云联合主办的“PaaS Innovation 2017,构建灵动新IT”大会在北京召开。本次大会由于汇聚了前瞻的PaaS洞察,着眼PaaS技术创新和演进趋势;梳理PaaS落地行业痛点,分享金融标杆客户最佳行业实践、重磅发布企业级容器云平台标准及推导PaaS落地方法,而广受业界瞩目。来自行业的专家、媒体朋友、生态伙伴,以及金融、能源、快消、制造等传统行业客户300余人参加了此次大会。


QQ图片20171117150208.png



企业IT变革:轻量化、敏捷化、开源化

数人云CEO王璞博士做了以《云计算之PaaS进化:潮涌、碰撞、变革》为主题的开场演讲。传统商业正在被技术深度改变,互联网与传统行业结合的模式探索开始在各行业展开,新金融、新零售、新制造等新的业态不断涌现。在探求数字化转型过程中,无论是技术、人员,还是体制、运营管理,都并非简单的架构调整即可为之,传统业务和互联网场景应用将长期双态并存。

在互联网+重构业务形态的驱动下,传统企业纷纷开拓互联网业务来加大自身的行业竞争优势,这给复杂的响应缓慢的传统IT架构带来严峻挑战。企业IT部门和IT管理者疲于奔命。

王璞在演讲中指出,轻量化、敏捷化和开源化是近年企业IT架构三大最重要的技术演变趋势。

2.png


首先,应用容器化、架构微服务化,使得企业级应用变得越来越轻。其次,传统企业开始践行DevOps理念,打造开发运维一体化。将整个从开发到运维的全生命周期整合为统一的流程,研发人员可以专注业务开发本身,无需关注底层技术细节。运维人员大量采用自动化运维平台和工具,运维效率显著提升。由此,敏捷开发和业务敏捷性有了实现的可能。

第三,IT基础设施软件全面拥抱开源。开源技术能够增强企业的自主可控能力,开源可拓展的IT成为企业CIO和其他IT管理者在进行技术选型和新项目建设时的重要选择方向。同时,开源技术更新迭代频繁,也对企业级IT在技术选型上提出了挑战,需要不断在各种技术之间取长补短。

PaaS技术变革:应用容器化、服务网格化、生态行业化

PaaS正在成为云计算市场中增长最快的一极。尽管在大众的印象中,云计算三层之前始终是两家独大,不过最近几年,PaaS表现出强劲的发展势头。据IDC最新的全球半年度公有云服务支出指南,2017年PaaS支出增速五年复合年增长率为32.2%。

3.png



PaaS通过技术不断创新积累,深入到企业应用领域,赢得市场,为应用交付、资源管理、运维效率、业务支撑提供了基于新一代IT架构的重要支撑体系。凭借团队在互联网应用架构和企业级IT的丰富经验,并扎根行业,做深做透客户业务特性,王璞在演讲中指出,当前PaaS呈现出应用容器化、服务网格化和行业生态化三大技术趋势。

容器经过4年的迅速发展,已经成为云计算原生应用的标准交付方式,能够对底层基础架构资源实现快速、标准化和更轻量级的管理。其次,微服务将成为云计算原生应用的标准开发架构,传统企业客户对微服务应用的管理需求日益强烈。敏捷开发和部署举步维艰,其中最大的障碍是应用太复杂,以至于单个开发者很难搞懂。微服务架构下,技术选型去中心化,团队可以自由选择合适的技术栈。同时,当需要对技术栈进行升级,面临的风险也小得多。

在以微服务和容器技术为核心的技术转型下,新一代服务网络技术方兴未艾。服务网格技术在云环境下,能够对应用进行更好地管理。开发人员在开发应用时,不必考虑后端管理上的诉求,让开发变得更透明。另外,服务网格技术对后期应用程序的管理维护能够提供更丰富的手段,以及更细粒度的管理。

行业生态化也是PaaS演进的一大重要趋势,企业级IT服务逐步向行业云过渡。数人云通过与生态伙伴合作共同落地私有云、行业云,整合行业内云产业链上IaaS、PaaS和SaaS三层资源,为企业客户提供整体解决方案。王璞强调,在行业云发展的过程中,不仅业务特性突出的SaaS具备行业属性,偏下层的IaaS和PaaS同样具备行业属性,如此更好地实现企业IT资源和服务整合。

PaaS表现出强劲的发展势头,也是行业生态化使然。随着企业应用市场的爆发和成熟,SaaS对PaaS层的要求越来越高,应用要打通、跨层、效率、协作等,这在客观上推动了PaaS体量猛增。

PaaS落地:数人云DataMan OS+EAMS

数人云是国内轻量化PaaS的首倡者,具备PaaS层面丰富的产品线,通过DataMan OS和EAMS两大产品帮助企业客户建立标准化、统一化、模块化的企业级IT体系,落地敏捷IT能力。


4.png



DataMan OS是数人云产品的底座,利用容器实现应用标准化交付和统一化运维管理,为用户IT系统带来高可用、弹性伸缩。

EAMS产品基于Spring Cloud微服务开发框架,实现针对微服务应用的统一化服务治理、业务应用模块化,落地敏捷开发,帮助传统企业落地贯穿应用全生命周期的DevOps最佳实践。

“企业要获得敏捷IT,落地DevOps能力,从开发源头上,首先必须进行开发框架的标准化。微服务开发框架解决了应用的复杂性,推而广之,实现测试和运维的标准化,敏捷支撑上面的业务应用和场景。”王璞说道。

数人云始终围绕PaaS和应用来帮助企业客户交付IT能力。将关注的重心转向微服务架构的逻辑在于,架构对于企业IT来说是最根本的,关乎到长期的IT环境的先进性和高效,保障应用的持续迭代,业务快速响应。一个有长久生命力的系统必然有一个设计高明的架构,架构必须具备灵活性,同时易用性、安全性、稳定性恒久不变。“微服务架构是云时代的IT架构,在云化转型的时代,企业客户最匹配的就是微服务云计算原生架构。”


5.png



在云生态方面,数人云先后与宇信科技、高阳金信等金融领域领先IT解决方案提供商,以及首都在线等基础IaaS厂商结成合作伙伴,共同深挖行业,为客户交付从应用到平台更完善的IT能力,推动企业云化转型。

招银云创:容器已成熟采摘正当时

招银云创是招商银行的全资子公司,致力于将招商银行IT系统30年稳定运行的成功经验和金融IT成熟解决方案开放给金融同业。招银云创战略研究院总监陈沙克受邀在此次大会上做了《容器已成熟 采摘正当时》的主题演讲,分享招银云创的容器PaaS实践。

他指出,金融行业云有突出的行业特性:强监管、强安全和高复杂度。随着Fintech驱动业务创新和互联网的普及,银行IT不仅要支撑传统核心业务,系统定制化满足大客户需求,而且要重视发展2C业务。

面对互联网化IT和客户定制化双重需求,招银云创构建的容器PaaS平台包括SpringCloud开发框架、容器运行时管理平台和容器周边管理配套工具三方面。回顾招银云创PaaS经验,陈沙克强调,目前招银云创最关注的是容器周边管理工具,这是“企业用好容器的关键”。容器让金融行业云应用变得标准化、简单化,打造了快速应变,构建开放、弹性、安全可控新型IT,满足了银行业务的创新需求。对于招银云创来说,容器和PaaS正在让“开发人员再也看不到IaaS”。

作为PaaS Innovation大会的联合主办方,中国电子技术标准化研究院软件工程与评估中心主任、中国开源云联盟秘书长周平莅临现场并致开幕辞,他分享了开源技术如何推动产业创新,以及国内开源技术现况,并与开源云联盟容器工作组成员单位共同权威发布《企业级容器云平台》联盟标准。容器标准的发布意味着容器技术迅速成熟,进入全面落地阶段,产业化进程将大大加速。

此外,大会还邀请到了国家青年千人计划学者、清华大学交叉研究院助理院长徐葳,他在《数据中心和“智能”》的主题演讲中,和与会嘉宾分享了GPU容器集群、AI等更智能数据中心的最新研究成果。

在大会最后的圆桌环节,嘉宾们就PaaS认知、传统企业如何切入PaaS、PaaS在企业数字化转型中的作用,开源技术商业化,以及如何看待云计算风口等话题展开了热烈的圆桌讨论。在全面云化的今天,PaaS作为平台层崛起风口已现,上下游合作伙伴将一起携手推进传统企业上云,为传统企业提供更多贴近业务场景的技术、应用和解决方案。

关于数人云

数人云成立于2014年,创始团队来自谷歌、红帽和惠普,作为领先的云计算开源技术实践者,数人云致力于帮助传统企业提升IT对业务的支撑能力,帮助客户统一管理资源和应用,加速应用交付、提升运维效率,建设新一代基于云计算技术的IT架构体系。

数人云重点聚焦打造基于容器的极轻量级PaaS平台,在实现应用全生命周期管理的同时,管理海量监控、日志等产生的各类数据,自动分配应用资源、对业务运行状况进行自动分析。数人云产品体系创新性地升级为企业应用架构管理体系(EAMS),实现业务、应用、架构和IT管理四者和谐统一,满足企业双态IT需求,实现IT敏捷化自动化。借鉴国外SRE的实践经验支持DevOps落地,提升企业IT工业化程度,构建灵动新IT。

数人云为中国开源云联盟理事单位、Linux&CNCF基金会成员,并加入OCI(The Open Container Initiative)联盟,携手与国内外云计算伙伴共同推动云计算领域容器等开源技术的落地与发展。

浅论Prometheus容器监控优缺点,2.0版本哪项改进受关注?

杨y 发表了文章 • 1 个评论 • 29 次浏览 • 2017-11-14 22:12 • 来自相关话题

 
关于容器监控,数人云之前给大家分享了《解惑|你是否为容器监控操碎了心?》,就有有Prometheus的身影,那么它都有哪些优缺点?近日发布的2.0版本又有哪些改进?本文见分晓~

Prometheus解决了Devs如何监控高动态容器环境的问题,在本文中,Frederick Ryckbosch讲述了使用Prometheus的优点和缺点,以及它到底有多大的伸缩性。

Prometheus是一个基于时间序列的数值数据的监控解决方案,这是一个开源项目,由前Google员工在SoundCloud启动,他们希望监控一个高度动态的容器环境,因为对传统的监控工具不甚满意,所以开发出Prometheus,并在上面进行工作。

在本文中,我们将讨论Prometheus的重要设计决策及其影响,将重点讨论“ Digital Ocean”如何成功地将Prometheus扩展到100万台机器,以及在使用Coscale时如何利用Prometheus。

Prometheus是如何工作的

要使用Prometheus监控服务,服务需要公开一个Prometheus端点,这端点是一个HTTP借口,它公开了度量的列表和当前的值。

Prometheus提供了广泛的服务发现选项,以查找您的服务并从它们开始检索度量数据。Prometheus服务器轮询服务的指标接口并存储数据。

在Prometheus UI中,用户可以在PromQL语言中编写查询以提取度量信息。

例如:topk(3, sum(rate(container_cpu_time[5m]) by (app, proc)))将返回最上面的3个CPU消费服务。

告警可以在Alertmanager中配置,再次使用PromQL语言。Grafana 是一个流行的选项,为Prometheus的指标创建仪表盘。








Prometheus的设计决策

这里从Prometheus的度量终点开始,这些端点定义度量标准和值,并通过HTTP公开,它们为手机度量标准提供了一种标准化的方法,Prometheus度量遵循了度量2.0所指定的许多准则:度量标准有名称、描述、维度和值。唯一缺少的是度量单位。

许多服务度暴露了Prometheus端点,这使得收集它们非常容易,对没有本地Prometheus端点的其他服务,则需要转换器。这意味着对于这些服务,必须部署一个额外的Sidecar容器,以公开Prometheus格式的字表。

在这里讨论的第二个设计决定是拉力和推力,Prometheus调查服务的指标,这意味着如果您想要使用Prometheus监控的所有服务都应该公开Prometheus度量端点,Prometheus使用服务发现,它与Kubernetes很好的集成在一起,以找到所有的服务一旦它找到了所有服务,将通过轮询其他Prometheus度量端点收集所有这些服务的指标。

容器

Pull方法的优点是不需要安装代理,而且可以通过多个Prometheus实例来提取指标。

而缺点同样明显:

对于Prometheus的使用者来说,所有的公制端点都必须是可达的,这意味着一个更加复杂的安全网络配置。

在大型部署中,扩展成为一个问题,Prometheus建议采用一种基于推特的方法来收集短期的工作指标。

Prometheus的主要设计目标之一是操作简单性。这样,Prometheus就限制了监控系统的可能失效模式数量,遵循着一原则,Prometheus目前只局限于单个点,因为集群带来了额外的操作复杂性,使用单个节点不那么复杂,但是对可以由Prometheus监控的度量指标适量有着严格的限制。

Prometheus不解决的问题

Prometheus并不打算解决几个方面的问题:

首先是对日志的支持:这两个指标和日志都是为用户的应用程序提供完全可见性的必要部分,但是已经有大量的开源和闭源日志聚合器来管理日志。

Prometheus也不提供持久的长期存储、异常检测、自动水平缩放和用户管理,但从作者的客户基础上,看到在多数企业环境中都需要这些特性。

Prometheus不是一个Dashboarding解决方案,它提供了一个简单的UI来进行PromQL查询,但它依赖于移植物的操作,增加了一些额外的设置复杂度。

Prometheus与Digital Ocean

在2016年的PromCon演讲中,来自Digital Ocean的Matthew Campbell解释了它们如何将Prometheus扩展到100万台的,在演讲当中,他解释了他们是怎样从一个默认的Prometheus装置开始的,以及他们必须改变什么,才能让它变得更大。

他们以每天数据中心的一台Prometheus机开始,遇到了可伸缩性问题,并创建了更大的机器来运行Prometheus。一旦他们将机器按最大尺寸缩放,他们将系统保留时间减少到3天,并决定放弃某些指标。这种方法只能到目前为止,因此他们决定根据节点标签进一步提高他们的Prometheus,这种方法的困难在于,查询变得更加困难,他们最终实现了一个从多个碎片收集数据的Prometheus代理,他们无法用这种方法解决更大的问题是碎片重新分配和过度供应。

当从1万个服务器扩展到100万个虚拟机时,他们决定采取不同的方法,创建了一个“反向节点出口商”,它基本上是安装在节点上的代理,并将数据推到一个中心点,在后端方面,他们也做了重大的改变:保留了Prometheus API,但添加了一个Kafka集群,用于传入的指标和Cassandra的度量存储,他们还介绍了采样,这个项目被称为Vulcan,可用作开源。

Vulcan所采取的方法看起来很像CoScale所采取的方法,还使用代理和可伸缩、高可用的后端。

CoScal在哪里合适?

我们相信有一个标准化的度量格式有很大的价值,这使得从不同类型的服务中心收集指标变得很容易,CoScale提供了一个Prometheus插件,它收集了在Prometheus格式中暴露的指标,这使得您可以轻松地从已启动的服务中获得指标。

但是仍然有很多服务没有暴露出Prometheus端点。为这些服务部署一个转换器非常麻烦,CoScale有广泛的插件,支持多种服务的本地度量机制;录用日志、Api和其他线程的度量计数器。我们还提供了收集自定义指标的不同选项。

CoScale提供了一个可扩展的插件,包括一个代理和和一个可扩展的、高可用的后端作为SaaS和On-Premise,CoScale提供了Metrics,指标,和事件存储(短期和长期),直观的仪表盘,告警和异常检测。

Prometheus 2.0

Prometheus 1.0于2016年7月发布,就在前几天,Prometheus发布了2.0的版本,带来了巨大的性能改进,并变得更容易操作,下面让我们看看这个版本都有哪些方面的改进。

许多公司和组织都采用了Prometheus,这个项目很快就拥有了一大批的活跃粉丝(开发人员)以及技术社区。5月的时候就传出Prometheus 2.0版本的前瞻预测,据说会有一个很大的改进是,有新的存储层,这意味着极大地提高了Kubernetes和其他分布式系统的监控可伸缩性。

Prometheus有一个简单而健壮的操作模式,然而,基础设施领域也在逐步发展,如Kubernetes何Mesos这样的项目迅速地改变了应用部署和管理的方式,受监控的环境变得越来越动态化。

Prometheus存储子系统需要仔细配置预期负载,虽然在Prometheus 1.6中,自动调谐能力让其大为减轻,但用户仍然会遇到一些不可避免的硬限制。

存储

2017年,事情逐步发生改变,最初作为一种新的,更高效的时间序列数据库的实验,在实际的基准测试中得到了验证,在过去的6个月当中,Prometheus的开发团队一直在忙着稳定这个独立的时间序列数据库,并将其重新整合到Prometheus本身,其结果上,几乎所有的维度上都有了改进,从而显著地提高了Prometheus 2.0的性能,查询延迟更为一致,特别是在高串扰的情况下,在不同的实际生产场景中,度量的资源消耗也显著减少:

与Prometheus 1.8相比,CPU使用率降低了20%-40%
与Prometheus 1.8相比,磁盘空间使用减少到33%-50%
没有太多查询负载的磁盘I/O通常小于1%








在未来的几年里,它还可以处理现代计算环境日益增长的动态特性。

Staleness handling

此外,许多以小见大的变化使得Prometheus更加直观,最值得注意的是Staleness处理,它是最古老和最需要路线图的项目之一,随着新的改进,从这些目标中消失的监控目标或系列已经被明确跟踪,这减少了人工查询,增强了告警响应能力。

其他改进

Prometheus 2.0还内置了对整个数据库快照备份的支持。

同时,还将记录和告警规则从一个自定义格式迁移到无处不在的YAML格式,这使得集成配置管理和模块变得更加容易。

其他的变动改进请参看:https://prometheus.io/docs/pro ... tion/

未来计划

会将新的存储子系统设计为可访问和可扩展的,这就需要将新特性直接集成到Prometheus中,以及可以在它之上构建的定制工具,简单而开放的存储格式和库也允许用户轻松构建自定义扩展,比如动态保留策略,这使得存储层能够满足广泛的需求,而无需将复杂性引入到Prometheus本身中,让它专注于它的核心目标。 查看全部

1.png

 
关于容器监控,数人云之前给大家分享了《解惑|你是否为容器监控操碎了心?》,就有有Prometheus的身影,那么它都有哪些优缺点?近日发布的2.0版本又有哪些改进?本文见分晓~

Prometheus解决了Devs如何监控高动态容器环境的问题,在本文中,Frederick Ryckbosch讲述了使用Prometheus的优点和缺点,以及它到底有多大的伸缩性。

Prometheus是一个基于时间序列的数值数据的监控解决方案,这是一个开源项目,由前Google员工在SoundCloud启动,他们希望监控一个高度动态的容器环境,因为对传统的监控工具不甚满意,所以开发出Prometheus,并在上面进行工作。

在本文中,我们将讨论Prometheus的重要设计决策及其影响,将重点讨论“ Digital Ocean”如何成功地将Prometheus扩展到100万台机器,以及在使用Coscale时如何利用Prometheus。

Prometheus是如何工作的

要使用Prometheus监控服务,服务需要公开一个Prometheus端点,这端点是一个HTTP借口,它公开了度量的列表和当前的值。

Prometheus提供了广泛的服务发现选项,以查找您的服务并从它们开始检索度量数据。Prometheus服务器轮询服务的指标接口并存储数据。

在Prometheus UI中,用户可以在PromQL语言中编写查询以提取度量信息。

例如:topk(3, sum(rate(container_cpu_time[5m]) by (app, proc)))将返回最上面的3个CPU消费服务。

告警可以在Alertmanager中配置,再次使用PromQL语言。Grafana 是一个流行的选项,为Prometheus的指标创建仪表盘。


2.png



Prometheus的设计决策

这里从Prometheus的度量终点开始,这些端点定义度量标准和值,并通过HTTP公开,它们为手机度量标准提供了一种标准化的方法,Prometheus度量遵循了度量2.0所指定的许多准则:度量标准有名称、描述、维度和值。唯一缺少的是度量单位。

许多服务度暴露了Prometheus端点,这使得收集它们非常容易,对没有本地Prometheus端点的其他服务,则需要转换器。这意味着对于这些服务,必须部署一个额外的Sidecar容器,以公开Prometheus格式的字表。

在这里讨论的第二个设计决定是拉力和推力,Prometheus调查服务的指标,这意味着如果您想要使用Prometheus监控的所有服务都应该公开Prometheus度量端点,Prometheus使用服务发现,它与Kubernetes很好的集成在一起,以找到所有的服务一旦它找到了所有服务,将通过轮询其他Prometheus度量端点收集所有这些服务的指标。

容器

Pull方法的优点是不需要安装代理,而且可以通过多个Prometheus实例来提取指标。

而缺点同样明显:

对于Prometheus的使用者来说,所有的公制端点都必须是可达的,这意味着一个更加复杂的安全网络配置。

在大型部署中,扩展成为一个问题,Prometheus建议采用一种基于推特的方法来收集短期的工作指标。

Prometheus的主要设计目标之一是操作简单性。这样,Prometheus就限制了监控系统的可能失效模式数量,遵循着一原则,Prometheus目前只局限于单个点,因为集群带来了额外的操作复杂性,使用单个节点不那么复杂,但是对可以由Prometheus监控的度量指标适量有着严格的限制。

Prometheus不解决的问题

Prometheus并不打算解决几个方面的问题:

首先是对日志的支持:这两个指标和日志都是为用户的应用程序提供完全可见性的必要部分,但是已经有大量的开源和闭源日志聚合器来管理日志。

Prometheus也不提供持久的长期存储、异常检测、自动水平缩放和用户管理,但从作者的客户基础上,看到在多数企业环境中都需要这些特性。

Prometheus不是一个Dashboarding解决方案,它提供了一个简单的UI来进行PromQL查询,但它依赖于移植物的操作,增加了一些额外的设置复杂度。

Prometheus与Digital Ocean

在2016年的PromCon演讲中,来自Digital Ocean的Matthew Campbell解释了它们如何将Prometheus扩展到100万台的,在演讲当中,他解释了他们是怎样从一个默认的Prometheus装置开始的,以及他们必须改变什么,才能让它变得更大。

他们以每天数据中心的一台Prometheus机开始,遇到了可伸缩性问题,并创建了更大的机器来运行Prometheus。一旦他们将机器按最大尺寸缩放,他们将系统保留时间减少到3天,并决定放弃某些指标。这种方法只能到目前为止,因此他们决定根据节点标签进一步提高他们的Prometheus,这种方法的困难在于,查询变得更加困难,他们最终实现了一个从多个碎片收集数据的Prometheus代理,他们无法用这种方法解决更大的问题是碎片重新分配和过度供应。

当从1万个服务器扩展到100万个虚拟机时,他们决定采取不同的方法,创建了一个“反向节点出口商”,它基本上是安装在节点上的代理,并将数据推到一个中心点,在后端方面,他们也做了重大的改变:保留了Prometheus API,但添加了一个Kafka集群,用于传入的指标和Cassandra的度量存储,他们还介绍了采样,这个项目被称为Vulcan,可用作开源。

Vulcan所采取的方法看起来很像CoScale所采取的方法,还使用代理和可伸缩、高可用的后端。

CoScal在哪里合适?

我们相信有一个标准化的度量格式有很大的价值,这使得从不同类型的服务中心收集指标变得很容易,CoScale提供了一个Prometheus插件,它收集了在Prometheus格式中暴露的指标,这使得您可以轻松地从已启动的服务中获得指标。

但是仍然有很多服务没有暴露出Prometheus端点。为这些服务部署一个转换器非常麻烦,CoScale有广泛的插件,支持多种服务的本地度量机制;录用日志、Api和其他线程的度量计数器。我们还提供了收集自定义指标的不同选项。

CoScale提供了一个可扩展的插件,包括一个代理和和一个可扩展的、高可用的后端作为SaaS和On-Premise,CoScale提供了Metrics,指标,和事件存储(短期和长期),直观的仪表盘,告警和异常检测。

Prometheus 2.0

Prometheus 1.0于2016年7月发布,就在前几天,Prometheus发布了2.0的版本,带来了巨大的性能改进,并变得更容易操作,下面让我们看看这个版本都有哪些方面的改进。

许多公司和组织都采用了Prometheus,这个项目很快就拥有了一大批的活跃粉丝(开发人员)以及技术社区。5月的时候就传出Prometheus 2.0版本的前瞻预测,据说会有一个很大的改进是,有新的存储层,这意味着极大地提高了Kubernetes和其他分布式系统的监控可伸缩性。

Prometheus有一个简单而健壮的操作模式,然而,基础设施领域也在逐步发展,如Kubernetes何Mesos这样的项目迅速地改变了应用部署和管理的方式,受监控的环境变得越来越动态化。

Prometheus存储子系统需要仔细配置预期负载,虽然在Prometheus 1.6中,自动调谐能力让其大为减轻,但用户仍然会遇到一些不可避免的硬限制。

存储

2017年,事情逐步发生改变,最初作为一种新的,更高效的时间序列数据库的实验,在实际的基准测试中得到了验证,在过去的6个月当中,Prometheus的开发团队一直在忙着稳定这个独立的时间序列数据库,并将其重新整合到Prometheus本身,其结果上,几乎所有的维度上都有了改进,从而显著地提高了Prometheus 2.0的性能,查询延迟更为一致,特别是在高串扰的情况下,在不同的实际生产场景中,度量的资源消耗也显著减少:

与Prometheus 1.8相比,CPU使用率降低了20%-40%
与Prometheus 1.8相比,磁盘空间使用减少到33%-50%
没有太多查询负载的磁盘I/O通常小于1%


3.png



在未来的几年里,它还可以处理现代计算环境日益增长的动态特性。

Staleness handling

此外,许多以小见大的变化使得Prometheus更加直观,最值得注意的是Staleness处理,它是最古老和最需要路线图的项目之一,随着新的改进,从这些目标中消失的监控目标或系列已经被明确跟踪,这减少了人工查询,增强了告警响应能力。

其他改进

Prometheus 2.0还内置了对整个数据库快照备份的支持。

同时,还将记录和告警规则从一个自定义格式迁移到无处不在的YAML格式,这使得集成配置管理和模块变得更加容易。

其他的变动改进请参看:https://prometheus.io/docs/pro ... tion/

未来计划

会将新的存储子系统设计为可访问和可扩展的,这就需要将新特性直接集成到Prometheus中,以及可以在它之上构建的定制工具,简单而开放的存储格式和库也允许用户轻松构建自定义扩展,比如动态保留策略,这使得存储层能够满足广泛的需求,而无需将复杂性引入到Prometheus本身中,让它专注于它的核心目标。

SRE|当Google的核心准则遇到Xero的最佳实践

杨y 发表了文章 • 0 个评论 • 24 次浏览 • 2017-11-14 15:55 • 来自相关话题

关于SRE,数人云之前给大家分享很多相关的文章,想必大家已经有了一定的了解,今天给大家带来的这篇文章,分别从Xero和Google的角度讨论一些工具和框架,以及SRE的一些准则。

Xero的SRE之路

作为一个SRE,作者主要关心的是如何保持应用平台的稳定,减少崩溃,然而这也是不能避免的,本文会通过Xero的SRE经验去讨论一些工具和框架。

任何故障的开始都是至关重要的,因此需要在发现故障的第一时间就提醒能解决问题的人。

大多数的生产问题,都是通过监控基础设施进行检测的,用于告警的通道工具已经随着时间的推移而发生了变化,但是基本的流程仍然大同小异,如下图所示:






自动告警Pipeline

自动化Pipeline可以确保工程师快速、正确、一致和可靠的进行工作,理想的情况下, 所有的告警都应该是自动化的,但有时我们会接触到一些没有被发现的问题,所以希望有一种方法可以允许其他团队报告保留自动告警Pipeline,因此决定将这些请求转换为自动告警,如下所示:






 
手动报警Pipeline

使用这种方法,自动和手动告警都以同样的方式送达工程师,但是每个告警都有什么呢?

剖析一个告警

出现了什么错误?问题的性质和严重性?
故障出现后,都有哪些地方收到了影响?
它怎么能固定下来呢?链接到Runbooks或者How-to文档。

尝试编写自动告警模板以满足这些需求,对于手工报告的问题,依赖于通过在线表单提供这些信息,希望填写表格的过程是速度且无痛的,所以只有第一个问题是强制性的:

能否概括一下这个问题,比如,到底出了什么问题?
哪个站点/URL有问题?可以帮助识别受影响的地方。
问题是否仅限于特定的地点,帮助我们隔离网络/CDN问题。
问题是什么时候开始的?帮助设置日志/度量搜索的时间尺度。
谁在关注这些问题?这样可以将它们包含在事件的Pipeline中

虽然这些信息不可能如监控系统所提供的那样具体明确,但它仍然可以减少SRE工程师所需要的调查工作。

On-call as code

我们使用第三方的呼叫管理系统,允许我们建立多个On-call团队,定义每个团队的轮换,并将每个团队连接到监控基础设施,告警是针对拥有受影响系统的团队的,但是SRE为每个团队提供了额外的层,如下所示:








告警升级

在20多个产品和服务的呼叫团队中,On-call管理配置已经演化为相当复杂的设置,随着越来越多的团队加入其中,我们的支持模式也在不断地发展,要手动设置所有的东西将是一项艰巨的任务,处于这个原因,我们创建了一个“On-call as code”系统,类似于Chef这样的基础设施代码框架。








On-call configuration pipeline

延伸阅读:

Chef 是一款自动化服务器配置管理工具,可以对所管理的对象实行自动化配置,如系统管理,安装软件等。Chef 由三大组件组成:Chef Server、Chef Workstation 和 Chef Node。

Chef Server 是核心服务器,维护了一套配置脚本(Cookbook),与每个被管节点(Chef Node)交互并给出配置指令。

Chef Workstation 提供了我们与 Chef Server 交互的接口:我们在 Workstation 上创建定义 Cookbook,并将 Cookbook 上传到 Chef Server 上以保证被管机器能从 Chef Server 上取得最新的配置指令。

Chef Node 是安装了 chef-client 并注册了的被管理节点,可以是物理机或者虚拟机或者其他对象。Chef Node 每次运行 chef-client 时都会从 Chef Server 端取得最新的配置指令(Cookbook)并按照指令配置自己。 一套 Chef 环境包含一个 Chef Server,至少一个 Chef Workstation,以及一到多个 Chef Node。

团队可以通过将更改合并到Git存储库来更新他们的调用配置,然后,CI/CD系统运行一个Rake任务,它通过调用管理系统来同步存储库,这种方法为我们提供了一系列的好处:

所有的配置更改都可以通过标准的Git工作流进行同行评审。

CI服务器可以“Lint”每个配置更改,以验证它满足一些基本需求(例如,每个团队需要一个管理员)。

允许团队手动设置他们的调用轮换,因为On-call系统的Web界面提供了一种简单的方法,然而,团队调用设置的所有其他组件都由同步任务执行。

新团队不需要担心设置他们的告警端点或将他们的团队与SRE的时间表联系起来,同步任务从一个最小的配置文件自动地构建每个团队的调用配置,如果团队需要一个不寻常的调用设置,那他们就可以置顶额外的配置文件来这样做。

未来,可以很容易地改变所有团队的标准调用配置,例如更改每次升级之间的时间限制。

在这些倡议中,我们为管理良好的时间奠定了基础:

告警以相同的方式发出,无论它们是自动检测还是手动报告。

每个告警的内容都包含了足够的信息,让工程师开始计划响应。

On-Call作为代码系统,确保所有的团队都能以一致的方式接受告警。

虽然工作流程、优先级和日常操作从SRE团队到另一个SRE团队之间都有细微的差别,但都与他们支持的服务有着基本的信任,并坚持相同的核心原则。

一般来说,SRE团队负责可用性、延迟性、性能、效率、变更管理、监控、紧急响应以及服务的容量规划。

我们已经为SRE团队与其环境交互(不仅仅是生产环境,还包括开发团队、测试团队、用户等等)制定了相关的规则和原则,这些规则和工作实践帮助我们保持对工程工作的关注,而不是运维工作。

Google SRE准则
确保持久专注于工程

Google在50%的时间内为SREs的运维工作设置上限,他们的剩余时间应该用在项目工作的编程技能上,在实践当中,这是通过监控SRE们所做的运维工作数量来完成的,并将多余的运维工作重新定向到产品开发团队:重新分配Bug将开发人员集成到On-Call pager roUNK中等等。

当运维负载下降到50%或更低时,重新向结束,这也提供了一个有效的反馈机制,引导开发人员构建不需要人工干预的系统,当整个组织——SRE和开发人员理解为什么这个机制存在时,这种方法很有效,并且支持没有溢出事件的目标,因为产品没有产生足够的运维负载来要求她。

当他们专注于运维工作时,在平均每8-12小时中,SRE应该最多接受两个事件,这个目标量给呼叫工程师足够的时间准确快速地处理事件,清理和恢复正常服务,然后进行事后剖析,如果有两个以上的事件经常发生在呼叫转移上,问题就无法彻底调查,工程师们也无法从这些事件中吸取教训,一种寻呼机疲劳的情况下也不会随着规模而提高,相反,如果每次转换时,调用的SRE始终接受不到一个事件,那么这就无异于在浪费时间。

对于所有重大事件,无论是否寻呼,都应该写死后的纪录,没有触发界面的后期纪录甚至更有价值,因为它们可能指出了明显的监控漏洞,这个调查应该确定发生的细节,找出事件的所有根源,并分配行动来纠正问题化或改进下次处理的方法,Google在一个免费的分析文化下运行,目标是揭露出错误并应用工程来修复这些错误,而不是去避免或尽量最小化它们。

追求最大的变化速度而不违反服务的SLO

产品开发和SRE团队可以通过消除各自目标中的结构性冲突来享受高效的工作关系,结构冲突是在创新和产品稳定性之间,正如前面所述,这种冲突往往是间接表达的,在SRE中,我们将这个冲突引入到前面,然后通过引入错误预算来解决它。

预算错误源于这样一种观察, 即100%是所有东的错误可靠性目标,一般来说,对于任何软件服务或系统100%可用和99.999%可用,有许多其他系统用户和服务之间的路径(他们的笔记本电脑,家里的WIFI,ISP,电网……),这些系统集体远远低于99.999%,因此,99.999……和100%的差异在于其他不可用性的丢失,而且用户无法从需要添加走货0.001%的可用性中获益。

如果100%是一个系统的错误可靠性目标,那么,系统的正确可靠性目标是什么?这实际上并不是一个技术问题——这是一个产品问题,应该考虑以下因素:

考虑到他们是如何使用产品的,用户满意的程度是多少?

对于那些对产品的可用性不满意的用户有什么选择?

用户在不同可用级别上使用该产品会发生什么情况?

业务或产品必须建立系统的可用性目标,一旦确定了目标,错误预算就是一个减去可用性的目标。一个99.99%可用服务是0.01的不可用,允许0.01的不可用性是服务的错误预算,我们可以把预算画在问么想要的任何东西上,只要不超支。

那么要如何花费这个错误预算呢?开发团队希望推出特性并吸引新用户,理想情况下,我们会把所有的错误预算都花在我们发布的新产品上,以快速启动它们,这个基本前提描述了整个错误预算模型,一旦SRE活动在这个框架中被概念化,通过注入阶段性的滚转和1%的实验等策略释放错误预算,可以优化更快的启动。

错误预算的使用解决了开发和SRE之间的结构冲突,SRE的目标实在是“0消耗”;相反,SRE和产品开发人员的目标是将错误预算花在获得最大特征速度上,这种改变造成了不同,宕机不再是“坏”的事情——它是创新过程中预期的一部分,而且发展和SRE团队都在管理,而不是一直忧心忡忡。

监控

监控是服务所有者跟踪系统的健康和可用性的主要手段之一,因此,应当深思熟虑地构建监控策略,一个典型的、常见的监控方法是观察特定的值或条件,然后在超过该值或条件时触发电子邮件告警,然而,这种类型的电子邮件告警并不是一个有效的解决方案;一个需要一个人阅读电子邮件并决定是否需要采取某种行动的系统从根本上是有缺陷的,监控不应该要求人对告警区域的任何部分进行解释,相反,应用应做口译,只有当它们需要采取行动时,才去通知SRE。

三种有效地监控输出:

告警:意味着SRE需要立即采取行动来应对正在发生或即将发生的事情,以改善这种情况。

Tickets:表示SRE需要采取行动,但不是马上,系统不能自动处理这种情况,但如果一个人在几天内采取了动作,就不会造成事故。

日志记录:无需日日查看的信息,但它被记录为诊断错误或反刍的目的。

应急响应

可靠性是指故障时间(MTTF)和平均修复时间(MTTR)的函数,评估应急反应有效性地最相关的指标是反应小组能多快地将系统恢复到健康状态,即MTTR。 一个能够避免需要人工干预的紧急情况的系统比需要实际操作的系统有更高的可用性,当SRE有需求时,我们发现,在“剧本”中提前记录是最佳实践,在MTTR中产生大约3倍的改进,而不是“即兴发挥”的策略,谷歌SRE依赖于on -call playbooks,除了诸如“不幸之轮”这样的练习,还可以让工程师对on - call事件做出反应。

效率和性能

任何时候,有效利用资源都是非常重要的,由于SRE最终控制了供应,因此它也必须参与任何有关使用的工作,因为利用率是给定服务如何工作的一个函数,以及它是如何响应的。密切关注服务的供应策略,它的使用为服务的总成本提供了非常大的杠杆。

资源使用是需求(负载)、容量和应用效率的函数。SRE预测需求,提供能力,并可以修改软件,这三个因素是服务效率的很大一部分(尽管不是全部)。

随着负载的增加,应用系统会变得越来越慢,服务的减少等同于能力的丧失,在某一个时刻,当某个缓慢的系统停止服务,这相当于无限的慢。SRE提供以特性的响应速度满足容量目标,因此对服务的性能非常感兴趣,SRE和产品开发人员将(并且应该)监控和修改服务以提高其性能,从而增加容量和提高效率。

以上是小数今天给大家分享的文章,众所周知,SRE的理念最早出自Google,而数人云老王(王璞)曾供职于Google的广告部门,对于SRE有着深入的研究,在数人云的Meetup上就曾以SRE为题进行了多次分享,同时小数也给大家分享了多篇SRE相关的文章,有兴趣的可以点击查看: 查看全部

1.png



关于SRE,数人云之前给大家分享很多相关的文章,想必大家已经有了一定的了解,今天给大家带来的这篇文章,分别从Xero和Google的角度讨论一些工具和框架,以及SRE的一些准则。

Xero的SRE之路

作为一个SRE,作者主要关心的是如何保持应用平台的稳定,减少崩溃,然而这也是不能避免的,本文会通过Xero的SRE经验去讨论一些工具和框架。

任何故障的开始都是至关重要的,因此需要在发现故障的第一时间就提醒能解决问题的人。

大多数的生产问题,都是通过监控基础设施进行检测的,用于告警的通道工具已经随着时间的推移而发生了变化,但是基本的流程仍然大同小异,如下图所示:


2.png

自动告警Pipeline

自动化Pipeline可以确保工程师快速、正确、一致和可靠的进行工作,理想的情况下, 所有的告警都应该是自动化的,但有时我们会接触到一些没有被发现的问题,所以希望有一种方法可以允许其他团队报告保留自动告警Pipeline,因此决定将这些请求转换为自动告警,如下所示:


3.png

 
手动报警Pipeline

使用这种方法,自动和手动告警都以同样的方式送达工程师,但是每个告警都有什么呢?

剖析一个告警

出现了什么错误?问题的性质和严重性?
故障出现后,都有哪些地方收到了影响?
它怎么能固定下来呢?链接到Runbooks或者How-to文档。

尝试编写自动告警模板以满足这些需求,对于手工报告的问题,依赖于通过在线表单提供这些信息,希望填写表格的过程是速度且无痛的,所以只有第一个问题是强制性的:

能否概括一下这个问题,比如,到底出了什么问题?
哪个站点/URL有问题?可以帮助识别受影响的地方。
问题是否仅限于特定的地点,帮助我们隔离网络/CDN问题。
问题是什么时候开始的?帮助设置日志/度量搜索的时间尺度。
谁在关注这些问题?这样可以将它们包含在事件的Pipeline中

虽然这些信息不可能如监控系统所提供的那样具体明确,但它仍然可以减少SRE工程师所需要的调查工作。

On-call as code

我们使用第三方的呼叫管理系统,允许我们建立多个On-call团队,定义每个团队的轮换,并将每个团队连接到监控基础设施,告警是针对拥有受影响系统的团队的,但是SRE为每个团队提供了额外的层,如下所示:


4.png



告警升级

在20多个产品和服务的呼叫团队中,On-call管理配置已经演化为相当复杂的设置,随着越来越多的团队加入其中,我们的支持模式也在不断地发展,要手动设置所有的东西将是一项艰巨的任务,处于这个原因,我们创建了一个“On-call as code”系统,类似于Chef这样的基础设施代码框架。


5.png



On-call configuration pipeline

延伸阅读:

Chef 是一款自动化服务器配置管理工具,可以对所管理的对象实行自动化配置,如系统管理,安装软件等。Chef 由三大组件组成:Chef Server、Chef Workstation 和 Chef Node。

Chef Server 是核心服务器,维护了一套配置脚本(Cookbook),与每个被管节点(Chef Node)交互并给出配置指令。

Chef Workstation 提供了我们与 Chef Server 交互的接口:我们在 Workstation 上创建定义 Cookbook,并将 Cookbook 上传到 Chef Server 上以保证被管机器能从 Chef Server 上取得最新的配置指令。

Chef Node 是安装了 chef-client 并注册了的被管理节点,可以是物理机或者虚拟机或者其他对象。Chef Node 每次运行 chef-client 时都会从 Chef Server 端取得最新的配置指令(Cookbook)并按照指令配置自己。 一套 Chef 环境包含一个 Chef Server,至少一个 Chef Workstation,以及一到多个 Chef Node。

团队可以通过将更改合并到Git存储库来更新他们的调用配置,然后,CI/CD系统运行一个Rake任务,它通过调用管理系统来同步存储库,这种方法为我们提供了一系列的好处:

所有的配置更改都可以通过标准的Git工作流进行同行评审。

CI服务器可以“Lint”每个配置更改,以验证它满足一些基本需求(例如,每个团队需要一个管理员)。

允许团队手动设置他们的调用轮换,因为On-call系统的Web界面提供了一种简单的方法,然而,团队调用设置的所有其他组件都由同步任务执行。

新团队不需要担心设置他们的告警端点或将他们的团队与SRE的时间表联系起来,同步任务从一个最小的配置文件自动地构建每个团队的调用配置,如果团队需要一个不寻常的调用设置,那他们就可以置顶额外的配置文件来这样做。

未来,可以很容易地改变所有团队的标准调用配置,例如更改每次升级之间的时间限制。

在这些倡议中,我们为管理良好的时间奠定了基础:

告警以相同的方式发出,无论它们是自动检测还是手动报告。

每个告警的内容都包含了足够的信息,让工程师开始计划响应。

On-Call作为代码系统,确保所有的团队都能以一致的方式接受告警。

虽然工作流程、优先级和日常操作从SRE团队到另一个SRE团队之间都有细微的差别,但都与他们支持的服务有着基本的信任,并坚持相同的核心原则。

一般来说,SRE团队负责可用性、延迟性、性能、效率、变更管理、监控、紧急响应以及服务的容量规划。

我们已经为SRE团队与其环境交互(不仅仅是生产环境,还包括开发团队、测试团队、用户等等)制定了相关的规则和原则,这些规则和工作实践帮助我们保持对工程工作的关注,而不是运维工作。

Google SRE准则
确保持久专注于工程

Google在50%的时间内为SREs的运维工作设置上限,他们的剩余时间应该用在项目工作的编程技能上,在实践当中,这是通过监控SRE们所做的运维工作数量来完成的,并将多余的运维工作重新定向到产品开发团队:重新分配Bug将开发人员集成到On-Call pager roUNK中等等。

当运维负载下降到50%或更低时,重新向结束,这也提供了一个有效的反馈机制,引导开发人员构建不需要人工干预的系统,当整个组织——SRE和开发人员理解为什么这个机制存在时,这种方法很有效,并且支持没有溢出事件的目标,因为产品没有产生足够的运维负载来要求她。

当他们专注于运维工作时,在平均每8-12小时中,SRE应该最多接受两个事件,这个目标量给呼叫工程师足够的时间准确快速地处理事件,清理和恢复正常服务,然后进行事后剖析,如果有两个以上的事件经常发生在呼叫转移上,问题就无法彻底调查,工程师们也无法从这些事件中吸取教训,一种寻呼机疲劳的情况下也不会随着规模而提高,相反,如果每次转换时,调用的SRE始终接受不到一个事件,那么这就无异于在浪费时间。

对于所有重大事件,无论是否寻呼,都应该写死后的纪录,没有触发界面的后期纪录甚至更有价值,因为它们可能指出了明显的监控漏洞,这个调查应该确定发生的细节,找出事件的所有根源,并分配行动来纠正问题化或改进下次处理的方法,Google在一个免费的分析文化下运行,目标是揭露出错误并应用工程来修复这些错误,而不是去避免或尽量最小化它们。

追求最大的变化速度而不违反服务的SLO

产品开发和SRE团队可以通过消除各自目标中的结构性冲突来享受高效的工作关系,结构冲突是在创新和产品稳定性之间,正如前面所述,这种冲突往往是间接表达的,在SRE中,我们将这个冲突引入到前面,然后通过引入错误预算来解决它。

预算错误源于这样一种观察, 即100%是所有东的错误可靠性目标,一般来说,对于任何软件服务或系统100%可用和99.999%可用,有许多其他系统用户和服务之间的路径(他们的笔记本电脑,家里的WIFI,ISP,电网……),这些系统集体远远低于99.999%,因此,99.999……和100%的差异在于其他不可用性的丢失,而且用户无法从需要添加走货0.001%的可用性中获益。

如果100%是一个系统的错误可靠性目标,那么,系统的正确可靠性目标是什么?这实际上并不是一个技术问题——这是一个产品问题,应该考虑以下因素:

考虑到他们是如何使用产品的,用户满意的程度是多少?

对于那些对产品的可用性不满意的用户有什么选择?

用户在不同可用级别上使用该产品会发生什么情况?

业务或产品必须建立系统的可用性目标,一旦确定了目标,错误预算就是一个减去可用性的目标。一个99.99%可用服务是0.01的不可用,允许0.01的不可用性是服务的错误预算,我们可以把预算画在问么想要的任何东西上,只要不超支。

那么要如何花费这个错误预算呢?开发团队希望推出特性并吸引新用户,理想情况下,我们会把所有的错误预算都花在我们发布的新产品上,以快速启动它们,这个基本前提描述了整个错误预算模型,一旦SRE活动在这个框架中被概念化,通过注入阶段性的滚转和1%的实验等策略释放错误预算,可以优化更快的启动。

错误预算的使用解决了开发和SRE之间的结构冲突,SRE的目标实在是“0消耗”;相反,SRE和产品开发人员的目标是将错误预算花在获得最大特征速度上,这种改变造成了不同,宕机不再是“坏”的事情——它是创新过程中预期的一部分,而且发展和SRE团队都在管理,而不是一直忧心忡忡。

监控

监控是服务所有者跟踪系统的健康和可用性的主要手段之一,因此,应当深思熟虑地构建监控策略,一个典型的、常见的监控方法是观察特定的值或条件,然后在超过该值或条件时触发电子邮件告警,然而,这种类型的电子邮件告警并不是一个有效的解决方案;一个需要一个人阅读电子邮件并决定是否需要采取某种行动的系统从根本上是有缺陷的,监控不应该要求人对告警区域的任何部分进行解释,相反,应用应做口译,只有当它们需要采取行动时,才去通知SRE。

三种有效地监控输出:

告警:意味着SRE需要立即采取行动来应对正在发生或即将发生的事情,以改善这种情况。

Tickets:表示SRE需要采取行动,但不是马上,系统不能自动处理这种情况,但如果一个人在几天内采取了动作,就不会造成事故。

日志记录:无需日日查看的信息,但它被记录为诊断错误或反刍的目的。

应急响应

可靠性是指故障时间(MTTF)和平均修复时间(MTTR)的函数,评估应急反应有效性地最相关的指标是反应小组能多快地将系统恢复到健康状态,即MTTR。 一个能够避免需要人工干预的紧急情况的系统比需要实际操作的系统有更高的可用性,当SRE有需求时,我们发现,在“剧本”中提前记录是最佳实践,在MTTR中产生大约3倍的改进,而不是“即兴发挥”的策略,谷歌SRE依赖于on -call playbooks,除了诸如“不幸之轮”这样的练习,还可以让工程师对on - call事件做出反应。

效率和性能

任何时候,有效利用资源都是非常重要的,由于SRE最终控制了供应,因此它也必须参与任何有关使用的工作,因为利用率是给定服务如何工作的一个函数,以及它是如何响应的。密切关注服务的供应策略,它的使用为服务的总成本提供了非常大的杠杆。

资源使用是需求(负载)、容量和应用效率的函数。SRE预测需求,提供能力,并可以修改软件,这三个因素是服务效率的很大一部分(尽管不是全部)。

随着负载的增加,应用系统会变得越来越慢,服务的减少等同于能力的丧失,在某一个时刻,当某个缓慢的系统停止服务,这相当于无限的慢。SRE提供以特性的响应速度满足容量目标,因此对服务的性能非常感兴趣,SRE和产品开发人员将(并且应该)监控和修改服务以提高其性能,从而增加容量和提高效率。

以上是小数今天给大家分享的文章,众所周知,SRE的理念最早出自Google,而数人云老王(王璞)曾供职于Google的广告部门,对于SRE有着深入的研究,在数人云的Meetup上就曾以SRE为题进行了多次分享,同时小数也给大家分享了多篇SRE相关的文章,有兴趣的可以点击查看:

Docker?Rkt?Lxd?细说K8S容器进行时的又一选项Containerd

杨y 发表了文章 • 0 个评论 • 42 次浏览 • 2017-11-11 14:18 • 来自相关话题

器运行时是执行容器并在节点上管理容器镜像的软件,目前,最广为人知的容器运行时是Docker,但在生态系统中还有其他容器运行时软件,比如Rkt、Containerd和Lxd。Docker是现在于Kubernetes环境中使用的最常见的容器运行时,今天数人云给大家推荐一个Docker的组件——Containerd,它可能是更好的选择。

本文是由谷歌的软件工程师Lantao Liu和IBM的开源开发者Mike Brown基于自身相关实践,共同编写。

Kubernetes 1.5引入了一个名为容器运行时接口(CRI)的内部插件API,以方便地访问不同的容器运行时,CRI允许Kubernetes使用各种容器运行时,而不需要重新编译。从理论上说,Kubernetes可以使用任何实现CRI的容器运行时管理容器和容器镜像。

在过去的6个月中,来自Google、Docker、IBM、中兴和ZJU的工程师们一直在努力为CRI For Containerd,这个项目被称为cri-containerd,用户可以使用容器作为底层运行时运行Kubernetes集群,并且无需安装Docker。

Containerd

Containerd是一个兼容OCI的核心容器运行时,它被设计为嵌入到更大的系统当中,提供了在一个节点上执行容器和管理镜像的最小功能集,它是由Docker公司发起,并于2017年3月加入了CNCF,Docker引擎本身是建立在早期版本的容器之上,并且很快将更新到最新版本。

与Docker相比,Containerd的规模要小得多,提供了Golang客户端API,而且更专注于可嵌入,较小范围会导致一个更小的代码库,随着时间的推移,其更容器维护以及匹配Kubernetes的需求,如下图所示:












综上所述,从技术的角度来看,Containerd是Kubernetes的容器进行时比较好的选择。

Cri-Containerd

Cri-Containerd是对于容器的一个实现,它在与Kubelet和 Containerd相同的节点上运行,在Kuberntes和Containerd之间的分层中,Cri-Containerd处理来自Kubelet的所有国际服务请求,并使用Containerd管理容器和容器镜像,Cri-Containerd管理这些服务请求,在一定程度上是通过形成Containerd服务请求,同时添加足够的附加功能来去支持CRI需求。






与当前的Docker CRI实现(Dockershim)相比,Cri-Containerd消除了栈中的额外跳转,使堆栈更加稳定和高效。

体系结构







可以通过下面这个例子来演示当Kubele创建一个单一容器的时候,如何使用Cri-Containerd。

Kubelet通过国际运行时服务API调用了Cri-Containerd,用以创建一个Pod;

Cri-Containerd使用Containerd创建和启动一个特殊的暂停容器(沙箱容器),并将该容器放在Pod的Cgroups和名称空间中;

Containerd使用CNI配置了Pod的网络名称空间;

Kubelet随后通过国际服务API调用了“容器”,以拉出应用程序的容器的镜像;

如果镜像不存在于节点,则Cri-Containerd将进一步使用Containerd来拉出镜像;

然后,Kubelet通过“CRI”服务API调了“Cri-Containerd”通过拉取容器的镜像来创建和启动应用程序容器;

Cri-Containerd最终调用Containerd来创建应用程序容器,将其放入Pod的Cgroups和命名空间中,然后启动该容器的新应用程序容器。

在这些步骤之后,将创建并运行一个Pod及其相应的应用程序容器。

现阶段状态

Cri-Containerd V1.0.0-alpha.0是在2017年9月25日发布的。

其功能完备,所有的Kubernetes的特性都得到了支持。

所有的CRI validation test(CRI validation test是一种测试框架,用于验证是否符合Kubernetes的所有要求。地址:https://github.com/kubernetes/ ... on.md)

所有的 Node e2e Test都已通过(用于测试Kubernetes节点级功能的测试框架如Managing Pods、Mounting Volumes等,地址:https://github.com/kubernetes/ ... ts.md)。

若想了解更多关于V1.0-Alpha的相关内容,请前往:https://github.com/kubernetes- ... pha.0

延伸阅读

对于一个多节点集群安装程序,并使用能应用和Kubeadm启动步骤请参见:https://github.com/kubernetes- ... ME.md

若想在Google云端从头创建一个集群,请参见:https://github.com/kelseyhight ... d-way

对于一个自发布Tarball的自定义安装,请参见:https://github.com/kubernetes- ... on.md

对于在本地VM上安装LinuxKit,请参见:https://github.com/linuxkit/li ... netes

下一阶段

Containerd承诺,在下一阶段将主要改进稳定性和可用性方面的问题:

稳定性:

在Kubernetes的测试基础设施上建立一套完整的Kubernetes集成测试,包括Ubuntu、COS(容器化的OS 地址:https://cloud.google.com/conta ... docs/)等等。

积极解决用户报告的任何测试失败和其他问题。

可用性:

提高Crictl(https://github.com/kubernetes- ... tl.md)的用户体验,Crictl是所有的CRI容器运行时的可移植命令行工具,这里的目标是使其易于用于调试和开发场景。

集成Kube-up.sh(https://kubernetes.io/docs/get ... /gce/)帮助用户使用Cri-Containerd来提高Kubernetes集群的生产质量。

改进文档。

预计在2017年底发布V1.0-Beta。

提供建议

Cri-Containerd是一个Kubernetes的孵化器项目,地址:ttps://github.com/kubernetes-incubator/cri-containerd。欢迎提供任何具有建设性的意见和建议,具体的使用入门指南请参见:https://github.com/kubernetes- ... opers

社区

Cri-Containerd是由Kubernetes Signode社区开发和维护的,如有相关的建议,可以加入社区:

Sig-Node社区网站:https://github.com/kubernetes/ ... -node

Slack:Kubernetes(kubernet.slack.com)的sig-节点通道:https://kubernetes.slack.com/

原文作者:Kubernetes 原文链接:http://blog.kubernetes.io/2017 ... erral 查看全部

1.png


器运行时是执行容器并在节点上管理容器镜像的软件,目前,最广为人知的容器运行时是Docker,但在生态系统中还有其他容器运行时软件,比如Rkt、Containerd和Lxd。Docker是现在于Kubernetes环境中使用的最常见的容器运行时,今天数人云给大家推荐一个Docker的组件——Containerd,它可能是更好的选择。

本文是由谷歌的软件工程师Lantao Liu和IBM的开源开发者Mike Brown基于自身相关实践,共同编写。

Kubernetes 1.5引入了一个名为容器运行时接口(CRI)的内部插件API,以方便地访问不同的容器运行时,CRI允许Kubernetes使用各种容器运行时,而不需要重新编译。从理论上说,Kubernetes可以使用任何实现CRI的容器运行时管理容器和容器镜像。

在过去的6个月中,来自Google、Docker、IBM、中兴和ZJU的工程师们一直在努力为CRI For Containerd,这个项目被称为cri-containerd,用户可以使用容器作为底层运行时运行Kubernetes集群,并且无需安装Docker。

Containerd

Containerd是一个兼容OCI的核心容器运行时,它被设计为嵌入到更大的系统当中,提供了在一个节点上执行容器和管理镜像的最小功能集,它是由Docker公司发起,并于2017年3月加入了CNCF,Docker引擎本身是建立在早期版本的容器之上,并且很快将更新到最新版本。

与Docker相比,Containerd的规模要小得多,提供了Golang客户端API,而且更专注于可嵌入,较小范围会导致一个更小的代码库,随着时间的推移,其更容器维护以及匹配Kubernetes的需求,如下图所示:

2.png


3.png



综上所述,从技术的角度来看,Containerd是Kubernetes的容器进行时比较好的选择。

Cri-Containerd

Cri-Containerd是对于容器的一个实现,它在与Kubelet和 Containerd相同的节点上运行,在Kuberntes和Containerd之间的分层中,Cri-Containerd处理来自Kubelet的所有国际服务请求,并使用Containerd管理容器和容器镜像,Cri-Containerd管理这些服务请求,在一定程度上是通过形成Containerd服务请求,同时添加足够的附加功能来去支持CRI需求。

4.png


与当前的Docker CRI实现(Dockershim)相比,Cri-Containerd消除了栈中的额外跳转,使堆栈更加稳定和高效。

体系结构

5.png



可以通过下面这个例子来演示当Kubele创建一个单一容器的时候,如何使用Cri-Containerd。

Kubelet通过国际运行时服务API调用了Cri-Containerd,用以创建一个Pod;

Cri-Containerd使用Containerd创建和启动一个特殊的暂停容器(沙箱容器),并将该容器放在Pod的Cgroups和名称空间中;

Containerd使用CNI配置了Pod的网络名称空间;

Kubelet随后通过国际服务API调用了“容器”,以拉出应用程序的容器的镜像;

如果镜像不存在于节点,则Cri-Containerd将进一步使用Containerd来拉出镜像;

然后,Kubelet通过“CRI”服务API调了“Cri-Containerd”通过拉取容器的镜像来创建和启动应用程序容器;

Cri-Containerd最终调用Containerd来创建应用程序容器,将其放入Pod的Cgroups和命名空间中,然后启动该容器的新应用程序容器。

在这些步骤之后,将创建并运行一个Pod及其相应的应用程序容器。

现阶段状态

Cri-Containerd V1.0.0-alpha.0是在2017年9月25日发布的。

其功能完备,所有的Kubernetes的特性都得到了支持。

所有的CRI validation test(CRI validation test是一种测试框架,用于验证是否符合Kubernetes的所有要求。地址:https://github.com/kubernetes/ ... on.md

所有的 Node e2e Test都已通过(用于测试Kubernetes节点级功能的测试框架如Managing Pods、Mounting Volumes等,地址:https://github.com/kubernetes/ ... ts.md)。

若想了解更多关于V1.0-Alpha的相关内容,请前往:https://github.com/kubernetes- ... pha.0

延伸阅读

对于一个多节点集群安装程序,并使用能应用和Kubeadm启动步骤请参见:https://github.com/kubernetes- ... ME.md

若想在Google云端从头创建一个集群,请参见:https://github.com/kelseyhight ... d-way

对于一个自发布Tarball的自定义安装,请参见:https://github.com/kubernetes- ... on.md

对于在本地VM上安装LinuxKit,请参见:https://github.com/linuxkit/li ... netes

下一阶段

Containerd承诺,在下一阶段将主要改进稳定性和可用性方面的问题:

稳定性:

在Kubernetes的测试基础设施上建立一套完整的Kubernetes集成测试,包括Ubuntu、COS(容器化的OS 地址:https://cloud.google.com/conta ... docs/)等等。

积极解决用户报告的任何测试失败和其他问题。

可用性:

提高Crictl(https://github.com/kubernetes- ... tl.md)的用户体验,Crictl是所有的CRI容器运行时的可移植命令行工具,这里的目标是使其易于用于调试和开发场景。

集成Kube-up.sh(https://kubernetes.io/docs/get ... /gce/)帮助用户使用Cri-Containerd来提高Kubernetes集群的生产质量。

改进文档。

预计在2017年底发布V1.0-Beta。

提供建议

Cri-Containerd是一个Kubernetes的孵化器项目,地址:ttps://github.com/kubernetes-incubator/cri-containerd。欢迎提供任何具有建设性的意见和建议,具体的使用入门指南请参见:https://github.com/kubernetes- ... opers

社区

Cri-Containerd是由Kubernetes Signode社区开发和维护的,如有相关的建议,可以加入社区:

Sig-Node社区网站:https://github.com/kubernetes/ ... -node

Slack:Kubernetes(kubernet.slack.com)的sig-节点通道:https://kubernetes.slack.com/

原文作者:Kubernetes 原文链接:http://blog.kubernetes.io/2017 ... erral

打走企业级落地微服务的拦路虎:数据

杨y 发表了文章 • 0 个评论 • 36 次浏览 • 2017-11-08 15:08 • 来自相关话题

数人云上几天给大家分享了:《踢开绊脚石:微服务难点之服务调用的解决方案》剖析了微服务的难点之一:服务调用的解决方案。今天再来跟大家聊聊微服务的另外一个难点:数据。

在尝试使用微服务架构的因由中,最主要的是允许团队能够以不同的速度在系统的不同部分进行工作,而且尽量将影响团队的相关因素最小化。因此,我们希望团队能够自治,做出关于实现和运营服务最好的决策,并且可以自由地进行更改。

为了获得这种自主权,需要“摆脱依赖”,很多人在某种程度上都引用了这句话,因为“每个微服务都应该拥有和控制自己的数据库,而不是两个服务去共享一个数据库。”这种理念是合情合理的,不要在服务之间共享一个数据库是因为会遇到读/写模式冲突、数据模型冲突、协调性问题等等。

当构建微服务时,如何安全地将数据库分切成多个小的数据库?首先对于企业级构建微服务,需要明确以下内容:

域是什么?它实现了什么
事物边界在哪里?
微服务如何跨越边界进行通信?
如果将数据库打开,会怎样?

什么是域

这似乎在很多地方都被忽视了,但在互联网公司如何实践微服务和传统企业如何(或者可能因为忽视了这一点而失败)实现微服务之间存在的巨大差异。

在构建微服务之前,以及它使用的数据(产品/消费等)的原因,需要对数据的表示有一个明确清晰的理解,例如,在我们可以将信息存储到一个数据库中,关于TicketMonster的预定和它向微服务的迁移,需要了解“什么是预定”,就如同在其他领域里需要了解什么是账户、什么是雇员、什么是索赔等等。

要做到这一点,需要深入了解现实中的“IT”是什么,例如,“什么是书?”,试着停下来想一想,因为这是一个很简单的例子,试着去想什么是一本书,那么,如何在数据模型中表达这一点呢?

关于“什么是一本书”没有一个客观的定义,因此,要回答这样的问题,必须知道“谁在问问题,什么是背景”,需要根据上下文去进行判断。作为人类,我们可以迅速(甚至是无意识地)解决着一理解的模糊性,因为在头脑、环境和问题中都有一个背景,但计算机没有,当构建应用并对数据建模时,需要明确地说出上下文,比如上面提到的企业拥有账户、用户、预定索赔等等,这让整个应用变得更为复杂,并且会产生很多的冲突和模糊,所以,需要界限。

在哪里划定界限?域驱动设计社区中的工作帮助处理整个域的复杂性,在实体、值对象和集合中绘制一个有界的上下文,换句话说,构建和细化一个代表域的模型,整个模型包含一个定义上下文的边界内,这些边界最终会成为微服务,或边界内的组件最终会成为微服务,抑或两者都是,无论哪种方式,微服务都是关于边界的,DDD(领域驱动设计)也是如此。







数据模型(希望如何在物理存储中表示的概念——注意,这里的显示差异)是由领域模型驱动的,当有这个边界时,可以知道并断言,在模型中什么是正确的,什么是不正确的,这些界限也意味着一定程度的自制,有界上下文的“A”可能对“Book”有不同的理解,而不是有界上下文的“B”(例如,可能有界上下文A是搜索服务,搜索标题为“Book”的标题,也许有界的上下文“B”是一种结账服务,它根据你购买的数据(标题+副本)来处理交易)。

关于DDD:

一些人试图复制Netflix,但他们只是复制了他们看到的那些,比如结果,而不是整个过程——Adrian Cockcroft,前Netflix首席云架构师。

对于不同的来说,微服务也是不尽相同的,没有一个硬性规定,只是根据自身实际情况去权衡,复制对一家公司有用的东西,仅仅因为它在这一刻似乎起到了作用,但跳过了过程以及其中的尝试,不会起到决定性的作用,需要注意的一点是,你的公司并不是Netflix,事实上,无论域在Netflix上有多么的复杂,它都要比你的传统企业简单的多。一些互联网公司之所以想实践落地微服务,是因为它们的速度非常快,而且规模庞大(在Twitter上发布一条推文很简单,但为5亿用户发布推文和显示Tweet流是非常复杂的),今天的企业将不得不面对领域和规模的复杂性,因此,接受这样一个事实:对于每个企业来说,都是不同的。

什么是事务边界

回到上文所设定的环境当中,需要一些如领域驱动设计这样的东西来帮助我们理解将要使用的模型来实现系统并在一个上下文中划定这些模型的边界,因此,接受客户、账户、预定等可能对不同的有界上下文意味着不同的东西,但最终,可能会在体系结构中分布这些相关的概念,但当发生变化时,需要一些方法协调这些不同的模型变化,需要对此进行解释,但在这之前,首先需要确定事务边界。

然而不幸,作为开发人员似乎仍然在构建分布式系统:仍然在查看一个单一的、关系型的、ACID的Database。也忽略了一个异步的、不可靠的网络危险,也就是说,做一些事情如编写一些奇特的框架,使我们不必对网络有任何了解(包括RPC框架、数据库抽象也可以忽略网络),并尝试用点对点同步调用(REST、SOAP、其他CORBA,比如对象序列化RPC库等等)来实现所有的东西。在不考虑权威和自治的情况下构建系统,最终试图通过许多独立服务来解决分布式数据问题,比如两阶段提交,或者把这些顾虑都忽略了?这种思维模式会导致构建非常脆弱的系统,而这些系统不具有规模,若把它称为SOA、微服务、迷你服务等等,那就无关紧要了。

交易边界的意思是需要最小的单位原子性,这是业务不变量的,无论使用数据库的ACID属性来实现原子性还是两段提交等都不重要,关键是想要使这些事物边界尽可能小(理想的是单一对象的单一事物:Vernon Vaughn有系列的文章描述了这种方法,用DDD聚集),这样就可以伸缩了,当使用DDD术语构建领域模型时,会识别实体、值对象和聚集,在这个上下文中,聚集的对象是封装其他实体/值对象的对象,并负责执行不变量(在一个有界的上下文中可以有多个聚合体)。

例如,假设有以下用例:

允许客户搜索航班
让客户在特定航班上选择座位
允许客户预定航班

可能会有三个有界的上下文:搜索、预定和票务(也许会有更多的支付、、待机、升级等等,但会将它缩小到这三个)。搜索负责显示特定路线的航班和特定时间的路线(天数、时间等等),预定将负责在预定过程中使用客户信息(姓名、地址、常旅客号等)、作为偏好和支付信息进行预定,票务将负责与航空公司的订位,并签发机票,在每个有界的上下文中,希望确定事务边界,在那里可以执行约束/不变量,不会考虑跨界上下文的原子事务,若想要小的事务边界(这是预定航班的一个非常简化的版本),改如何建模呢?可能是一个包含时间、日期、路线和像客户、飞机以及预定这样的实体航班集合?因为航班都有飞机、作为、客户和预定。为创造预定,飞行总机负责跟踪飞机、座椅等。这可能从数据库内部的数据模型角度(带有约束和外键的关系模型)或者在源代码中创建一个不错的对象模型(继承/组合),但来看看会发生什么:








在所有的预定、飞机、航班等方面是否真的存在不变量,只是为了创造一个预定?也就是说,如果在航班总数上增加了一架新飞机,是否应该在这一交易中包含客户和预定?可能不会,在这里所拥有的是一种聚合的聚合以及数据模型的便利,然而,事务的边界太大了,如果对航班、作为、预定等进行大量的更改,就会有巨大的事务冲突(无论是使用乐观的还是悲观的锁定都不重要),而且这显然没有规模(永远不要介意订单的不断下降,因为航班计划正在改变,这是一种糟糕的客户体验)。

如果打破了交易的界限,那就更小了。

也许预定、座椅可用性和航班是它们自己的独立集合,预定封装了客户信息、首选项和支付信息,Seat可利用聚合封装了飞机和飞机的配置,航班集合是由时间表、路线等组成的,但可以在不影响航班时刻表和飞机/座位可用性的情况下进行预定,从领域的角度看,希望能够做到这一点,不需要100%的严格一致性,但确实想要正确地记录飞行时间表的变化,如管理员,飞行的配置,以及客户的预定,那么,如何实现“在飞行上预定一个座位,”这样的事情呢?

在预定过程中,可能会呼叫座椅可用性集合,并要求它在飞机上预定一个作为,这个作为预定将被实现为一个单一的事务,例如(持有作为23A),并返回一个预定ID,可以将这个预定ID于预定联系起来,并且提交,知道这个座位是在一个“预定”的每一个(保留一个座位,并接受预定)都是单独的事务,并且可以独立地进行,而不需要任何两阶段提交或两阶段锁定。注意,这里使用“预定”是一个业务需求,不做座位分配,只保留座位,这个需求可能需要通过模型的迭代而被束缚,因为最初使用用例的语言可能只是简单地说“允许客户选择一个座位”,开发人员可以试着推新,这个需求意味着“从生育的座位中挑选,把它分配给客户,从库存中移除它,并且不出售比座位更多的票”。这将是额外的,不必要的不变量,这会给事务模型增加额外的负担,而业务模型实际上并不是不变的,在没有完全的座位分配情况下,这个业务当然可以接受预定,甚至是超额销售机票。








上图为一个示例,允许真正的域引导使用更小的、简化的、完全原子的事务边界来处理单个聚合,现在必须纠正这样一个事实:所有的个体交易都需要在某一时刻聚集在一起,数据的不同部分涉及到(例如,创建了一个预定和座位预定,但这些都不是通过固定的交易来获得登机牌/机票等)。

微服务如何跨边界通信

想要保持真正的业务 不变性,使用DDD可以选择将这些不变量建模为聚合,并使用单个事务进行聚合,在某些情况下,可以在单个事务中更新多聚合(跨单个数据或多个数据库),但这些场景可能是例外,仍然需要在聚合之间保持某种形式的一致性(最终在有界的上下文之间),那么应该怎么做呢?需要理解的一件事是:分布式系统是非常挑剔的,如果能在有限的时间内对分布式系统中的任何东西做出任何保证(事情将会失败,事情是不确定的,或者似乎失败了,系统有非同步的时间边界等等),那么为什么要尝试去解决它呢?如果接受并将其放入领域的一致性模型中会怎样呢?如果说“在必要的事务边界之间,可以与数据和域的其他部分进行协调,并在以后的某个时间点保持一致”?

正如一直说的,对于微服务,我们重视自主权,认为能够独立于其他系统(在可用性、协议、格式等方面)进行更改,时间的解耦和任何有限制的时间之间任何保证之间的任何保证,都允许真正实现这种自治(这不是计算机系统特有的,因此在事务边界和有界上线问之间,使用事件来保持一致性,事件是不可变的结构,它捕获了一个有趣的时间点,应该向对等点广播,同伴们会聆听它们感兴趣的事件,并根据这些数据做出的决定更新自己的数据等等。)

继续以订机票为例,当一个预定通过一个Acid风格的交易存储时,如何结束它?这是前面提到的“退票界”的背景,预定有界上下文将发布类似“New Booking创建”这样的事件,而票务绑定上下文将会消耗该事件,并继续与后端(可能是遗留的)票务系统进行交互,这显然需要某种集成和数据转换,这是Apache Camel非常擅长的。也引出了一些其他的问题,如何对数据库进行写操作,并以原子的方式将其发布到队列/消息传递设备中?

如果在事件之间有排序需求/因果需求呢?每个服务的一个数据库呢?

理想情况下,聚合会直接使用命令和域事件(作为第一个类公民,也就是说,)任何操作都是作为命令来实现的,任何响应都是作为对事件的响应来实现的)可以更清晰地映射使用内部上下文和上下文之间使用的事件之间关系,可以将事件(即Newbooking创建)发布到消息队列中,然后让侦听器从消息队列中使用该队列,并将其插入到数据库中,而无需使用Xa/2pc事务,而不需要将其插入到数据库中,可以将事件插入到一个专用的事件存储中,它就像数据库和消息发布-订阅主题一样(这可能是首选路由),或者可以继续使用一个ACID数据库,并将该数据库的变化流到一个持久的、复制的日志中,就像Apache卡夫卡一样,使用类似于Debezium的东西,并使用某种事件处理器来推断事件,无论哪种方式,关键是想要在时间事件中与不可变点之间的边界进行通信。








这带来了一些巨大的优势:

避免了跨边界且昂贵潜在的不可能的事务模型

可以对系统进行更改,而不妨碍系统的其他部分(时间和可用性)的进展

可以将数据存储在自己的数据库中,同时使用适合于服务的技术

可以在空闲时更改模式/数据库

变得更加可伸缩、容错、灵活

必须更加关注CAP定力和选择的技术来实现存储/队列

需要注意的是,这也有一些缺点:
更加复杂
难以调试
由于看到事件时有延迟,所以不能对其他系统所知道的内容作出任何假设
必须更加关注CAP定理和选择的技术来实现队列/存储

从这种方法中产生另一个有趣的概念是,能够实现一种称为“命令查询分离责任”的模式,在这种模式中,将读模型和编写模型分离到单独的服务中,请记住,我们对互联网公司没有非常复杂的领域模型感到遗憾,这在他们的编写模型中很明显(例如,在一个分布式日志中插入一条Tweet)。然而,他们的阅读模式因其规模而变得非常复杂,CQRS帮助分离了这些问题,另一方面,在企业中,编写模型可能非常复杂,而读取模型可能是简单的平面选择查询和扁平DTO对象,CQRS是一种强大的关注点隔离模式,一旦有了适当的边界和在聚集和有界上下文之间进行数据更改的好方法,就可以对其进行评估。

那么服务只有一个数据库,并且不与其他服务共享呢?在这个场景中,可能会侦听事件流的侦听器,并可能将数据插入到一个共享数据库中,而主聚合可能最终会使用这些数据,这个“共享数据库”非常好,记住,没有规则,只有权衡,在这种情况下,可能会有很多服务协同同一个数据库一起工作,只要团队拥有所有的过程,就不会否定自治的优势,当听到有人说“微服务应该有自己的数据库,而不是别人分享”时,你可以回答:好吧,有点。

打开数据库

如果将使用事件/流来进行所有的事情,并且永远的持久化这些事件呢?如果说数据库/缓存/索引实际上只是过去发生的事件的持久日志/流的物化视图,而当前状态是所有这些事件的左折叠?

这种方法带来了更多的好处,可以通过事件(上面列出的)来增加交流的好处:

现在可以将数据库看做是记录的:“当前状态”,而不是真正的纪录
可以引入新的应用,重新阅读过去的事件,并根据“将要发生的事情”来检查它们的行为
免费完善审计日志记录
可以引入应用的新版本,并通过重新播放事件对其执行非常详尽的测试
可以更容易地关于数据库版本/升级/模式变化的事件重演到新数据库中
可以迁移到全新的数据库技术(例如,可能发现已经超越了关系数据库,并且希望切换到专门的数据库/索引)







TM体系结构

当在aa.com、Delta.com或united.com上预定航班时,会看到其中的一些概念,当选择一个座位时,并没有实际地分配它。当订机票时,实际上并没有收到实体票,之后会收到一封电子邮件,通知已经被确认,你是否有过一次飞机换班的经历,并分配到一个不同的座位?或者是去登机口,听到工作人员要求放弃座位,因为机票已经超出预定座位,这些都是事务边界的例子,最终的一致性、补偿事务,甚至连工作中的道歉都属于。

Moral Of The Story

这里指的是:数据、数据集成、数据边界、企业使用模式、分布式系统理论、时间等等,都是微服务的难点(因为微服务是真正的分布式系统)在技术上看到了太多的困惑(“如果使用Spring引导,我正在做微服务”,“需要解决服务发现,在云计算之前负载均衡”,必须有一个每个微服务的数据库)和关于使用微服务的无用理论,别担心,因为一旦大的供应商来卖给你所有的高级产仍然需要做上面列出的那些困难部分。

原文作者:Software 原文链接:http://www.tuicool.com/articles/VnIvyyF 查看全部
数人云上几天给大家分享了:《踢开绊脚石:微服务难点之服务调用的解决方案》剖析了微服务的难点之一:服务调用的解决方案。今天再来跟大家聊聊微服务的另外一个难点:数据。

在尝试使用微服务架构的因由中,最主要的是允许团队能够以不同的速度在系统的不同部分进行工作,而且尽量将影响团队的相关因素最小化。因此,我们希望团队能够自治,做出关于实现和运营服务最好的决策,并且可以自由地进行更改。

为了获得这种自主权,需要“摆脱依赖”,很多人在某种程度上都引用了这句话,因为“每个微服务都应该拥有和控制自己的数据库,而不是两个服务去共享一个数据库。”这种理念是合情合理的,不要在服务之间共享一个数据库是因为会遇到读/写模式冲突、数据模型冲突、协调性问题等等。

当构建微服务时,如何安全地将数据库分切成多个小的数据库?首先对于企业级构建微服务,需要明确以下内容:

域是什么?它实现了什么
事物边界在哪里?
微服务如何跨越边界进行通信?
如果将数据库打开,会怎样?

什么是域

这似乎在很多地方都被忽视了,但在互联网公司如何实践微服务和传统企业如何(或者可能因为忽视了这一点而失败)实现微服务之间存在的巨大差异。

在构建微服务之前,以及它使用的数据(产品/消费等)的原因,需要对数据的表示有一个明确清晰的理解,例如,在我们可以将信息存储到一个数据库中,关于TicketMonster的预定和它向微服务的迁移,需要了解“什么是预定”,就如同在其他领域里需要了解什么是账户、什么是雇员、什么是索赔等等。

要做到这一点,需要深入了解现实中的“IT”是什么,例如,“什么是书?”,试着停下来想一想,因为这是一个很简单的例子,试着去想什么是一本书,那么,如何在数据模型中表达这一点呢?

关于“什么是一本书”没有一个客观的定义,因此,要回答这样的问题,必须知道“谁在问问题,什么是背景”,需要根据上下文去进行判断。作为人类,我们可以迅速(甚至是无意识地)解决着一理解的模糊性,因为在头脑、环境和问题中都有一个背景,但计算机没有,当构建应用并对数据建模时,需要明确地说出上下文,比如上面提到的企业拥有账户、用户、预定索赔等等,这让整个应用变得更为复杂,并且会产生很多的冲突和模糊,所以,需要界限。

在哪里划定界限?域驱动设计社区中的工作帮助处理整个域的复杂性,在实体、值对象和集合中绘制一个有界的上下文,换句话说,构建和细化一个代表域的模型,整个模型包含一个定义上下文的边界内,这些边界最终会成为微服务,或边界内的组件最终会成为微服务,抑或两者都是,无论哪种方式,微服务都是关于边界的,DDD(领域驱动设计)也是如此。

1.png



数据模型(希望如何在物理存储中表示的概念——注意,这里的显示差异)是由领域模型驱动的,当有这个边界时,可以知道并断言,在模型中什么是正确的,什么是不正确的,这些界限也意味着一定程度的自制,有界上下文的“A”可能对“Book”有不同的理解,而不是有界上下文的“B”(例如,可能有界上下文A是搜索服务,搜索标题为“Book”的标题,也许有界的上下文“B”是一种结账服务,它根据你购买的数据(标题+副本)来处理交易)。

关于DDD:

一些人试图复制Netflix,但他们只是复制了他们看到的那些,比如结果,而不是整个过程——Adrian Cockcroft,前Netflix首席云架构师。

对于不同的来说,微服务也是不尽相同的,没有一个硬性规定,只是根据自身实际情况去权衡,复制对一家公司有用的东西,仅仅因为它在这一刻似乎起到了作用,但跳过了过程以及其中的尝试,不会起到决定性的作用,需要注意的一点是,你的公司并不是Netflix,事实上,无论域在Netflix上有多么的复杂,它都要比你的传统企业简单的多。一些互联网公司之所以想实践落地微服务,是因为它们的速度非常快,而且规模庞大(在Twitter上发布一条推文很简单,但为5亿用户发布推文和显示Tweet流是非常复杂的),今天的企业将不得不面对领域和规模的复杂性,因此,接受这样一个事实:对于每个企业来说,都是不同的。

什么是事务边界

回到上文所设定的环境当中,需要一些如领域驱动设计这样的东西来帮助我们理解将要使用的模型来实现系统并在一个上下文中划定这些模型的边界,因此,接受客户、账户、预定等可能对不同的有界上下文意味着不同的东西,但最终,可能会在体系结构中分布这些相关的概念,但当发生变化时,需要一些方法协调这些不同的模型变化,需要对此进行解释,但在这之前,首先需要确定事务边界。

然而不幸,作为开发人员似乎仍然在构建分布式系统:仍然在查看一个单一的、关系型的、ACID的Database。也忽略了一个异步的、不可靠的网络危险,也就是说,做一些事情如编写一些奇特的框架,使我们不必对网络有任何了解(包括RPC框架、数据库抽象也可以忽略网络),并尝试用点对点同步调用(REST、SOAP、其他CORBA,比如对象序列化RPC库等等)来实现所有的东西。在不考虑权威和自治的情况下构建系统,最终试图通过许多独立服务来解决分布式数据问题,比如两阶段提交,或者把这些顾虑都忽略了?这种思维模式会导致构建非常脆弱的系统,而这些系统不具有规模,若把它称为SOA、微服务、迷你服务等等,那就无关紧要了。

交易边界的意思是需要最小的单位原子性,这是业务不变量的,无论使用数据库的ACID属性来实现原子性还是两段提交等都不重要,关键是想要使这些事物边界尽可能小(理想的是单一对象的单一事物:Vernon Vaughn有系列的文章描述了这种方法,用DDD聚集),这样就可以伸缩了,当使用DDD术语构建领域模型时,会识别实体、值对象和聚集,在这个上下文中,聚集的对象是封装其他实体/值对象的对象,并负责执行不变量(在一个有界的上下文中可以有多个聚合体)。

例如,假设有以下用例:

允许客户搜索航班
让客户在特定航班上选择座位
允许客户预定航班

可能会有三个有界的上下文:搜索、预定和票务(也许会有更多的支付、、待机、升级等等,但会将它缩小到这三个)。搜索负责显示特定路线的航班和特定时间的路线(天数、时间等等),预定将负责在预定过程中使用客户信息(姓名、地址、常旅客号等)、作为偏好和支付信息进行预定,票务将负责与航空公司的订位,并签发机票,在每个有界的上下文中,希望确定事务边界,在那里可以执行约束/不变量,不会考虑跨界上下文的原子事务,若想要小的事务边界(这是预定航班的一个非常简化的版本),改如何建模呢?可能是一个包含时间、日期、路线和像客户、飞机以及预定这样的实体航班集合?因为航班都有飞机、作为、客户和预定。为创造预定,飞行总机负责跟踪飞机、座椅等。这可能从数据库内部的数据模型角度(带有约束和外键的关系模型)或者在源代码中创建一个不错的对象模型(继承/组合),但来看看会发生什么:


2.png



在所有的预定、飞机、航班等方面是否真的存在不变量,只是为了创造一个预定?也就是说,如果在航班总数上增加了一架新飞机,是否应该在这一交易中包含客户和预定?可能不会,在这里所拥有的是一种聚合的聚合以及数据模型的便利,然而,事务的边界太大了,如果对航班、作为、预定等进行大量的更改,就会有巨大的事务冲突(无论是使用乐观的还是悲观的锁定都不重要),而且这显然没有规模(永远不要介意订单的不断下降,因为航班计划正在改变,这是一种糟糕的客户体验)。

如果打破了交易的界限,那就更小了。

也许预定、座椅可用性和航班是它们自己的独立集合,预定封装了客户信息、首选项和支付信息,Seat可利用聚合封装了飞机和飞机的配置,航班集合是由时间表、路线等组成的,但可以在不影响航班时刻表和飞机/座位可用性的情况下进行预定,从领域的角度看,希望能够做到这一点,不需要100%的严格一致性,但确实想要正确地记录飞行时间表的变化,如管理员,飞行的配置,以及客户的预定,那么,如何实现“在飞行上预定一个座位,”这样的事情呢?

在预定过程中,可能会呼叫座椅可用性集合,并要求它在飞机上预定一个作为,这个作为预定将被实现为一个单一的事务,例如(持有作为23A),并返回一个预定ID,可以将这个预定ID于预定联系起来,并且提交,知道这个座位是在一个“预定”的每一个(保留一个座位,并接受预定)都是单独的事务,并且可以独立地进行,而不需要任何两阶段提交或两阶段锁定。注意,这里使用“预定”是一个业务需求,不做座位分配,只保留座位,这个需求可能需要通过模型的迭代而被束缚,因为最初使用用例的语言可能只是简单地说“允许客户选择一个座位”,开发人员可以试着推新,这个需求意味着“从生育的座位中挑选,把它分配给客户,从库存中移除它,并且不出售比座位更多的票”。这将是额外的,不必要的不变量,这会给事务模型增加额外的负担,而业务模型实际上并不是不变的,在没有完全的座位分配情况下,这个业务当然可以接受预定,甚至是超额销售机票。


3.png



上图为一个示例,允许真正的域引导使用更小的、简化的、完全原子的事务边界来处理单个聚合,现在必须纠正这样一个事实:所有的个体交易都需要在某一时刻聚集在一起,数据的不同部分涉及到(例如,创建了一个预定和座位预定,但这些都不是通过固定的交易来获得登机牌/机票等)。

微服务如何跨边界通信

想要保持真正的业务 不变性,使用DDD可以选择将这些不变量建模为聚合,并使用单个事务进行聚合,在某些情况下,可以在单个事务中更新多聚合(跨单个数据或多个数据库),但这些场景可能是例外,仍然需要在聚合之间保持某种形式的一致性(最终在有界的上下文之间),那么应该怎么做呢?需要理解的一件事是:分布式系统是非常挑剔的,如果能在有限的时间内对分布式系统中的任何东西做出任何保证(事情将会失败,事情是不确定的,或者似乎失败了,系统有非同步的时间边界等等),那么为什么要尝试去解决它呢?如果接受并将其放入领域的一致性模型中会怎样呢?如果说“在必要的事务边界之间,可以与数据和域的其他部分进行协调,并在以后的某个时间点保持一致”?

正如一直说的,对于微服务,我们重视自主权,认为能够独立于其他系统(在可用性、协议、格式等方面)进行更改,时间的解耦和任何有限制的时间之间任何保证之间的任何保证,都允许真正实现这种自治(这不是计算机系统特有的,因此在事务边界和有界上线问之间,使用事件来保持一致性,事件是不可变的结构,它捕获了一个有趣的时间点,应该向对等点广播,同伴们会聆听它们感兴趣的事件,并根据这些数据做出的决定更新自己的数据等等。)

继续以订机票为例,当一个预定通过一个Acid风格的交易存储时,如何结束它?这是前面提到的“退票界”的背景,预定有界上下文将发布类似“New Booking创建”这样的事件,而票务绑定上下文将会消耗该事件,并继续与后端(可能是遗留的)票务系统进行交互,这显然需要某种集成和数据转换,这是Apache Camel非常擅长的。也引出了一些其他的问题,如何对数据库进行写操作,并以原子的方式将其发布到队列/消息传递设备中?

如果在事件之间有排序需求/因果需求呢?每个服务的一个数据库呢?

理想情况下,聚合会直接使用命令和域事件(作为第一个类公民,也就是说,)任何操作都是作为命令来实现的,任何响应都是作为对事件的响应来实现的)可以更清晰地映射使用内部上下文和上下文之间使用的事件之间关系,可以将事件(即Newbooking创建)发布到消息队列中,然后让侦听器从消息队列中使用该队列,并将其插入到数据库中,而无需使用Xa/2pc事务,而不需要将其插入到数据库中,可以将事件插入到一个专用的事件存储中,它就像数据库和消息发布-订阅主题一样(这可能是首选路由),或者可以继续使用一个ACID数据库,并将该数据库的变化流到一个持久的、复制的日志中,就像Apache卡夫卡一样,使用类似于Debezium的东西,并使用某种事件处理器来推断事件,无论哪种方式,关键是想要在时间事件中与不可变点之间的边界进行通信。


4.png



这带来了一些巨大的优势:

避免了跨边界且昂贵潜在的不可能的事务模型

可以对系统进行更改,而不妨碍系统的其他部分(时间和可用性)的进展

可以将数据存储在自己的数据库中,同时使用适合于服务的技术

可以在空闲时更改模式/数据库

变得更加可伸缩、容错、灵活

必须更加关注CAP定力和选择的技术来实现存储/队列

需要注意的是,这也有一些缺点:
更加复杂
难以调试
由于看到事件时有延迟,所以不能对其他系统所知道的内容作出任何假设
必须更加关注CAP定理和选择的技术来实现队列/存储

从这种方法中产生另一个有趣的概念是,能够实现一种称为“命令查询分离责任”的模式,在这种模式中,将读模型和编写模型分离到单独的服务中,请记住,我们对互联网公司没有非常复杂的领域模型感到遗憾,这在他们的编写模型中很明显(例如,在一个分布式日志中插入一条Tweet)。然而,他们的阅读模式因其规模而变得非常复杂,CQRS帮助分离了这些问题,另一方面,在企业中,编写模型可能非常复杂,而读取模型可能是简单的平面选择查询和扁平DTO对象,CQRS是一种强大的关注点隔离模式,一旦有了适当的边界和在聚集和有界上下文之间进行数据更改的好方法,就可以对其进行评估。

那么服务只有一个数据库,并且不与其他服务共享呢?在这个场景中,可能会侦听事件流的侦听器,并可能将数据插入到一个共享数据库中,而主聚合可能最终会使用这些数据,这个“共享数据库”非常好,记住,没有规则,只有权衡,在这种情况下,可能会有很多服务协同同一个数据库一起工作,只要团队拥有所有的过程,就不会否定自治的优势,当听到有人说“微服务应该有自己的数据库,而不是别人分享”时,你可以回答:好吧,有点。

打开数据库

如果将使用事件/流来进行所有的事情,并且永远的持久化这些事件呢?如果说数据库/缓存/索引实际上只是过去发生的事件的持久日志/流的物化视图,而当前状态是所有这些事件的左折叠?

这种方法带来了更多的好处,可以通过事件(上面列出的)来增加交流的好处:

现在可以将数据库看做是记录的:“当前状态”,而不是真正的纪录
可以引入新的应用,重新阅读过去的事件,并根据“将要发生的事情”来检查它们的行为
免费完善审计日志记录
可以引入应用的新版本,并通过重新播放事件对其执行非常详尽的测试
可以更容易地关于数据库版本/升级/模式变化的事件重演到新数据库中
可以迁移到全新的数据库技术(例如,可能发现已经超越了关系数据库,并且希望切换到专门的数据库/索引)


5.png


TM体系结构

当在aa.com、Delta.com或united.com上预定航班时,会看到其中的一些概念,当选择一个座位时,并没有实际地分配它。当订机票时,实际上并没有收到实体票,之后会收到一封电子邮件,通知已经被确认,你是否有过一次飞机换班的经历,并分配到一个不同的座位?或者是去登机口,听到工作人员要求放弃座位,因为机票已经超出预定座位,这些都是事务边界的例子,最终的一致性、补偿事务,甚至连工作中的道歉都属于。

Moral Of The Story

这里指的是:数据、数据集成、数据边界、企业使用模式、分布式系统理论、时间等等,都是微服务的难点(因为微服务是真正的分布式系统)在技术上看到了太多的困惑(“如果使用Spring引导,我正在做微服务”,“需要解决服务发现,在云计算之前负载均衡”,必须有一个每个微服务的数据库)和关于使用微服务的无用理论,别担心,因为一旦大的供应商来卖给你所有的高级产仍然需要做上面列出的那些困难部分。

原文作者:Software 原文链接:http://www.tuicool.com/articles/VnIvyyF