微服务架构理论-扩展立方体篇

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

  近几年的的微服务概念大火特火,随之框架也变得大火起来,尤其是spring boot,可能是因为spring cloud火起来的原因 搞得沉寂多年的dubbo也开始更新变得火起来。

说起微服务对于不了解整个系统架构历史的小伙伴可能有些迷惑,怎么就突然一下子就微服务了,有点摸不着头脑,到底咋回事那?听我娓娓道来!

  很久很久以前的程序员都很牛逼一不开心就自己写个操作系统自己玩,玩着玩着最后就剩下了几个,比如我们熟知的windows,linux,苹果OS,这是我们使用最底层的

操作系统,在操作系统上面我们还要运行我们的应用软件,这个运行的应用软件就是我们今天重点讲解的,然而这个软件一般指企业级软件。

  企业级软件最初只想把那些纸质的数据进行电子化,但是不断的发展,不断的发展,不过也就几十年的时间就出现了如下的架构(原谅我上面墨迹了那么多没用的):

  

  通过上面的发展我们我不在一一讨论除微服务之外的各种优缺点,直奔主题,为什么要用微服务??

  用三个字回答就是“可扩展”,围绕可扩展我们最终实现了微服务化,以及实现了对应的实例框架 spring boot 等

  也就是说,如果 “可扩展” 是抽象类的话,那么微服务就是继承了可扩展并实例化了(原谅我的程序思维)!

  可扩展也是很直白,那就是可以根据实际需要进行扩展。最后很多牛叉的人和组织总结了一个AKF可扩展的立方体

  

  X,Y,Z轴分别代表了不同的扩展方向,下面简单解释一下:

    X轴代表无差别的克隆服务和数据库。用一个人来说X轴的例子可能是公司很多相同的事情分给多个人来干,简单快捷

  在每个克隆实体间无差别的分配任务,每个克隆实体都可以完成其他克隆实体的任务,无论任务分配给了谁。

  每个克隆实体都有工具和资源来尽快完成所分配的任务。

    Y轴代表的是按照交易处理的数据类型,交易任务类型或两者组合分割的工作责任。我们一般用动词或资源进行分离,比如:

  登录,查询,结算等等。把同样的工作分割成流水线式的工作流或并行的处理流,Y轴代表的更多是对工作的“工业革命”,将耦合紧密的

  工作进行进行专门处理。Y轴实质代表责任、行动或数据。实施成本一般比X轴扩展代价高。假如有100个人造100辆车,每个人负责

  造一辆,完成造车全部的任务,不如让100个人执行子任务,如发送机的安装、喷漆、四轮定位。这样就会减少前后交互所需要的上下文

  信息,更专注做某件事情。

    Z轴通常基于请求或客户的信息进行分割。比如我们在分客户时会有 “普通会员”和“vip会员“之分,服务“普通会员”与服务“vip会员”可能

  会有不同。vip会员可能会特殊对待,会有单独的人在处理vip会员的事情。但是他们都是会员。再比如一些客户可能需要专门的账单、

  付款条件和基于业务量的特别互动。我们可能安排最好的财务代表、甚至特别的经理负责一个或多个客户,以专门处理他们的独特需求。

  这样将减少执行绝大多数的计费功能所需的知识量,从而服务好广大客户。

  Z轴分割是成本最高的分割方向,Z轴分割有助于提高交易和数据的可扩展性,如果实施得当也有助于扩展指令集和过程

  

好下面列举一下按三个轴划分的例子

  X轴一般就是负载均衡,比如用F5等硬件设备进行端口轮训负载。

  Y轴主要体现在我们按业务拆分服务,比如登录服务,订单服务等

  Z轴主要是对一些有特殊要求的业务执行单独流程处理,比如按地区提供对应地区客户的服务,根据不同地区不同客户群的生活习惯等进行差异化服务。 

  下面的图会直观一点

  

   AKF扩展立方体XYZ三个轴可以根据实际情况酌情使用其中一个两个或三个都是用,并且三个轴既可以无限向下扩展也可以无限向上扩展。

