前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >采用微服务和容器架构的五个想法

采用微服务和容器架构的五个想法

作者头像
程序你好
发布2018-07-23 09:46:24
3320
发布2018-07-23 09:46:24
举报
文章被收录于专栏:程序你好程序你好

作为New Relic容器Fabric项目(我们的内部容器编排和运行时平台)的首席站点可靠性工程师(SRE),我花了大量时间与现有和潜在客户一起回答关于我们如何使用和管理容器来创建由数十个微服务组成的平台的问题。

我们肯定认为自己是容器的早期采用者,我们几乎在2014年夏天发布了第一个可生产的容器版本后就开始在容器中包装服务。与我交谈过的许多客户都刚刚开始——或者正在考虑开始——这样的旅行,他们想知道我们所知道的一切。他们想知道我们如何使它工作,以及我们如何架构它。但是,我想强调的是,他们需要知道我们从我们在这个过程中所经历的事情中学到了什么。

考虑到这一点,以下是我想与任何考虑容器和微服务的人分享的5个要点:

1。发展永不停止

认真对待您的采用项目,把它像一个产品。给它一个名字,甚至一些内部品牌,一个清晰的产品愿景。它应该被管理并赋予生命。

我们当前版本的容器结构并不是我们第一次尝试自定义编排和交付。我们在2014年构建了我们的原始版本,一旦我们达到了我们认为需要的程度,我们就停止了开发。我们没有开发人员喜欢使用和构建的部署平台的完整愿景,它只满足我们对一致抽象层的需求。

所以两年过去了,我们才开始重新投资我们的集装箱平台。我们的第一个版本并没有停止使用,但是我们没有捕获Docker快速开发阶段中出现的许多增量改进。

我们一个运行时间最长的客户在同一时期经历了类似的容器编排/微服务过程,并且他们比我们今天走得更远。当我们问他们是如何走到这一步时,他们的回答非常简单:“我们只是一直在努力。”

2。逐步构建它,并从早期采用者开始

当你转移到容器时,采用一种新技术(如Kubernetes)并不意味着你直接进入深水区,将你的整个生产机群移动到巨大的可获得的集群中。把东西一块一块一块地做起来不是更容易吗?

当我们开始使用Container Fabric时,我们将rollout限制为最简单的用例,我们可以服务无状态HTTP服务——没有持久性、没有非HTTP协议,只有一个部署方案。这将平台的特性占用减少到我们知道我们可以在合理的时间范围内有效地服务。

这很重要,因为容器调度平台不能提供一切。我们仍然需要监视平台、对其部署更改、处理秘密、配置自动负载平衡和捕获日志——所有这些都是富服务平台附带的内容。限制目标服务类型使我们更容易推断平台的组件。

因此,如果您确定需要某种容器编排,请仔细查看容器平台提供的内容,并考虑缺少什么。您需要在该平台之上构建什么来支持您的特定服务和基础设施上下文?

此外,要了解团队的文化和可用性。谁是贵公司的早期采用者?哪些团队已经准备好进入一个新的范式?哪些团队正在构建适合于微服务体系结构的服务?哪些团队受困于遗留的巨大单体应用,需要更多的时间、计划和实验?

3、一个型号尺寸并不能适合所有人

当涉及到容器和微服务时,有些系统不适合这个模型,如果您从一开始就认识到这一点,就会更容易。新系统中的技术通常是,移植旧系统的努力可能比它的价值更麻烦。

我们的平台继续主要服务于HTTP服务,但我们也开始处理更多的流处理服务。我们仍然不做持久存储或数据库。(数据库团队使用Megabase处理这个问题。)

最新的技术和体系结构都是关于快速迭代和分散控制的,因此,如果这些东西对您的业务目标并不重要,那么就让这些旧的遗留系统慢慢退役,直到您有逻辑的业务需要迁移它们为止。

4、技术变化就是组织机构的变化

当New Relic团队将他们的服务转移到Container Fabric上时,他们的操作工作量通常会降低。在某些情况下,团队会减少大量的工作,使他们能够在其他项目上获得更多的回报。这是自动化减轻工作负担的最好例子,我们很高兴看到这一点。迁移过来的团队可以更自由地构建让客户满意的软件

考虑迁移到容器和微服务体系结构的组织应该问自己以下问题:

您的操作组向开发人员提供什么产品,该产品使用什么抽象层?

这对你的生意是合适的还是容器更合适?

容器是否更好,以至于您愿意更改抽象,从而更改您的操作团队提供的整个产品,以便使用它们?

您准备好创建新的角色来管理这个新的抽象的规模和可靠性了吗?

没有组织像这样一夜之间发生变化。从理想的新体系结构到第一次生产部署的过程需要改变许多人的想法并创建新的过程——这并不总是有趣的。

5、开发软件需要的是人的经验

一个丰富的、复杂的容器调度平台需要几百年的经验来构建、维护和扩展。这些平台和体系结构要求您接受新的上下文,并要求您的组织在设计中接受权衡取舍,以便您调整它以适应您的用例。采用容器化的微服务体系结构是一项很重要的工作,它可能会改变您所有团队的工作平衡;这会影响他们的生活方式;它有时会影响他们在工作中的幸福感。除非您真正考虑到平台采用的这些人的方面,否则迁移将会比需要的困难得多。

由于我们的组织结构,我们已经为成功的迁移做好了准备。新Relic的每个服务都由一个团队拥有,他们计划、计划、部署和操作它。这种结构已经存在多年,而容器Fabric平台使这些完全所有者团队的工作更简单,让他们能够提升操作抽象层和更接近业务目标。

容器,尤其是它们的调度器平台的承诺通常是“这是每个人都应该开发软件的方式——它充满魔力”。这通常是真实的容器平台确实使一些非常强大的功能,并且值得认真对待。但请记住,它们都以一种固执己见的方式解决平台产品化问题。如果这些观点也可以是你自己的,那么你就需要合理解释。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2018-06-28,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 程序你好 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
容器服务
腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档