43

微服务和容器——企业持续交付指南

 5 years ago
source link: http://dockone.io/article/8630?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

【编者的话】微服务、容器及其编排平台是当今的热门话题,并且很多企业已经开始在生产中使用它们,本文就微服务的崛起、企业应用如何从微服务中受益、微服务基于容器技术如何更好更快地持续交付进行了详细的阐述。

很大程度上,当今的企业需要依靠软件应用来促进大量的商业需求。在大多数企业中,一个软件应用往往提供了数百项功能——所有这些功能都集中在一个大型单体应用中。例如,ERP和CRM平台具有统一的架构,有效地服务于数百种功能。但是,由于多个依赖项重叠并创建集群,故障诊断、扩展和升级它们的任务变成了噩梦。有时,企业会为了方便而调整这种单体应用,因为单体应用一旦陷入瓶颈,便不再为任何真正的业务目的提供服务。这时,企业开始寻找实现应用程序现代化和采用灵活性的架构方法。

微服务的崛起

企业对微服务架构的 需求越来越大 ,以实现向现代交付的转变。在此架构下,功能被设计为独立的微服务,这些微服务之间松耦合,以创建一个能够执行多任务的应用程序。这种方法有助于大规模地构建应用,在组件级别进行更改变得容易,而不会干扰应用的其他部分。

FBfiUvv.jpg!web

Netflix是最大的、也是最有趣的成功案例之一,它从单体架构过渡到基于微服务架构的应用。这家媒体服务提供商永远不会忘记2008年的一天,一个分号的丢失导致了重大的数据库损坏,导致整个平台瘫痪了几个小时。Netflix意识到他们必须改变架构方法,从而考虑从单体架构转向微服务架构。

尽管Netflix从2009年开始转向微服务架构,并在2011年成功地运行了基于云的微服务架构,但微服务这个术语在2012年之前并没有出现。直到2014年Martin Flower和该行业的其他领军人物开始 讨论这个问题 时,它才开始流行起来。

Netflix的首席云工程师Adrian Cockcroft是一位有远见的人,他在架构格局的变化中扮演了重要角色,他将微服务 解释 为“具有有限上下文的松散耦合的面向服务的架构”。

由于他大胆的决定转向微服务,Netfix在可扩展性上取得了巨大飞跃。2016年初,Netfix 宣布 将服务扩展到130多个新的国家。

微服务如何使企业应用受益

从单体架构到微服务的过渡可以为企业打开一个充满各种可能性的世界,例如:

  • 能够创建支持服务且独立运行的组件
    这样,每个组件自身都是独立的,但是它们都通过API耦合在一起,作为应用程序以统一的方式工作。
  • 独立测试和运行的组件
    你可以很轻松的对一个组件运行测试与更改,而不必更改任何其他组件。
  • 互连组件的同步工作
    组件使用简单的通信通道和协议作为个体单元共存并协同工作。
  • 一个非集中化的应用程序
    每个组件都是独立的,可以单独开发和部署。因此,消除了由于一个小缺陷而导致整个应用程序崩溃的风险。
  • 分散的数据管理 每个组件都有自己独立的数据库,因此,可有效地防止数据泄露导致接管整个应用程序,并将其限制在一个组件中,这增强了应用程序的安全性。
  • 灵活和可伸缩的应用程序
    应用程序的部分升级或扩展,无需对已经存在的组件进行任何更改。

尽管微服务架构有很多优点,但它也有自己的局限性。微服务面临的最大挑战之一仍然是如何大规模的提供这些服务。这种分段应用的持续集成和交付变得非常复杂,因为需要大量的协调才能同步地集成和部署一组微服务。只有非常高效的DevOps团队才能实现这一壮举。关键是在微服务和它们赖以运行的基础设施之间拥有无缝的通信通道。为了充分挖掘微服务的价值,必须将它们作为可自我维持和可移植的交付单元,这些单元由容器支持。

对于微服务,为什么选择容器

“容器简化了微服务的持续部署”——这句话经常被 技术专家 重复。但是究竟什么是软件容器?它们是如何简化微服务的交付的?

容器所做的与物理容器完全相同,但是更加数字化。简而言之,容器允许你将微服务放入专用的盒子中,其思想是将类服务及其所需的基础设施打包到其中。容器在虚拟化操作系统中提供了一个独立的工作负载环境。通过在单独的容器中运行微服务,可以独立地部署它们。由于容器在隔离的环境中操作,因此可以使用它们部署微服务,而不考虑用于创建每个微服务的代码语言。因此,容器消除了语言、库或者框架之间的任何摩擦或冲突的风险,从而使它们兼容。

由于容器非常轻量且可移植,因此可以使用它们快速部署微服务。通常,应用程序由小型自包含的微服务组成,每个微服务充当一个单一功能的应用程序,通过不依赖于特定语言的API一起工作。因此,容器在这种情况下提供了所需的隔离性,从而支持组件协同。

作为微服务使用容器好处的支持,Docker 报告 表明,使用docker容器的软件发布频率增加了46%。

这些容器可以通过 容器编排平台 进行编排,如Kubernetes、Docker Swarm、Helios等。这些平台可以根据需要创建多个容器,并使它们易于应用的顺利部署。编排还控制如何连接容器,以便从多个微服务构建复杂的应用程序。

展望,前方的道路

虽然容器和编排平台是当今热门话题的一部分,但更大的问题是企业如何以及何时可以开始在生产中使用它们。这两种技术都为应用交付的速度、规模和频率设定了新的基准,如果没有自动化和流程标准化,这将很难实现。这可以通过选择一个高效的应用交付平台来实现,该平台可以为现有应用和未来的云原生应用提供容器化,并无缝地将它们导入Kubernetes,从而实现应用交付过程的自动化。这样可以简单的规范APP的交付流程,加快容器原生交付的关键环节,实现微服务的持续交付。

作者:Spruha Pandya,团队目前正试图破解Kubernetes交付软件的最佳方式。

原文链接: Of Microservices & Containers-An enterprise’s guide to continuous delivery

译者:Mr.lzc,软件工程师、DevOpsDays深圳核心组织者,目前供职于华为,从事云存储工作,以Cloud Native方式构建云文件系统服务,专注于K8s、微服务领域。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK