「微服务架构」分散您的微服务组织

本文涉及的产品
注册配置 MSE Nacos/ZooKeeper,118元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
云原生网关 MSE Higress,422元/月
简介: 「微服务架构」分散您的微服务组织

适应性 - 快速,轻松地进行变革的能力 - 已成为现代企业的首要目标,并迫使技术团队构建更容易,成本更低的平台。在这样的环境中工作,这些团队越来越多地被软件架构的微服务风格所吸引。吸引他们的是承诺加快软件更改的方法,而不会给业务带来不必要的危险。

微服务的工作方式在很大程度上可以通过支持软件组件和数据的分散来实现 - 更具体地说,通过将“单体”元素分解为更小,更容易更改的部分,并在网络上部署这些部分。要使这种架构运行良好,需要改变工作方式以及如何管理工作。采用微服务的组织是“脱离开发人员的方式”,并提供自由和自主来实现魔术。

在组织设计中,他们的目标是分散决策权。而不是让少数人为组织中的每个人做出架构和软件决策,分散化将使他们能够在执行工作的人员之间分配决策权。

直接向工人推行决策权使他们能够以更大的自由和自主权生产。在适当的情况下,这将导致更好,更快的变化。但是,如果您的组织弄错了,一系列错误的决策可能会降低变更速度 - 或者更糟糕的是,最终会损害您的业务。

诀窍是只分散那些可以帮助你加速的事情,而不会牺牲系统的安全性。

找到正确的权力下放战略是一个进化过程,需要您进行调整,分析和调整。为了帮助您开始正确的方向,以下是您应该考虑的三个最重要的问题:

我们应该针对哪些决策?

我们所有这一切的目标是增强您平台的可变性。因此,您应首先找到阻止变更发生的瓶颈。仔细研究功能和变化如何从概念转变为实施,并找到需要工作的人不能做的过程部分,因为他们正在等待其他人做出决定。

权力下放不是解除瓶颈的灵丹妙药。然而,在一个倾向于集中决策的组织中,权力下放可能会有所帮助。另一方面,如果您找不到因集中决策流程而导致员工陷入困境的许多情况,那么分散化不应成为您最关心的问题。

使微服务系统工作不仅仅需要改变有关组件大小的想法。组织中涉及创建和更改服务的所有区域都可以发挥作用。以下是可能成为微服务领域分散化候选人的决策类型的非详尽列表:

  1. 服务生命周期 - 服务何时创建或退役?他们叫什么?我们什么时候需要将它们分开?
  2. 服务实施 - 我们应该在每项服务中使用哪些工具,语言和架构?
  3. 系统架构 - 服务如何与其他人交谈?开发人员如何了解它们?
  4. 数据架构 - 如何在服务之间共享数据?
  5. 变更流程 - 何时可以更改服务?部署和QA有哪些工具和流程?
  6. 团队管理 - 谁在哪个团队服务?每个团队负责什么?团队成员做什么?
  7. 人员管理 - 人们如何被雇佣和解雇?员工如何激励和奖励?什么是休假政策?
  8. 安全管理 - 我们如何降低安全事件的风险?需要做些什么才能提高整个系统的安全性?
  9. 采购 - 可以购买哪些软件?使用开源软件需要哪些保护措施?

分析这些空间中的决策是如何制定的,这是值得的。它们如何影响系统的更改方式?哪些决策过程阻碍了你?哪些阻止人们进行创新?最后,在哪些情况下,更多的自由和自治会有益吗?

Netflix是一家能够以创新方式下放权力的公司的典范。其政策赋予员工权力,以决定他们需要多少时间来分散传统上受到严密控制的决策。

赋予员工指定自己的假期分配的权限可能听起来很奇怪。但是,如果您希望将组织的可变性提升到更高的档位,那么您应采取的确切方法是消除冗余和不必要的协调工作,同时避免引入新风险。追求构建软件的微服务风格的团队应该考虑在整个组织中进行这些优化。

这并不意味着分发假日决策的政策应该是微服务架构的原则。 Netflix可以做到这一点,因为它的文化和劳动力使这样的政策更容易实施。它的员工可以做出最适合整个系统的决策,而且公司因其对员工的选择而闻名。

并非每个组织都看起来像Netflix,很少有人在Netflix的在线视频内容传输领域运营。每家公司都有自己独特的约束和目标。您需要为自己发现自己的目标和约束。分析,洞察力和实验将帮助您确定权力下放工作的优先顺序,并引导您的系统实现适应性目标。

参与的人是谁?

人们做出的一些决定对他们公司的影响非常大。改变银行账户交易方式的决定对传统银行来说是有风险的。对于具有熟悉旧接口的大型用户群的软件公司而言,更改应用程序的用户体验的决定将是一种风险。

组织试图加强对这些类型决策的控制,以便最大限度地降低风险,从而实现决策权的集中化。例如,在过去的几年中,Apple以拥有一个高度集中的设计小组而闻名,该小组由相对较少的人组成,他们做出了大部分关于其产品设计的决策。

集中化是因为合适的人需要做出最重要的决策。通常,“合适的人”是那些拥有人才,专业知识和经验的人,这使我们能够充分信任他们以做出最佳决策。我们可以称这些人为我们的“明星”决策者

如果一个组织只有星星,那么它的所有决定都可以分散。如果我们信任更多员工以做出最佳决策,我们会将更多决策分发给更多人。

在实践中,公司拥有数量有限的明星决策者。实际上,大多数团队都有一些明星与更多的决策者相结合,他们有能力但缺乏一些必要的经验或才能来做出完美的决策。

好消息是,你不需要一个全明星团队来采用分权策略。您只需要考虑如何将您的团队组织在一起以及您部署最佳决策者的位置。

微服务风格使这一切变得更加容易,因为决策的影响可以在实现个别变更的速度增加的同时受到限制。如果一个团队在处理微服务时做出了错误的决定,那么错误的爆炸半径应该很小并且包含在内。当系统变更便宜且容易时,团队可以快速改进以前的决策,使他们能够更快地做出最佳决策。

在这种环境中,你不受你的明星力量的限制 - 当目标是达到最佳决策时,你只需要提供一个系统,让有能力的工人获得自由和自主权。

谁拥有哪一部分?

没有立即做出决定。它基于选择,而选择又基于领域知识。决不应立即实施。有时它可能需要某人的祝福,而在其他时候,它可能需要高度专业化的技能或知识来实施。

管理专家Henry Mintzberg为我们提供了一个很好的模型,概述了决策过程的步骤:

  • 研究和信息收集
  • 产生选择
  • 选择(做出选择)
  • 授权选择
  • 执行和实施

所有这一切的关键在于,在采用决策权力下放时,您不需要绝对。 Mintzberg的每个步骤都可以独立集中或分散,在平衡基于决策的系统变更的速度和安全性时,可以提供更大的灵活性。

考虑一家大公司典型招聘流程的情况:当找到新员工时,它是集中的人力资源部门,广播开放职位并邀请人们申请工作。同一个集中团队筛选候选人并生成该组中最佳的列表。然后将该清单移交给实际的招聘经理,该经理根据进一步的审查选择最佳候选人。从那里,招聘经理将球交还给人力资源中心团队,他们完成了文书工作并完成了整个过程。

这种集中式选择生成模式与分散式选择选择相结合是大公司中常见的选择。事实上,大多数采用微服务风格的组织都以某种形式使用它。

例如,集中式企业团队可以识别所有微服务团队应该使用的三种数据库。由各个团队决定选择,但他们可以从提供的菜单中进行选择。如果他们偏离批准的列表,他们将需要证明他们的决定,从而为集中团队提供反馈机制,他们可以重新评估菜单。

分散流程的选择,授权和执行部分可以使各个团队快速,大规模地进行迁移。集中研究和选择生成步骤,总体上损害了创新,但降低了决策的风险,从而对整个系统产生负面影响。这是一种流行的模式,因为它为大多数组织提供了正确的妥协方式。

当人们谈论微服务组织时,权力下放会出现很多,因为它是提高变革速度的有效方法。但不要忘记它只是等式的一部分。您的员工是谁,您的团队如何协调,以及他们所处理的所有系统,工具和环境同样重要。

您必须了解考虑如何制定决策 - 更重要的是,如何改进流程 - 是向变革友好型组织迈进的一种很好的方式。

相关文章
|
6天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
4天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
9天前
|
设计模式 Java API
微服务架构演变与架构设计深度解析
【11月更文挑战第14天】在当今的IT行业中,微服务架构已经成为构建大型、复杂系统的重要范式。本文将从微服务架构的背景、业务场景、功能点、底层原理、实战、设计模式等多个方面进行深度解析,并结合京东电商的案例,探讨微服务架构在实际应用中的实施与效果。
48 6
|
9天前
|
设计模式 Java API
微服务架构演变与架构设计深度解析
【11月更文挑战第14天】在当今的IT行业中,微服务架构已经成为构建大型、复杂系统的重要范式。本文将从微服务架构的背景、业务场景、功能点、底层原理、实战、设计模式等多个方面进行深度解析,并结合京东电商的案例,探讨微服务架构在实际应用中的实施与效果。
25 1
|
15天前
|
弹性计算 Kubernetes Cloud Native
云原生架构下的微服务设计原则与实践####
本文深入探讨了在云原生环境中,微服务架构的设计原则、关键技术及实践案例。通过剖析传统单体架构面临的挑战,引出微服务作为解决方案的优势,并详细阐述了微服务设计的几大核心原则:单一职责、独立部署、弹性伸缩和服务自治。文章还介绍了容器化技术、Kubernetes等云原生工具如何助力微服务的高效实施,并通过一个实际项目案例,展示了从服务拆分到持续集成/持续部署(CI/CD)流程的完整实现路径,为读者提供了宝贵的实践经验和启发。 ####
|
5天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
16 1
服务架构的演进:从单体到微服务的探索之旅
|
4天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
24 5
|
6天前
|
监控 API 微服务
后端技术演进:从单体架构到微服务的转变
随着互联网应用的快速增长和用户需求的不断演化,传统单体架构已难以满足现代软件开发的需求。本文深入探讨了后端技术在面对复杂系统挑战时的演进路径,重点分析了从单体架构向微服务架构转变的过程、原因及优势。通过对比分析,揭示了微服务架构如何提高系统的可扩展性、灵活性和维护效率,同时指出了实施微服务时面临的挑战和最佳实践。
25 7
|
5天前
|
Kubernetes 负载均衡 Cloud Native
云原生架构下的微服务治理策略
随着云原生技术的不断成熟,微服务架构已成为现代应用开发的主流选择。本文探讨了在云原生环境下实施微服务治理的策略和方法,重点分析了服务发现、负载均衡、故障恢复和配置管理等关键技术点,以及如何利用Kubernetes等容器编排工具来优化微服务的部署和管理。文章旨在为开发者提供一套实用的微服务治理框架,帮助其在复杂的云环境中构建高效、可靠的分布式系统。
19 5
|
5天前
|
负载均衡 监控 Cloud Native
云原生架构下的微服务治理策略与实践####
在数字化转型浪潮中,企业纷纷拥抱云计算,而云原生架构作为其核心技术支撑,正引领着一场深刻的技术变革。本文聚焦于云原生环境下微服务架构的治理策略与实践,探讨如何通过精细化的服务管理、动态的流量调度、高效的故障恢复机制以及持续的监控优化,构建弹性、可靠且易于维护的分布式系统。我们将深入剖析微服务治理的核心要素,结合具体案例,揭示其在提升系统稳定性、扩展性和敏捷性方面的关键作用,为读者提供一套切实可行的云原生微服务治理指南。 ####