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

本文涉及的产品
云原生网关 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扩展立方体作为理论指导,设计完之后回过头来看看是否可以做相应的扩展。

  

 

相关文章
|
20天前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
19天前
|
Java 开发者 微服务
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
138 68
从单体到微服务:如何借助 Spring Cloud 实现架构转型
|
18天前
|
运维 监控 持续交付
微服务架构解析:跨越传统架构的技术革命
微服务架构(Microservices Architecture)是一种软件架构风格,它将一个大型的单体应用拆分为多个小而独立的服务,每个服务都可以独立开发、部署和扩展。
149 36
微服务架构解析:跨越传统架构的技术革命
|
21天前
|
设计模式 负载均衡 监控
探索微服务架构下的API网关设计
在微服务的大潮中,API网关如同一座桥梁,连接着服务的提供者与消费者。本文将深入探讨API网关的核心功能、设计原则及实现策略,旨在为读者揭示如何构建一个高效、可靠的API网关。通过分析API网关在微服务架构中的作用和挑战,我们将了解到,一个优秀的API网关不仅要处理服务路由、负载均衡、认证授权等基础问题,还需考虑如何提升系统的可扩展性、安全性和可维护性。文章最后将提供实用的代码示例,帮助读者更好地理解和应用API网关的设计概念。
49 8
|
26天前
|
监控 持续交付 API
深入理解微服务架构:构建高效、可扩展的系统
深入理解微服务架构:构建高效、可扩展的系统
45 3
|
26天前
|
消息中间件 运维 Kubernetes
后端架构演进:从单体到微服务####
本文将探讨后端架构的演变过程,重点分析从传统的单体架构向现代微服务架构的转变。通过实际案例和理论解析,揭示这一转变背后的技术驱动力、挑战及最佳实践。文章还将讨论在采用微服务架构时需考虑的关键因素,包括服务划分、通信机制、数据管理以及部署策略,旨在为读者提供一个全面的架构转型视角。 ####
35 1
|
28天前
|
弹性计算 运维 开发者
后端架构优化:微服务与容器化的协同进化
在现代软件开发中,后端架构的优化是提高系统性能和可维护性的关键。本文探讨了微服务架构与容器化技术如何相辅相成,共同推动后端系统的高效运行。通过分析两者的优势和挑战,我们提出了一系列最佳实践策略,旨在帮助开发者构建更加灵活、可扩展的后端服务。
|
28天前
|
消息中间件 运维 Cloud Native
云原生架构下的微服务优化策略####
本文深入探讨了云原生环境下微服务架构的优化路径,针对服务拆分、通信效率、资源管理及自动化运维等核心环节提出了具体的优化策略。通过案例分析与最佳实践分享,旨在为开发者提供一套系统性的解决方案,以应对日益复杂的业务需求和快速变化的技术挑战,助力企业在云端实现更高效、更稳定的服务部署与运营。 ####
|
19天前
|
Cloud Native API 持续交付
云原生架构下的微服务治理策略与实践####
本文旨在探讨云原生环境下微服务架构的治理策略,通过分析当前面临的挑战,提出一系列实用的解决方案。我们将深入讨论如何利用容器化、服务网格(Service Mesh)等先进技术手段,提升微服务系统的可管理性、可扩展性和容错能力。此外,还将分享一些来自一线项目的经验教训,帮助读者更好地理解和应用这些理论到实际工作中去。 ####
35 0
|
27天前
|
负载均衡 Java 持续交付
深入解析微服务架构中的服务发现与负载均衡
深入解析微服务架构中的服务发现与负载均衡
61 0