PerfMa

IT系统稳定性保障专家

请至少选择一个您感兴趣的方案
发送验证码

感谢您的提交!

我们会在2工作日内与您联系

产品

全天候为您的IT系统稳定运行提供有力保障
即刻开启您的IT系统稳定性保障之旅

XSea 全链路压测平台

多地域高仿真流量模拟、端到端流量染色与数据隔离、全链路压测风险熔断

XWind 性能风险巡检与诊断平台

无人值守智能分析、风险处理能力闭环、可拓展性能风险知识库、丰富图表及报告、开放API助力DevOps

TestMa 质量效能平台

全流程的质量闭环,可度量的质量数据,无门槛的接口编排,高效率的精准测试

XChaos 混沌工程平台

应用架构智能感知、故障演练场景丰富、高级多流程编排、多维度演练观测、过程安全控制、第三方集成扩展

XSpider 监控平台

无侵入实时性能分析、低性能开销、动态采样、根因定位

解决方案

沉淀PerfMa多年的业务经验,提供金融、
证券、快消、交运等多个领域的解决方案

金融

依托全链路压测平台的能力,建立一套完整的性能保障体系

电商

基于平台的建设及专家咨询服务,进行统一平台管理,实现工具、框架的统一

连锁快消

实现多维自动化能力,协助构建标准化的性能测试及回归体系,提升测试效率

交通运输

以数据驱动,形成标准化测试能力,保障系统的正确性、性能容量及可靠性

公司动态

全方位汇集PerfMa大小资讯
寻找对您有帮助的事件

PerfMa新闻

PerfMa公司最新动态或消息,为您提供关于PerfMa公司的第一手资讯

PerfMa活动

为您提供PerfMa线上线下精彩活动回顾及预告

关于

和优秀的小伙伴一起共事
不负初心,用技术的力量创造梦想

关于PerfMa

强大的专业团队、企业资深专家,致力于为企业提供性能领域的全方位解决方案

加入我们

浓厚的工程师文化、靠谱的发展平台、舒适的办公环境,拥抱变化中快速成长

社区&开源

汇聚IT系统稳定性领域问题诊断调优精英
共建IT系统稳定性领域问题诊断调优标准和能力

专注性能领域垂直社区,几十万开发者在这里交流性能问题,分享技术干货,是开发者们学习和成长的乐园。


访问HeapDump社区 >

为终结性能问题而生的开源插件容器,将定位/解决各种性能问题的工具适配成插件,通过相互联动组合,一键解决您的性能问题。


访问XPocket官网 >
四种常用的微服务架构拆分方式
2022-03-03

微服务架构并无标准架构,不然什么架构师大会也不会各个系统架构百花齐放了。虽然没有固定的套路,却有一些经验,今天就来做一个总结。

 

基于角色拆分

 

这种拆分方式常见于基础设施以及其PaaS层的架构,比如服务治理、k8s、kafka。所谓基础组件的PaaS层是说,基础设施本身主要作为基础设施使用,是IaaS层。但是基础设施本身需要维护功能,需要增删改查等运维操作。业界基于开源做的二次开发也着重在做这方面的工作。

 

下面以kafka做说明。因为要上升到PaaS层,下图基于美团对kafka的二次开发封装,产品名叫mafka。

 

 

咱们直接看★标注的部分mafka-manager,这个就是运维操作统一管理端。充当的就是管理者的角色。再看看kafka其他组件的名称:生产者( producer )、消费者( consumer )、经纪人( broker )。核查员( monitor )。架构的组织都是根据角色来来划分的。

 

为什么我要将mafka-manager用★标注呢。因为不管是基础设施还是别的,以产品化的观点,需要对外提供一个完整的产品体验。完整的产品包含什么呢?统一的产品外观、统一的接口定义、统一的服务运营。

 

我们要接入mafka,虽然最终程序里要用的是生产者、消费者这些,但是第一步都要在mafka-manager对应的界面上申请。mafka-manager类似于网关入口的角色。业界有专门把这些接口服务抽象出来叫做api网关。

 

