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

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

  

 

相关文章
|
1天前
|
监控 持续交付 Docker
使用Docker进行微服务架构的最佳实践
【5月更文挑战第10天】本文探讨了使用Docker实施微服务架构的最佳实践。首先,理解微服务架构是拆分小型独立服务的模式,借助Docker实现快速部署、高可移植性和环境一致性。Docker的优势在于服务扩展、容器编排、自动化构建与部署。最佳实践包括:定义清晰服务边界,使用Dockerfile和Docker Compose自动化构建,利用Docker Swarm或Kubernetes编排,实施服务发现和负载均衡,监控与日志记录,以及持续集成和持续部署。Docker虽重要,但需与其他技术结合以确保系统整体稳定性。
|
1天前
|
缓存 负载均衡 API
微服务架构下的API网关性能优化实践
【5月更文挑战第10天】在微服务架构中,API网关作为前端和后端服务之间的关键枢纽,其性能直接影响到整个系统的响应速度和稳定性。本文将探讨在高并发场景下,如何通过缓存策略、负载均衡、异步处理等技术手段对API网关进行性能优化,以确保用户体验和服务的可靠性。
|
1天前
|
监控 持续交付 开发者
构建高效微服务架构:后端开发的新范式
【5月更文挑战第10天】在现代软件开发领域,微服务架构已经成为一种流行的设计模式,它通过将大型应用程序拆分为一组小型、独立和松散耦合的服务来提供更高的可伸缩性和灵活性。本文深入探讨了微服务架构的设计理念、实施步骤以及面临的挑战,并提出了一套实用的策略和最佳实践,帮助后端开发者构建和维护高效的微服务系统。
|
1天前
|
存储 监控 API
构建高效微服务架构:后端开发的现代实践
【5月更文挑战第9天】 在本文中,我们将深入探讨如何在后端开发中构建一个高效的微服务架构。通过分析不同的设计模式和最佳实践,我们将展示如何提升系统的可扩展性、弹性和维护性。我们还将讨论微服务架构在处理复杂业务逻辑和高并发场景下的优势。最后,我们将分享一些实用的工具和技术,以帮助开发者实现这一目标。
|
2天前
|
负载均衡 算法 NoSQL
探索微服务架构下的服务发现与治理
【5月更文挑战第9天】 在当今的软件开发领域,微服务架构已成为构建可伸缩、灵活且容错的系统的首选模式。随着服务的增多,如何有效地进行服务发现与治理成为了关键的挑战。本文将深入探讨微服务环境中服务发现的机制和治理策略,分析不同服务发现工具的优缺点,并提出一种基于一致性哈希和健康检查相结合的服务治理方案,旨在提高系统的可用性和性能。
|
2天前
|
监控 API 持续交付
构建高效可靠的微服务架构:策略与实践
【5月更文挑战第8天】在当今快速演进的软件开发领域,微服务架构已经成为实现敏捷开发、持续交付和系统弹性的关键模式。本文将探讨构建一个高效且可靠的微服务系统所必须的策略和最佳实践。我们将从服务的划分与设计原则出发,讨论如何通过容器化、服务发现、API网关以及断路器模式来优化系统的可伸缩性和鲁棒性。此外,我们还将涉及监控、日志管理以及CI/CD流程在确保微服务架构稳定运行中的作用。
|
2天前
|
消息中间件 Java 微服务
Java微服务架构实践指南
Java微服务架构实践指南
12 0
|
3天前
|
API 持续交付 开发者
构建高效微服务架构:后端开发的新视角
【5月更文挑战第8天】 随着现代软件开发的演变,微服务架构已经成为了企业追求敏捷、可扩展和灵活部署的重要解决方案。本文将深入探讨如何构建一个高效的微服务架构,包括关键的设计原则、技术栈选择以及持续集成与部署的最佳实践。我们还将讨论微服务带来的挑战,如数据一致性、服务发现和网络延迟,并提出相应的解决策略。通过本文,后端开发者将获得构建和维护微服务系统所需的深度知识,并了解如何在不断变化的技术环境中保持系统的健壮性和可维护性。
35 8
|
3天前
|
Kubernetes 持续交付 开发者
构建高效微服务架构:后端开发的新趋势
【5月更文挑战第8天】 随着现代软件开发的不断演进,微服务架构已成为众多企业解决复杂系统问题的首选方案。本文深入探讨了微服务架构的核心概念、设计原则以及实施策略,旨在为后端开发者提供一种清晰、高效的技术路径。通过分析微服务的优势与挑战,结合具体的应用实例,文章将展示如何通过容器化、服务网格和持续集成/持续部署(CI/CD)等先进技术手段,实现后端服务的高可用性、可扩展性和敏捷性。
|
3天前
|
消息中间件 监控 Java
构建高效微服务架构:后端开发的新趋势
【5月更文挑战第8天】随着现代软件开发的复杂性日益增加,传统的单体应用架构逐渐难以满足快速迭代和灵活部署的需求。微服务架构作为一种新的解决方案,以其模块化、独立性强和易于扩展的特点,正在成为后端开发领域的重要趋势。本文将深入探讨如何构建一个高效的微服务架构,并分析其对后端开发实践的影响。