关于devops:没有它你的DevOps是玩不转的你信不

34次阅读

共计 3919 个字符,预计需要花费 10 分钟才能阅读完成。

摘要:架构的抉择对于 DevOps 的实际是至关重要的,从某种程度上来说,架构就是 DevOps 这场战斗的粮草,它是撑持着 DevOps 胜利落地的重要前提。

善用兵者,役不再籍,粮不三载。取用于国,因粮于敌,故军食可足也。

——《孙子兵法》

在现代,带兵作战的将领,不仅要能长于用兵,而且要能保障食粮的短缺。正所谓兵马未动,粮草先行。粮草永远摆在第一位,因为在冷 ** 时代,和平中的将士都是在拼力量,吃饱才有力量打仗。

在明天互联网的“和平”环境中,咱们为了能更快的应答市场变动,始终以来一直调整着作战的方针和打法,也从传统的开发方式转变为了麻利开发,由麻利开发又过渡了到 DevOps。在 2019 年的中国 DevOps 行业报告中指出:“只管受访企业冀望 DevOps 可能带来更高效的交付效率,晋升客户满意度,发明更多的商业价值,但成功实践 DevOps 仍然是一个难题。”

其中 28.22% 被调查者认为本人组织的 DevOps 实际是不胜利的,41.13% 的被调查者不分明如何掂量本人组织的 DevOps 实际是否胜利。如果以一个更加直观的数据来展现,就是在承受考察的企业中有 69.35% 是没有能很好的理解和实际 DevOps 的。

兴许,在实际 DevOps 的这几年来,并没有多少公司是真正晓得什么是 DevOps 的。DevOps 只是从字面上了解的突破部门墙的一键公布的工具链吗,是否有了这个工具链就是 DevOps?答案是否定的。

那么,DevOps 是什么?

DevOps 是集文化理念、实际和工具于一身,能够进步组织高速交付应用程序和服务的能力,与应用传统软件开发和基础设施治理流程相比,可能帮忙组织更快地倒退和改良产品。这种速度使组织可能更好地服务其客户,并在市场上更高效地参加竞争——AWS

从 AWS 给出的定义来看,如同也还是比拟的形象。那如果简略的来说,DevOps 就是让软件过程既“快”又“稳”。

何为快和稳,这个快和稳体现在,部署频率、交付周期、均匀修复时长、变更失败比例这 4 个维度上。

在 2018 年的 DevOps 调查报告中基于上述 4 个维度,因为仅有 6% 达到了所规定的高性能指标,为了防止非凡起因造成数据过低,所以放宽的条件,并给出了准高性能 DevOps 指标。

从达成这一准高性能 DevOps 指标的团队剖析来看,其具体体现在三个方面:一方面是自动化、标准化、质量保证、麻利办法的实际流动上;一方面是 DevOps 各个阶段的对应工具上。除此以外就是,团队正在开发利用的架构上。

架构的抉择对于 DevOps 的实际是至关重要的,从某种程度上来说,架构就是 DevOps 这场战斗的粮草,它是撑持着 DevOps 胜利落地的重要前提。受访的准高性能 DevOps 指标的团队将“应用微服务框架”作为团队正在开发利用的架构上的 Top1。

什么是微服务

是一种软件架构格调,它是以专一于繁多责任与性能的小型性能区块 (Small Building Blocks) 为根底,利用模块化的形式组合出简单的大型应用程序,各性能区块应用与语言无关 (Language-Independent/Language agnostic) 的 API 集互相通信。

微服务的起源是由 Peter Rodgers 博士于 2005 年度云计算博览会提出的微 Web 服务 (Micro-Web-Service) 开始,Juval Löwy 则是与他有相似的前导想法,将类别变成细粒服务 (granular services),以作为 Microsoft 下一阶段的软件架构,其外围想法是让服务是由相似 Unix 管道的拜访形式应用,而且简单的服务背地是应用简略 URI 来凋谢接口,任何服务,任何细粒都能被凋谢 (exposed)。这个设计在 HP 的实验室被实现,具备扭转简单软件系统的弱小力量。

2014 年,Martin Fowler 与 James Lewis 独特提出了微服务的概念,定义了微服务是由以繁多应用程序形成的小服务,本人领有本人的行程与轻量化解决,服务依业务功能设计,以全自动的形式部署,与其余服务应用 HTTP API 通信。同时服务会应用最小的规模的集中管理 (例如 Docker) 能力,服务能够用不同的编程语言与数据库等组件实现。

微服务的特点

依据 Martin Fowler 的剖析,微服务架构有以下的一些通用个性,但并非所有微服务架构利用都必须具备所有这些个性:

通过服务实现利用的组件化(Componentizationvia Services):微服务架构中将组件定义为可被独立替换和降级的软件单元,在利用架构设计中通过将整体利用切分成可独立部署及降级的微服务形式进行组件化设计。

围绕业务能力组织服务(Organizedaround Business Capabilities):微服务架构采取以业务能力为出发点组织服务的策略,因而微服务团队的组织构造必须是跨性能的(如:既管利用,也管数据库)、强搭配的 DevOps 开发运维一体化团队,通常这些团队不会太大(如:亚马逊的“Two pizza team”- 不超过 12 人)。