我们在设计系统架构的时候可以将AKF扩展立方体作为理论指导,设计完之后回过头来看看是否可以做相应的扩展。

  

 

相关文章
|
11天前
|
监控 API 开发者
深入理解微服务架构:构建可扩展的应用程序
【10月更文挑战第6天】深入理解微服务架构:构建可扩展的应用程序
34 0
|
12天前
|
缓存 监控 API
探索微服务架构中的API网关模式
【10月更文挑战第5天】随着微服务架构的兴起,企业纷纷采用这一模式构建复杂应用。在这种架构下,应用被拆分成若干小型、独立的服务,每个服务围绕特定业务功能构建并通过HTTP协议协作。随着服务数量增加,统一管理这些服务间的交互变得至关重要。API网关作为微服务架构的关键组件,承担起路由请求、聚合数据、处理认证与授权等功能。本文通过一个在线零售平台的具体案例,探讨API网关的优势及其实现细节,展示其在简化客户端集成、提升安全性和性能方面的关键作用。
45 2
|
3天前
|
监控 持续交付 API
深入理解微服务架构:构建高效、可扩展的系统
【10月更文挑战第14天】深入理解微服务架构:构建高效、可扩展的系统
17 0
|
10天前
|
消息中间件 监控 API
理解微服务架构:构建灵活和可扩展的应用
【10月更文挑战第7天】理解微服务架构:构建灵活和可扩展的应用
|
10天前
|
消息中间件 监控 API
深入理解微服务架构:构建可扩展与灵活的应用
【10月更文挑战第7天】深入理解微服务架构:构建可扩展与灵活的应用
24 0
|
2天前
|
负载均衡 监控 Cloud Native
云原生架构下的微服务治理策略与实践####
在数字化转型加速的今天,云原生技术以其高效、灵活、可扩展的特性成为企业IT架构转型的首选。本文深入探讨了云原生环境下微服务治理的策略与实践路径,旨在为读者提供一个系统性的微服务治理框架,涵盖从服务设计、部署、监控到运维的全生命周期管理,助力企业在云端构建更加稳定、高效的业务系统。 ####
|
3天前
|
运维 监控 Cloud Native
云原生架构下,微服务治理的艺术与实践####
【10月更文挑战第14天】 在数字化转型的大潮中,云原生技术以其高效、灵活与可扩展性成为企业IT架构的首选。本文深入探讨了云原生架构的核心理念,聚焦于微服务治理的策略与实践,揭示了如何通过精细化管理提升系统的响应速度、稳定性和可维护性。不同于传统的摘要概述,本文摘要旨在直接触及读者关注的核心——即如何在复杂多变的云环境中,实现微服务的高效协同与治理,为读者提供一个清晰的行动指南。 ####
11 1
|
5天前
|
运维 Serverless 数据处理
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
24 3
|
11天前
|
存储 监控 前端开发
掌握微前端架构:构建可扩展的前端应用
【10月更文挑战第6天】随着前端应用复杂性的增加,传统单体架构已难以满足需求。微前端架构通过将应用拆分为独立模块,提升了灵活性与可维护性。本文介绍微前端的概念、优势及实施步骤,包括定义边界、创建共享UI库、设置通信机制等,并探讨其在SPA扩展、大型项目模块化及遗留系统现代化中的应用。通过实战技巧如版本控制、配置管理和监控日志,帮助团队高效协作,保持应用灵活性。微前端架构为构建大型前端应用提供有效解决方案,适合希望提升项目可扩展性的开发者参考。
|
12天前
|
运维 Kubernetes Cloud Native
探索云原生架构:构建弹性、高效和可扩展的现代应用
【10月更文挑战第5天】 在当今数字化时代,企业必须不断适应快速变化的技术环境。传统的单体应用程序已经无法满足现代业务需求,而云原生架构以其独特的优势,正在成为企业数字化转型的基石。本文将深入探讨云原生架构的核心概念、关键技术和应用实践,旨在帮助读者理解如何利用云原生技术构建弹性、高效和可扩展的现代应用。
58 1