作者围绕其这些年在OpenStack、Kubernetes、Microservice、DevOps、Cloud Foundry、ELK等云计算相关领域及技术的实践,从微服务和DevOps两方面着手,旨在为两者的落地提供一个快速可行路径。针对这“说说还可以,一深入讨论就吵架”的热点概念,详解了在产品研发过程中的思考与实践,通过多维度的架构与技术剖析,与大家深入沟通云计算的企业级落地思路。本文是从作者这些年的经历与实践出发的总结,也欢迎感兴趣的同学参与交流、保持沟通与学习。(备注:作者微信二维码详见文末)。 (一)服务与DevOps的认识现在见客户就会聊微服务、聊DevOps、聊容器,但这种热点概念,真的是“简单聊聊可以,一深入就吵架”,比如以前谁问我传统应用该怎么拆分,我还会说一堆,现在基本上对于这种开放型问题都不敢回答了,怕“没朋友”。 我简单说说我对微服务和DevOps的认知吧: 第一个就不说了,第二个垂直架构,典型的比如SSH框架,帮大家考虑了模块化、MVC等,但并没有考虑服务化。 第三个是分布式架构,以SOA为代表的这类技术已经热了很多年,也很成熟,也是目前很多企业架构的主体支撑。 而第四个以微服务架构为支撑的技术虽然在一些先进企业或互联网公司已经运用,但从生态上来看,还有很长一段时间要走,其更强调在DDD下的业务服务自治性及原子性。 “DevOps”通常指的是新兴的专业化运动,这种运动提倡开发和IT运维之间的高度协同,从而在完成高频率部署的同时,提高生产环境的可靠性、稳定性、弹性和安全性。 其概念也特别多,简单浏览下就可以了:DevOps运动的起源通常被放在2009年前后,伴随着许多运动的相辅相成和相互促进——效率研讨会运动,特别是由JohnAllspaw和Paul Hammond展示的开创性的“一天10次部署”,基础设施即代码”运动(Mark Burgess和LukeKanies),“敏捷基础设施运动”(Andrew Shafer),“敏捷系系统管理(PatrickDeBois),“精益创业”运动(EricRies),JezHumble的持续集成和发布运动,以及Amazon的“平台即服务运动”等这些运动的相辅相成和相互促进而发展起来的。 那云计算、微服务、容器这些概念或能力之间到底是什么关系呢?其实这个主要看大家的方向了,结合我所面临的客户以及IT现状,我的理解是这样的:
(二)平台级的实践与支撑先和大家说说我们的平台具体在做什么: 这个定位(非市场定位)讲起来比较拗口,“用微服务架构,做云计算DevOps平台,支撑上层微服务的全生命周期管理”。 这里有个鸡生蛋、蛋生鸡的问题,那我们还是通过制定微服务的规范以及一部分配套工具,基于这些开发了第一版DevOps云平台,将其作为后续版本的生产线使用。过程中对康威定律又有了进一步认识,尤其是运用在异地协作和技术选型上,团队能力、异地松耦合是必须考虑的维度。 先将平台用到的一些技术栈列出来: 图中标红的是目前我们已使用的,相信大家不难看出来:
这里有三个想法与大家共勉:
接着分别从微服务和DevOps方面来看看我们的一些关键设计和想法,先说说微服务架构: 当然微服务架构中重要的不仅仅是上述的5个能力:
上图亦可理解为是核心概念模型,面向的问题是这样的:
那概念模型上我们怎么办?上图的核心是业务运行及namespace的设计,下层无论资源有没有池化,都需要加一层Namespace的管理,这个管理有很多目标,比如隔离,再比如池化。 然后紧接着是pod,这个概念参考了Kubernetes,在微服务运行时,一直强调一个业务的独立性,比如一个业务,其应用及数据库是绑定的,且与其他业务隔离。那我们认为这种就是一个pod(豌豆荚),体现的是一个独立业务(微服务)。 一个pod无论内部如何,一般是跑在一台宿主机的,业务内部尽量本地调用,pod可以包括多个进程,也可以包含多个容器,也就是上图的pod与process的关系。 从可靠性及性能考虑,pod必须是集群的,所以一个pod可以有多个副本,也就是上图的pod与replication的关系。 最终业务要能对外提供能力,类似一个集群对外的统一发布地址,也就是上图的service的概念,service是外部的访问入口,并拥有一定的负载均衡能力。 下图是运行时的调用过程示意: 互通要求的是“可达、快速可达、安全并快速可达”。一个微服务内部可采用本地方式,而微服务之间采用service地址(无论内部怎么漂移伸缩,对外地址不变),对于公网上的调用,采用宿主机端口映射出去是个可选方式,当然要结合底层硬件基础设施本身的外网能力,比如阿里还有EIP之类 微服务的伸缩与漂移,需要与监控能力结合,监控结果判断则运用的是万年不变公式: Result = function1*weight1 + function2*weight2 + …… + functionN*weightN 以漂移为例子,漂移有很多触发器,有因为故障的,有基于优化考虑的,比如像优化漂移这种,就要求定义很多维度,包括资源均衡维度、宿主机特性维度、标签配置变更维度等,需结合多维打分对微服务进行合理调度。 那对于伸缩漂移所依赖的能力上,着重考虑下述两点:
微服务的升级与回退:
而对于我们来说,使用了rollingupdate机制来进行升级和回退(包括灰度),大家可参考Kubernetes的机制,一种基于标签和Replication的实现方法。对于升级回退、灰度中,最复杂的莫过于数据库以及前端负载的处理问题:
微服务的熔断与降级,当然熔断与降级并不是一个概念,只是很多时候会一起实现了:
举例:熔断器实现方式,设计参考了一般都使用的三态设计,默认关闭态,调用出错率到一定程度半开,半开时,允许一部分流量继续调用下游微服务,如果一定时间还是出错(这个时间可结合MTTR设置),就将熔断器置为全开态,同样设置一定的时间后再尝试调用; 现在在熔断和降级这块实现的比较好的包括netflix的Hystrix,还有motan,大家都可尝试,我们Hystrix测试过,目前使用了motan,仅从能力上对比,Hystrix无疑更强大。前段时间乐视受攻击,差不多每秒200G流量,最终能撑下来据说主要功劳和这个有关系。 微服务的注册与发现,解决微服务之间的调用、以及一定的客户端和服务端集群的问题。采用etcd作为分布式注册中心,在服务启动和停止时实现注册和注销,运行过程中,会定时同步服务的元信息(比如流量、健康性等),以便实现智能路由。 接着,我们来看看在DevOps实践中的一些关键点: 四要素的提法和友商大同小异,包括组织、流程、技术、文化,下图会将四要素进行更细粒度的要素分解。 组织:包括全栈团队、自治团队等 流程:包括开发、测试、集成、交付、度量等 技术:包括监控、ChatOps等 文化:包括协作、学习等 实现企业级DevOps,有很多方式和着手点,比如最常用的就是从持续发布开始。而我们更聚焦企业的全生命周期,所以在目前版本中(与上图有少许不对应),实现了基于微服务架构的以下15个DevOps领域系统:
这里对一些DevOps的关键系统协作方式做了一定描述,就不赘述了。 最终这个平台同时支撑了公有云与私有云两条线(8月发布第二版),其中公有云目前运行于阿里云上,使用了阿里云的ECS、VPC、EIP等很少的服务种类;而私有云,目前也在一些企业开始试点。 当然,过程中,尤其是公有云上遇到了不少问题,举两个例子:
(三)参考与总结最后分享下我觉得比较好的一些可参考材料,并对分享做下总结: 这个不确定最初是不是Gartner提出的,旨在给DevOps从运营效率、服务、组织、客户价值、业绩维度评估,让企业发现其需要改进的一些点。 平台品质属性,很多时候翻译成质量属性,一种属性分类的方法是把在运行时可识别的特性与那些不可识别的特性区分开),另一种方法是把对用户很重要的可见特性与对开发者和维护者很重要的不可见特性区分开,和CAP类似,这些特性有些可叠加,有些则会相互制约,在产品设计时需清楚哪些是您最迫切的。 Heroku的12Factor,这些因素为系统的CloudNative目标考虑,让云上云下得到同样的体验,这12因素不能简单的字面理解,要结合您现在的实际运行来看,则会发现其独到的地方,也不要想一蹴而就,只要时刻有这么根弦,在很多选择前面看看这12因素是否有类似的可参考,比如当时我们纠结了很久的,VCS是否使用TBD模式,其实这里面都可以找到相关答案。 谷歌的Borg,作为谷歌内部的管理调度核心,支撑着谷歌上万台机器及业务的运行,这个虽然是不开源的,但其设计思路和架构是很容易被找到学习的。参考这个的原因是谷歌本身内部就是容器与微服务架构的生产运用,是一个真正大规模的实践参考。 问:DevOps对多服务之间的依赖关系有什么好的解决办法吗? 问:对于遗留的业务系统如何落地? 问:DevOps的基础是环境,如何支持传统IT下和新上私有云公有云中的DevOps? 问:对各种私有云和公有云的支持是怎么做到的?比如要把应用跑到阿里云、青云、AWS、Azure、内网OpenStack。 问:涉及多个云后,用容器就会产生多个资源池,这些资源池本身以及容器云是如何管理的? 扫描二维码加入由作者主持的“普元云计算研发开放群”,讨论更多云计算、微服务、DevOps、容器相关内容,加群暗号“DevOps”。 InfoQ陪伴技术人, 用优质的技术文章作长情的告白。 技术提升世界的活交给你们了, 高效开发运维在这里给你们提供后勤补给。 |
|