您好,欢迎来到12图资源库!分享精神,快乐你我!我们只是素材的搬运工!!
  • 首 页
  • 当前位置:首页 > 开发 > WEB开发 >
    号称“天生一对”的容器+微效劳,能躲开微效劳的悖论圈套吗?
    时间:2018-02-28 21:03 来源:网络整理 作者:网络 浏览:收藏 挑错 推荐 打印

    容器和微效劳是不是天生一对?容器化环境能否能更好地实施微效劳?本文作者走访了数位亲身实际者,给出了一些停止容器化微效劳管理的6大建议。假设您也在评价思索微效劳技术,此文不要错过。

    一、微效劳的悖论

    Gianna作为初级软件工程师参加了Avidoo公司,这是一家消费力平台。在与其他团队的会议上,她提出了微效劳的成绩,以及团队能否末尾采用。她立刻失掉了剧烈的反响。

    拜伦表示:“我们尝试过采用微效劳,但是它们不起作用。

    “这带来了可怕的混乱!”另一位同事补充说。

    Gianna三次眨巴眼睛,等候着某种阐述,但没有一个往下接着说。

    Gianna沉默了一会儿,问:“发作了什么事?

    “后来很棒。每次我们被要求做新的东西时,我们都可以添加一个效劳,并运用想要实验的任何言语和框架。我们将REST API 发布在需求与之协作或在其数据库上任务的系统上。但过了一段时间,事情末尾越来越频繁地割裂,开发速度加快了。 Gianna叹了口吻。听起来像她的团队不断在树立一个散布式的巨石运用,而他们计划树立的是微效劳。

    散布式巨石运用和其他庞然大物

    Gianna所遇到的成绩太常见了。微效劳是灵丹妙药,IT经理和工程师倾向于区分哪些优势与他们的组织相顺应。

    却遗忘了天下没有收费的午餐这件事。除了优势之外,精心打造的微效劳架构也有被微辞的一面。没有任何“错误”的微效劳,只要微效劳不能提供的益处,或许由于它们的缺陷而形成的不可接受的风险。运用微效劳的优势选择采用微效劳应该首先决议哪种优势适宜本身的企业。以下是一些突出的优点:

    1.增强团队的自主性

    许多公司围绕团队成员具有的知识或组件组织团队。在发明真正的客户价值时,这要求团队之间停止少量的协调,不能够同时处置一个特性。

    号称“天生一对”的容器+微效劳,能躲开微效劳的悖论圈套吗?

    应用单一专业团队发明价值

    微效劳经过cover一个功用来促进自治。因此,一个团队可以完全拥有它,而不需求多个团队一同,这有助于增加跨团队的协调。

    号称“天生一对”的容器+微效劳,能躲开微效劳的悖论圈套吗?

    应用多学科团队发明价值

    2.更大的容错

    团队自治的中央也应该有自治的特点。一个功用通常依赖于另一个。在大少数环境中,通讯经过REST接口,按需和pull-based。当这种互动是关键义务时,依托这种通讯的效劳要么必须有合理的fall-back,要么就会失败。这种不安康的形式常常被系统运转状况反省所证明,假设系统的一个依赖性不安康,系统运转就会失败。除了招致部署顺序难以管理之外,它还阐明了系统依赖性的困难。

    号称“天生一对”的容器+微效劳,能躲开微效劳的悖论圈套吗?

    运转时依赖关系

    运用正确的软件架构(如event sourcing),能够补充CQRS,可以完全消弭大少数功用之间的运转时依赖。这主要是由于从pull-based系统向push-based系统的转变。

    3.细粒度的软件生命周期管理

    开发和业务人员一个共同的愿望是,尽快用新顺序交流运用顺序中的某个功用。无论是由于要求改动或许重写,又或由于紧张的上市周期需求而招致的技术债务,都使得开发速度落后了。有人能够天真地以为,这些是可以快速被替代的,但其实不然。常常改换功用招致不得不对其所依赖的许多系统停止更改,反之亦然。

    缺乏细粒度的软件生命周期管理

    经过高度调理系统间通讯,可以完全切换一个或多个功用,而不必触发任何依赖系统。

    4.灵敏的技术选择

    不可否认,这是一个顺手的成绩。在需求或团体兴味的推进下,入职和培训员工切换到通用技术有助于团队间的活动性。但是关于运用不同技术的几个部门的员工,坦率地说,这能够招致大规模的罢工。

    号称“天生一对”的容器+微效劳,能躲开微效劳的悖论圈套吗?

    迫使技术做出选择

    只需这些技术可以集成到自动化测试和部署任务流程中,一个团队就可以保持本人的技术选择。为什么要改动一个勾搭在对C#一切东西都十分热爱的成功团队呢?只需他们可以产出契合平台监控,日志记载和通讯规则的组件。

    那么为什么他们失败了?

    由于不知道应该如何去做微效劳。采用微效劳并不会失败,由于人们不知道如何去做,他们常常不记得首先要处置什么成绩。与其他任何决议一样,采用微效劳会带来一些成本。软件架构师往往会遗忘,他们不应该协助企业的管理者采用微效劳,而应该协助他们处置真正的业务成绩。恰外地权衡这些方面的成本和收益对企业的需求至关重要。

    二、微效劳和容器:6大长期管理技巧

    部署基于容器的微效劳仅仅是个末尾,如何有效管理它呢?在我们最近发布的有关微效劳和容器入门的文章中,Cloud Technology Partners公司副总裁兼首席云架构师 Mike Kavis分享了一个好音讯:“部署容器十分容易。

    他言简意赅的说:“虽然部署容器很容易,但是要多思索这些系统的运维。”

    你可以用容器化的微效劳深化到消费环境,但大少数专家不会引荐它,特别是假设这是你第一次运用这个弱小的技术。

    基于容器的微效劳有相当多的优势:正如红帽技术布道者(Gordon Haff)最近写到的:“即使Match.com(编者注:一家相亲配对网站)也找不到微效劳更好的协作同伴。”但是 IT Heaven所做的大部分任务都需求弱小灵敏的方案,继续管理企业的容器化微效劳架构。你的企业中能够存在一条学习曲线,需务实施智能最佳实际,确保高效运营。

    SolarWinds公司的担任人Kong Yang说:“第一天之后,一切事情都变得愈加复杂。

    我们讯问了Yang、Kavis等人,他们对有效管理容器化微效劳的最佳建议。

    1.保持复杂

    面对不断添加的复杂性,想要保持高效吗?那就保持复杂,愚笨。这种设计和工程原理,通常被以为是航空和系统工程师Clarence “Kelly” Johnson的指点准绳。

    关于Johnson来说,KISS和管理哲学一样重要,“我们的目的是经过对顺手成绩的常识运用来更快更高效地取得结果。

    关于IT团队来说,这些想法有一个可见的翻译,特别是在微效劳和容器方面。

    “为确保今后的成功运营,让每个微效劳做一件事,做得十分好。不要将附加功用扩展到现有的执行良好的微效劳里。”

    2.尽早把管理方案落实到位

    微效劳和容器可以完成更快,更灵敏,更弹性,照应速度更快的软件团队。但首要的事情是,在部署到消费之前制定一个方案。这样一个方案的范例框架如下:

    开发部署,安全和运维的最佳实际微效劳和容器应用现代化的日志记载和监控处置方案探求容器管理工具(又名编排平台,如Kubernetes),在云端和非云端点上了解本身的环境活期实行post-mortems,不断学习和提高

    3.选择一个编排平台

    编排工具关于容器化微效劳的长期成功至关重要。

    (责任编辑:admin)