索鸟网

  1. 首页
  2. 专注服务,而非容器

专注服务,而非容器


现阶段而言,容器听起来可能很酷,但这种现状或许不会持续太久。可以预见的是,容器将来也仅仅是一种基础设施。经验丰富的开发人员对部署应用程序的方法和其它几种类型的基础设施可能已经很熟悉了。容器对他们来说没什么大不了的。

 

然而,通过容器架构应用程序,能为基础设施带来新机遇,并且市场前景巨大,这就是为什么微服务应用程序中的服务比其运行的容器化基础设施要重要得多。

 

模块化一直是应用程序架构的目标,如今,微服务的设想已成为可能,如何构建这些服务最终决定了它们将在哪里运行以及它们将以何种方式部署。应用程序的功能通过服务满足用户需求,其价值也通过服务来实现。

 

这就是为什么如果你想充分利用容器,那你应该考虑的不应该仅仅只是容器。你必须关注服务,因为它们是容器启用的关键。


服务和容器


为了便于对话,服务和容器是可以互换使用的,因为容器化应用程序的理想用例是解构到服务中,每个服务都被部署为一个或多个容器。

 

但是,策略不尽相同。服务是一种隐含的基础设施,更重要的是应用程序体系结构。当您谈到作为应用程序一部分的服务时,该服务是持久性的。例如,在没有登录页面或购物车的情况下,你无法临时拥有一个应有程序,还指望其进展顺意。

 

另一方面,容器的生命周期在设计之初就被限定在极短的范围内。理想情况下, 在每次部署或还原时, 一旦新的部署生效并且流量被路由到该容器就被终止。因此容器并不持久。如果交货链正常运行,那根本就不重要。只要新部署已存在并且通信流路由到该容器, 就会立即将其杀死。所以容器不是持久的。如果交付链正常运行, 即使容器终止也无关紧要。

 

微服务,既是一个应用程序,也是一个基础设施术语,它有一些与之相关联的独特元素,从而使它进一步分化。


  • 单个服务可以部署在多个区域。

  • 每个区域都可以有多个版本――例如,A / B测试或Canary版本。

  • 每个服务可能具有不同的生命周期。特定于后端的服务可能比前端服务部署的要少。

 

它甚至不一定意味着一个服务等于一个容器或一个主机。该服务是来自应用程序中功能的逻辑抽象,并不直接与任何基础设施相关。


以服务为中心意味着什么?


专注于您的服务意味着开发人员不会花时间优化或修改容器编排或配置。如果最终版本的镜像已经准备好,开发者只要关心提交他们的代码就可以了。如果开发人员还需要把容器也纳入考虑范围,那就会打破某种平衡。

 

开发人员只有在开发环境中才需要考虑容器相关的事宜。开发环境和生产环境之间的平衡非常重要。要确保开发人员正在对正确的Docker镜像进行测试,并能够访问其他服务,而左移QA是缓解“它在我的机器上明明能正常工作”这一问题的唯一途径。这是通过强大的容器镜像仓库实现的。

 

然而,即使是开发环境也应该被放在最末来考虑。


如何实现以服务为中心的工作流


我希望我可以说,专注于服务是一项独立的开发任务,但其实不是。开发人员已着眼于正在构建的功能,如果他们因容器和业务流程而分心,那也是因为他们是技术狂人,他们想要修补问题,而不是因为他们觉得这是他们的主要职责。

 

以服务为中心,是团队中的每个人的责任。包括如何架构交付链――不仅要快,而且要避免更广泛的团队需要与之进行交互。因此,“以服务为中心”需要从管理开始,下放到传递链(或DevOps),再到工具,最终,开发人员要么保留基础设施包,要么可以自由工作。以下是服务重点的三个关键原则:

 

  • 规范开发环境。您可以通过找到一个强大的容器镜像仓库、审查图像和标准化开发人员在其框中的工具来执行此操作。由于服务是独立开发的,其中一个挑战是在整个应用程序的服务中看到新的功能。因此,开发人员每次提交都可以部署的按需集成环境就显得尤为重要。

  • 保持不可变,不要只是挂在嘴边。要想要以服务中心,你必须将“基础设施不可变”付诸实践,而不仅仅是嘴上说说。这意味着在部署容器后将不得再进行更改,只能选择运行或删除。严格禁止Snowflake镜像或配置,除了服务本身所需功能之外,不允许访问单个容器。

  • 创建可见性。基于服务的应用程序确实有多个单片应用程序的移动部件。这意味着创建可见性并为所有涉众提供访问权限至关重要。可见性还应支持基础设施和应用程序可见性。团队应该能够查看整个应用程序及其中的所有服务,并能检查单个容器。因此对开发团队来说,应用程序的可见性是最重要的。

 

为避免发生重大故障,DevOps团队还需要尽可能地减少网络和安全性的影响,其目标是尽可能多地卸载编排工具。

 

专注于服务的目标是避免分心,只专注于服务功能。如果开发人员专注于构建一个伟大的产品,而DevOps则专注于构建最佳的交付链,那么工具链和流程将会随之就绪以提供支持――如今,这种伟大的产品诞生了,那就是容器和强大的编排工具。

 

用户总是倾向于使用更优质的应有程序,这就促使公司更加精益求精、日臻完善,至于达到这一目标的机制,并非问题的关键所在。因此,下次您再谈论到容器时,不妨考虑把重点放在如何构建更好的服务上。


原文来源:Rancher Labs

本文出自 “12452495” 博客,请务必保留此出处http://12462495.blog.51cto.com/12452495/1946611

服务 容器 模块化

来源地址:http://12462495.blog.51cto.com/12452495/1946611 版权归作者所有!

相关教程

  • 专注服务,而非容器

    现阶段而言,容器听起来可能很酷,但这种现状或许不会持续太久。可以预见的是,容器将来也仅仅是一种基础设施。经验丰富的开发人员对部署应用程序的方法和其它几种类型的基础设施可能已经很熟悉了。容器对他们来说没什么大不了的。 然而,通过容器架构应用程序,能为基础设施带来新机遇,并且市场前景巨大,这就是为什么微服务应用程序中的服务比其运行的容器化基础设施要重要得多。
  • Laravel核心——Ioc服务容器

    服务容器 在说 Ioc 容器之前,我们需要了解什么是 Ioc 容器。 Laravel 服务容器是一个用于管理类依赖和执行依赖注入的强大工具。 在理解这句话之前,我们需要先了解一下服务容器的来龙去脉: laravel神奇的服务容器。这篇博客告诉我们,服务容器就是工厂模式的升级版,对于传统的工厂模式来说,虽然解耦了对象和外部资源之间的关系,但是工厂和外部资
  • Laravel 服务容器实现原理

    前言 通过实现laravel 框架功能,以便深入理解laravel框架的先进思想。 什么是服务容器 服务容器是用来管理类依赖与运行依赖注入的工具。Laravel框架中就是使用服务容器来实现 控制反转 和 依赖注入 。 什么是控制反转(IoC)和依赖注入(DI) 控制反转(IoC) 就是说把创建对象的 控制权 进行转移,以前创建对象的主动权和创建时
  • Laravel 大将之 服务容器 模块

    简介 服务容器是一个用于管理类依赖和执行依赖注入的强大工具。是整个框架的核心; 几乎所有的服务容器绑定都是在服务提供者中完成。 框架调用分析 在框架直接生成服务容器的只有一处,在bootstrap/app.php,通过require引用会返回服务容器实例。通过require引用有两处,一处是public/index.php,服务器访问的入口;另一处是te
  • laravel 自定义门面/服务容器(提供者)

    一. 几个概念(以下是从自定义): 服务提供者 :为相关服务容器提供统一绑定场所. 服务容器 :简单的说实现了某些功能的对象. 契约 :简单的说就是抽象类或接口,供服务容器去具体实里面的方法. 门面:服务容器对象的"静态"接口(别名). 几者的关系: 如果一个类(服务容器)没有基于任何接口(契约) 那么就没有必要将其绑定到容器。事例如下 //自定义
  • 轻松搞定|将PHP和Couchbase应用部署为Docker

    数人云之前分享了《如何用Docker实现PHP命令行程序的CI/CD》,详细地介绍了整体过程中的思路以及以及注意事项,今天带来的文章将阐述怎样部署一个PHP应用容器,并且与后端Couchbase Server容器进行通信。 本篇文章讲述如何创建一个自动提供的Couchbase节点和简化PHP应用程序读取写入Couchbase NoSQ数据库。 首先定义
  • 用尽可能简洁的白话解释微服务架构

    Kevin Casey 用非技术人员也能懂的方式解释微服务架构 进入2017下半年,微服务架构的热度继续攀升,在科技话题中至少可以排在前十名。利用容器技术,通过微服务的方式架构、构建、运维,几乎是无人不知的,但用非技术人员也能懂的方式解释微服务架构,却不是每个人都能做到的事。 在向广泛的受众解释什么是微服务架构时,无论是开发者、还是微服务架构技术供应商,
  • 认识Laravel中服务提供者和服务容器

    其实laravel中的服务容器就是一个依赖容器,依赖容器是什么,请看下文。 依赖注入 当一个系统变复杂后,经常会遇到A类需要B类的方法,B类需要C类的方法这样的情况。传统的思路下,我们会这么写: class Bim { public function doSomething() { echo __METHOD__, "|"