产品而非我的项目模式(Productsnot Projects):传统的利用模式是一个团队以我的项目模式开发残缺的利用,开发实现后就交付给运维团队负责保护;微服务架构则提倡一个团队应该如开发产品般负责一个“微服务”残缺的生命周期,提倡“谁开发,谁经营”的开发运维一体化办法。

智能端点与管道扁平化(Smartendpoints and dumb pipes):微服务架构主张将组件间通信的相干业务逻辑 / 智能放在组件端点侧而非放在通信组件中,通信机制或组件应该尽量简略及松耦合。RESTful HTTP 协定和仅提供音讯路由性能的轻量级异步机制是微服务架构中最罕用的通信机制。

“去中心化”治理(DecentralizedGovernance):整体式利用往往偏向于采纳繁多技术平台,微服务架构则激励应用适合的工具实现各自的工作,每个微服务能够思考选用最佳工具实现(如不同的编程语言)。微服务的技术标准偏向于寻找其余开发者已胜利验证解决相似问题的技术。

“去中心化”数据管理 (DecentralizedData Management):微服务架构提倡采纳多样性长久化(PolyglotPersistence) 的办法,让每个微服务治理其自有数据库,并容许不同微服务采纳不同的数据长久化技术。

基础设施自动化(InfrastructureAutomation):云化及自动化部署等技术极大地升高了微服务构建、部署和运维的难度,通过利用继续集成和继续交付等办法有助于达到减速推出市场的目标。

故障解决设计(Designfor failure):微服务架构所带来的一个结果是必须思考每个服务的失败容错机制。因而,微服务非常重视建设架构及业务相干指标的实时监控和日志机制。

演进式的设计(EvolutionaryDesign):微服务利用更重视疾速更新,因而零碎的计会随工夫一直变动及演进。微服务的设计受业务性能的生命周期等因素影响。如某利用是整体式利用,但逐步朝微利用架构方向演进,整体式利用仍是外围,但新性能将应用利用所提供的 API 构建。再如在某微服务利用中,可替代性模块化设计的根本准则,在施行后发现某两个微服务常常必须同时更新,则这很可能意味着应将其合并为一个微服务。

微服务实用的场景

基于微服务的劣势,咱们能够看到,微服务比拟实用于以下场景:

对于业务流程较为简单,且业务会变得逐步简单的我的项目,能够思考应用微服务架构

我的项目存在多个团队(公司)多种开发语言时

外围业务和非核心业务变得若明若暗

须要平滑降级时(服务无中断、客户无感知)

想对系统进行细粒度监控时(bug 考察艰难或性能等问题)

既然微服务有其应用的场景,那么也肯定有其优缺点。

微服务的劣势

微服务的诞生正是在互联网高速倒退,技术突飞猛进变动以及传统架构无奈适应疾速变动等多种因素独特推动下的必然产物。从一个网站的演变能够看到应用微服务后带来了很多长处,总结如下:

逻辑清晰:这个特点是由微服务的繁多职责的要求所带来的。逻辑清晰带来的是微服务的可维护性,在咱们对一个微服务进行批改时,可能更容易剖析到这个批改到底会产生什么影响,从而通过齐备的测试保障批改品质。

简化部署:微服务则能够只对一个微服务独自进行部署,不影响其余性能的同时,在效率上也失去了晋升,从而疾速的公布新的性能。

可扩展性强:在分布式系统中,采纳微服务的零碎绝对单块零碎具备更好的可扩展性。

灵便组合缩小节约:在微服务架构中,能够通过组合已有的微服务以达到性能重用的目标,缩小了反复节约。

技术异构:微服务间松耦合,不同的微服务能够抉择不同的技术栈进行开发。

微服务的毛病

以往单体利用,排查问题通常是看一下日志,钻研错误信息和调用堆栈。而微服务架构整个利用扩散成多个服务,定位故障点十分艰难。在微服务架构中,一个服务故障可能会产生雪崩效用,导致整个系统故障。微服务架构尽管逻辑设计上看是完满的,但就像积木搭建的富丽宫殿一样,经不起打草惊蛇。微服务架构尽管解决了旧问题,也引入了新的问题:进步了零碎的复杂度,此外还有:

服务的注册与发现问题;

服务之间的分布式事务问题;

数据隔离再来的报表解决问题;

服务之间的分布式一致性问题;

服务治理的复杂性,服务的编排;

不同服务实例的治理。

微服务在应用上是一把“双刃剑”,这就像粮草如果在搬运的过程中被敌方篡夺,那可能会是毁灭性的。所以 DevOps 团队在微服务的架构上须要十分的器重,一个成熟度高的微服务框架才是实现其 DevOps 的重要前提,反之亦然。

本文分享自华为云社区《没有它你的 DevOps 是玩不转的,你信不?》,原文作者:麻利的小智。

点击关注,第一工夫理解华为云陈腐技术~

正文完
 0