在k8s架构中,api网关这个概念更加明显一些。

 

 

kubectl是k8s的控制台命令交互界面、web UI是浏览器交互界面,不同的交互界面会走统一的api server。这里api server就是api网关服务。

 

基于可扩展性拆分

 

首先来了解一下AKF扩展立方体。

 

AKF扩展立方体(Scalability Cube),是《架构即未来》一书中提出的可扩展模型,这个立方体有三个轴线,每个轴线描述扩展性的一个维度:


X轴 —— 代表无差别的克隆服务和数据,工作可以很均匀的分散在不同的服务实例上;

Y轴 —— 关注应用中职责的划分,比如数据类型,交易执行类型的划分;

Z轴 —— 关注服务和数据的优先级划分,如分地域划分。

 

 

白话来说:X轴拆分就是通过加机器水平拆分;Y轴拆分就是按业务逻辑垂直拆分;Z轴拆分就是按照算法进行分片,这个算法比如按地域,不同地域访问不同的分片或者服务。

 

举个例子,比如一般公司的redis集群会有一个团队来进行统一维护。redis集群有主有从,数据都是一样的,多副本容灾,这是X轴水平的拆分。一个公司很多业务,redis团队会对不同的业务提供不同的集群,这是Y轴垂直拆分;集群内部数据会通过sharding做分片,这是Z轴算法拆分。

 

基于稳定性拆分

 

在业务架构中,通常会通过核心模块的划分或者主次链路的划分来进行微服务拆分。

 

在《三平面分离架构》中,我提到过分离出控制平面、数据平面和管理平面。这本质上也是通过核心模块划分来进行拆分的一种方式。控制平台一般是核心链路,核心数据作为控制逻辑的一部分可以通过本地缓存等措施弱依赖于数据平面。管理平台是后台管理等,用于增删改查,人工操作时才用,其他时间挂掉都没关系。

 

基于资源需求拆分

 

根据性能需求来进行拆分。简单来说就是访问量特别大,访问频率特别高的业务,又要保证高效的响应能力,这些业务对性能的要求特别高。比如积分竞拍、低价秒杀、限量抢购。

 

我们要识别出某些超高并发量的业务,尽可能把这部分业务独立拆分出来。这么做的原因非常简单,一个保证满足高性能业务需求,另一个保证业务的独立性,不互相影响。 

 

类似积分竞拍、超低价秒杀、限量抢购,对瞬间峰值和计算性能要求是非常高的。这部分的业务如果跟其他通用业务放在一块,一个是可能互相影响,比如某个链路阻塞,会导致雪崩沿调用链向上传递。

 

另外一个是如果多个业务耦合在一块,发布频率变高、服务扩缩容变难、维护复杂度变高。如下图例子所示,订单服务是一个性能要求高的服务,一般会单独拆分。

 

 


总结

 

咱们实际工作中,通常会发现一种拆分方式和另一种拆分方式并不冲突。一个完整的架构也不只使用了一种拆分方式。《领域驱动设计(DDD)中简单易用的10种技巧》也可以配合来使用。

 

本文提到的api网关严格上不是业务划分时的一个模块。业界通常把api网关作为一个基础设施。如果在架构图中包含了api网关通常是下图所示:

 

 

上图中的架构既包含了业务逻辑的业务划分,也有配置中心、注册中心这样的技术划分。总体上来说是一个技术架构图。而api网关本身也更多被归为是技术概念,而不是业务概念。

 

在《尤娜系统的第一次飞行中换引擎的架构垂直拆分改造》中,首先就拆分出来了api网关层,这说明尤娜要下一盘大棋,最终对外会提供一个统一的产品。


文章来源:CSDN
链接:https://blog.csdn.net/xiexiaojing/article/details/123173357

请至少选择一个您感兴趣的方案
发送验证码

感谢您的提交!

我们会在2工作日内与您联系

业务咨询电话:4008-717-107

公司联系电话:0571-8500-1801