扩展微服务的7大要诀 已翻译 100%

oschina 投递于 05/21 14:45 (共 10 段, 翻译完成于 05-23)
阅读 484
收藏 1
0
加载中

在现代应用中使用微服务不再是一个可划分优劣的因素,但是对于希望在当今市场保持技术进步性的组织来说,这是一项迫在眉睫的任务。技术创新的步伐让企业变得更快,更智能,更精简,这意味着要实现IT现代化并保持竞争优势并扩大业务规模。

虽然许多组织都讲述了他们从单一应用程序转向分布式微服务的故事,但Sumo Logic的故事甚至更加激进。在开始Sumo Logic之前,我的团队花费了将近10年的时间来构建和扩展类似的解决方案,仅在单片机架构上作为企业软件提供。我们启动了Sumo Logic方案,专门以新的方式构建下一代日志管理系统:作为分布式,可扩展的多租户服务。

我们从逐渐实施用于日志和指标的超大型数据处理系统的经验中汲取了许多关键经验教训。为了避免我们必须坚持不懈的困难,我在这里提供了七条关于如何利用微服务来扩展业务的技巧。

凉凉_
凉凉_
翻译于 05/22 09:23
0

#1. 执行生产开发单元

首先,你需要建立你的团队。我们目前应用一种称为产品开发单元(PDU)的模型。 PDU是拥有一套微服务的完整单元。这有助于让较小的团队专注于特定的项目,并避免因在一组微服务中拥有太多人手而产生的复杂问题。这实际上是由杰夫贝佐斯在亚马逊出名的“双比萨团队”规则的想法,这意味着如果你不能给一个团队提供两个比萨饼,那么这个团队就太大了。

虽然PDU在其产品特定部分的操作知识和专业知识相当强大,但在需要推出横向更改时也存在不足。 (涉及我们所有微服务的项目的一个例子是从Java 7过渡到Java 8.)让所有PDU执行横向更改并不容易,但是如果您的团队有效地进行沟通,则可以完成。我们通常提名一个人去管理这些变化的并负责与下属人员交流,并且该人员将微服务的颜色编码列表发送到相对较大的分发列表。人们不希望在RED中看到他们的服务出现。

凉凉_
凉凉_
翻译于 05/22 09:37
0

#2. 改变你的组织结构以鼓励所有权

我们划分团队的方式随着时间而改变。在我们刚开始时,组织结构是四五个开发人员和一些微服务。现在团队规模变得更大,我们有40或50个微服务。最初,由一个人或一个团队管理每项服务没有意义,因为架构仍在迅速发展。但随着团队的成长,以及架构的基石落地,我们在几个团队中划分了服务。

构建软件的人员要完全管理它是非常重要的。换言之,他们不仅构建软件,而且还测试,部署和运行它。他们负责整个生命周期。我们喜欢这种问责制。另一方面,人们也需要有足够的自由来完全管理自己的工作,并且有权决定是否对软件做出决定。如果他们在半夜被代码工作吵醒,那么他们也需要被信任来做出一些特殊决定。

当涉及到这一点时,这与社会中的联邦制度和社会文化非常相似,在这个制度中,围绕多个独立单位而建立的系统共同实现了更大的目标。这在一定程度上限制了单位的独立性,但在较小的群体中,他们有权在更高级别的指导原则下自行作出多项决策。

凉凉_
凉凉_
翻译于 05/22 10:18
0

#3. 确定服务边界

在建立服务界限时,其中一些归结为纯粹的直觉。然而,刚开始之时,与其他人一样,我们拿过一块白板,开始标识系统的主要组件,并在它们周围画框。

起初,我们为微服务建立了一个硬边界 - 这是我们非常坚定的战略。我们最初拥有单独的软件仓库,即使在我们刚刚有三个微服务的时候也是如此。在以前的单片系统工作之前,我们已经被搞奔溃了,因为人们往往无法遵循代码组织的基本约定,比如哪些代码应该放入哪个Java包中,哪些包不应该调用其他包。所以为了保持低耦合,我们在这一点上是激进的。我们最终得到了一个庞大的存储库和最终柔和的边界,但工作至今,都是因为我们教导所有团队都尊重边界的结果。

从最初考虑系统的角度来看,领域经验也有帮助 - 最初的团队在构建日志管理系统方面有一定的经验。但是,当然有一些事情我们也弄错了。例如,在某一时刻,我们最初将数据索引和搜索分开,但实际上它们应该是相同的模块或相同的服务。在这些集群之间交换基本相同的数据是一个非常繁琐的过程,除了增加延迟外,它还会对您的架构产生不良影响。事实上,我们花了两三年的时间才弄清楚这个初步决策对架构的核心部分有多大的影响,但一旦我们做到了,它就会让我们的开发人员的工作变得更加轻松。

凉凉_
凉凉_
翻译于 05/23 10:15
0

#4. 谨慎对待服务器升级的时机

我无法夸大这一点:立即升级所有服务是一个坏主意。曾经有一段时间,我们曾经部署过几个星期,看到有些东西出毛病,回滚,然后重新开始。然后我们部署了,看到另一件事情又出毛病,回滚了,再次从头开始。在某一时刻,我们连续三,四,五周做了这个。我们最终意识到这是荒谬的,必须有一种更有效的方式去实现它。当然,对今天的人来说这是常识,但早在2010年,那时候人们必须自己发现这些基本事实。

当时,我们已经有大约25个服务和一个约15或20人的团队。另一种方法是通过服务推出升级服务,这似乎同样荒谬。如何升级服务,重启服务,并确保它在两小时的维护时间内正常运行25次?简短的回答:不可能。

我们在应付某些情况的时候。我们发明了一个名为“组装团队”的概念,这是25个服务的小组。这两项服务中的任何一项都可以一起升级,这对团队来说是一个更现实的任务。

凉凉_
凉凉_
翻译于 05/23 10:25
0

#5. 拥抱多种测试方式

使用微服务进行测试很困难,特别是一旦您转向持续部署模型。为了解决这个问题,我们投入了大量的资金 - 并且继续投入相当大的资金进行整合和单元测试,并且我们使用几种不同的方法来测试每个单独的情况。

一种方法就是我们所说的“本地部署”,在这种方式下,您可以在笔记本电脑上运行大部分服务以获得完全正常运行的系统。但是,目前带有16GB内存的笔记本电脑已经达到了极限,因此不容易扩展。

第二种方式就是我们所说的“个人部署”。这里的每个人都有自己的AWS账户,我们的部署工具完全自动化,您可以在10分钟内在AWS中建立一个完整的Sumo Logic实例。这是项目百分之百诞生在AWS云服务中的好处。

第三种方式就是我们所说的“桩部署”,这是我们建立的一个桩模块的名称。部署可以让你写微型服务的桩代码,表现得好像他们是真正的服务,并且在我们的服务发现中自我通知,就好像他们是真正的服务一样。但是,它们是一个虚拟的实现,它可以执行一些您可以控制的操作。这比运行所有这些服务要轻巧得多。

例如,如果您正在使用搜索组件,则始终需要知道哪些客户存在这个服务。您还需要知道用户和分区的服务,但您并不需要真正的版本及其所有的复杂性和功能。你只需要假装在这里有用户的东西。我们在这种情况下使用部署

凉凉_
凉凉_
翻译于 05/23 10:39
0

#6. 加上安全防线和安全中心

客户越来越重视对GDPR,HIPAA,PCI等认证的遵守。

鉴于此,安全必须从头开始建立。我们的部署工具是模型驱动的,并且该模型不仅了解集群和微服务等内容,而且还了解它们如何相互交流。我们可以从该模型生成一套相当紧密的安全控制机制。

例如,在网络层面上,我们可以严格根据谁与谁谈话的理解来生成防火墙规则。这是AWS为我们做了一些繁重工作的地方之一。

从安全的角度来看,建立在云服务上可能是有利的。你根本无法手动做任何事情,所以一切都必须自动化。一旦你开始编写和自动化所有的东西,默认情况下将所有东西都捆绑起来会更容易。

但是安全不仅仅是架构和代码 - 实际上它周围有很多过程。具体而言,客户需要查看审计报告。通过查看和审核对控件的要求,然后对其进行测试,您可以将审核过程转化为优势。然后,当审计员再次测试时,它们无形中建立了一个良好的习惯。

凉凉_
凉凉_
翻译于 05/23 10:47
0

#7. 使用维基百科来满足您组织的特定需求

总结经验意味着会积累大量信息,并且通常很快。许多开发团队转向使用他们的内部维基页面来记录文档和工作实践经验。但是,如果任由组织中的任何人进行编辑,这些内容可能会变得杂乱无章。像这样的内容很难管理和维护,因此最好指定负责维护组织维基的管理人员。

虽然指定管理人员可能感觉任务过于集中或者负担过重,但要激励一组开发人员去随时更新维基是很困难的。此外,虽然技术人员(尤其是初创公司)常常拥有很多头衔,但作为领导应优先考虑去维护此文档和最佳实践方式。

维基版主应该对他们策划的内容进行策略性的制定。不要将所有东西都包含在内,而应将其限制在开发人员需要了解的关键概念上。太多的内容可能会让人无所适从,并导致利用率不足。

凉凉_
凉凉_
翻译于 05/23 11:02
0

使用微服务分而治之

微服务架构的核心是分而治之。需要建立的分布式系统将变得复杂 - 这是一个给定的问题。解决这个问题的一种方法是试图限制任何给定部分的复杂性,并且通过遵循这七个技巧,组织可以更轻松地进行处理。

采用微服务架构是扩展系统和人机系统的最佳方法之一,尤其是考虑到功能性(特别是非功能性)需求的复杂性。虽然从庞大的系统过渡到微服务似乎是一项艰巨的任务,但如果您能够围绕这一想法动员开发人员并掌握相关所有知识,不仅可以轻松管理过渡期,还可以简化扩展的过程。这对开发人员来说背负了沉重的负担,并最终构建了一个更有效的系统,以更好地满足客户的需求。

凉凉_
凉凉_
翻译于 05/23 11:08
0

Christian Beedgen:作为Sumo Logic的联合创始人兼首席技术官,Christian Beedgen利用18年的从业经验打造行业领先的企业级软件产品。自2010年以来,他一直致力于构建Sumo Logic的多租户(multi-tenant)、云原生的机器数据分析平台,该平台目前已被1,600多名客户和50,000名用户广泛使用。在加入Sumo Logic之前,Christian早期曾担任ArcSight的工程师、工程总监和首席架构师,为ArcSight的SIEM和日志管理解决方案做出贡献。

Tocy
Tocy
翻译于 05/21 16:35
0
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(0)

返回顶部
顶部