微服务拆分的原则 - 腾讯云开发者社区 - 腾讯云

开发者社区

文档建议反馈控制台

最新优惠活动

文章/答案/技术大牛

发布

微服务粒度拆分的原则

微服务架构是模块化的一种方法，它把一整块应用拆分成一个个服务，以便于团队在开发复杂的应用时，能够更快地交付出高质量的软件。但从单体架构到微服务，拆分粒度很难把握。究竟有什么好的拆分理由呢？...团队组织架构按照康威定律的说法，组织结构一定会反映到系统架构上，一般是树形结构 + 底层网状结构，服务之间一定是每个系统的架构呈明显的树状，但是系统之间会有多重的服务互访。...应该尽量将处于生命周期中不同阶段的接口分割，避免高频更新服务和低频更新服务捆绑，避免向稳定运行的服务组添加新业务接口，而是应该考虑在新的服务组中实现。 3....调用频率服务组中的不同服务调用频率会有巨大差别，而高频调用肯定会占据更多的资源，会出现个别接口耗尽资源导致同组接口一起失败（资源竞争），需要对高频访问的服务设置定制的运行策略，如分配更多的 CPU 核心数和内存...这些和读操作都有巨大差异性，因此建议流量较大或较为核心的服务应该做读写分离，分拆为两个服务组发布。最后微服务的“微”如何做到足够合适的粒度，是一门艺术。

2.5K1 0

微服务设计、拆分原则

AKF拆分原则业界对于可扩展系统架构设计有一个朴素的理念：通过加机器就可以解决容量和可用性问题。...01 Y轴（功能）关注应用中功能划分，基于不同的业务拆分 Y轴扩展会将庞大的整体应用拆分为多个服务，每个服务实现一组相关的功能，如订单管理、客户管理等。...在工程上常见的方案是服务化架构（SOA），比如对于一个电子商务平台，我们可以拆分成不同的服务，组成类似下面的架构： ?...3、前端多渠道继承场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支持多个前端，例如：微信h5前端、PC前端、安卓前端、IOS前端。 ? 无状态服务 ?...这个无状态服务原则并不是说在微服务架构里不允许存在状态，表达的真实意思就是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。

9253 0

您找到你想要的搜索结果了吗？

是的

没有找到

微服务拆分原则之 AKF

这儿引入一个概念,微服务设计原则之一——AKF原则微服务拆分原则之AKF 首先来看单节点的单点故障这个问题,既然单节点容易挂,那么就可以进行复制,一变多,这儿设计到三个概念,主从、主主、主备,也是三种方式...,简单来说,主主相当于多台服务器同时对外提供读写: 主从,主机可以读写,但是一般只对外提供写,从机对外提供读: 主备,主机提供读写,备机不对外提供服务,当主机挂了的时候,备机通过选举产生主机对外提供服务...Y轴拆分这时候又有新的问题,例如一台服务器中,可能某些功能被频繁访问,涉及到的数据频繁读写,其他数据基本不怎么访问,这时候可以将这部分数据独立出来,也就是根据功能、业务继续拆分服务器,这种拆解就是AFK...中的Y轴拆分特点是Y轴纵向来看不同的Redis负责的功能是不同的,也就是所包含的数据也是不同的,另外仅仅扩展出一个Y轴上的业务服务器,又可能会存在单点问题,所以可以结合AFK的X轴拆分原则,继续对刚拆分的...Z轴拆分在上面的AFK原则X-Y拆分之后,对服务器显示做了主从主备复制,然后做了业务拆分,不同的Redis负责不同的业务请求,这时候还会有一个新的问题,例如对于Y轴上一个Redis,它负责某一样业务,

7413 0

微服务的拆分规范和原则

前言前面我们了解了什么是微服务和为什么需要做微服务架构(What & Why)，本文我们就来探讨如何做微服务架构的拆分(How) 微服务拆分没有一个绝对正确的方案，服务拆分的粒度完全要根据业务场景来规划...我这里总结了几个服务拆分的心法秘籍，同学们可以照着这个路子去思考服务拆分的粒度我行走江湖就靠着这套武功心法。拆迁方案这辈子当不成拆迁户的同学们，你们也别灰心，咱房子拆不成，微服务还是可以拆一拆的。...业务模型拆分业务模型拆分的维度有很多，我们在实际项目中应该综合各个不同维度做考量。...各位亲，这里建议将核心主链路拆分，有以下几个目的: 1)异常容错为主链路建立层次化的降级策略(多级降级) ，以及合理的熔断策略，这部分我们将在Hystrix服务容错阶段的课程中详细解释 2)调配资源主链路通常来讲都是高频场景...领域拆分的例子就太多了，我们做微服务规划的时候要确保各个领域之间有清晰的界限，比如商品服务，和订单服务，尽管他们之间有交集(都围绕商品主数据)但是毕竟是服务于不同领域(商品域和订单域)，所以我们要将两者拆分成独立的服务

2371 0

聊聊微服务拆分原则之 AKF

这儿引入一个概念,微服务设计原则之一——AKF原则微服务拆分原则之AKF 首先来看单节点的单点故障这个问题,既然单节点容易挂,那么就可以进行复制,一变多,这儿设计到三个概念,主从、主主、主备,也是三种方式...,简单来说,主主相当于多台服务器同时对外提供读写: 主从,主机可以读写,但是一般只对外提供写,从机对外提供读: 主备,主机提供读写,备机不对外提供服务,当主机挂了的时候,备机通过选举产生主机对外提供服务...Y轴拆分这时候又有新的问题,例如一台服务器中,可能某些功能被频繁访问,涉及到的数据频繁读写,其他数据基本不怎么访问,这时候可以将这部分数据独立出来,也就是根据功能、业务继续拆分服务器,这种拆解就是AFK...中的Y轴拆分特点是Y轴纵向来看不同的Redis负责的功能是不同的,也就是所包含的数据也是不同的,另外仅仅扩展出一个Y轴上的业务服务器,又可能会存在单点问题,所以可以结合AFK的X轴拆分原则,继续对刚拆分的...Z轴拆分在上面的AFK原则X-Y拆分之后,对服务器显示做了主从主备复制,然后做了业务拆分,不同的Redis负责不同的业务请求,这时候还会有一个新的问题,例如对于Y轴上一个Redis,它负责某一样业务,

3273 0

一起玩转微服务（8）——服务拆分原则

服务拆分拆分粒度不应该过分追求细粒度，要考虑适中不能过大或过小。按照单一职责原则和康威定律，在业务域、团队还有技术上平衡粒度。拆分后的代码应该是易控制，易维护的，业务职责也是明确单一的。...•X 轴：水平复制，即在负载均衡服务器后增加多个web服务器。•Y 轴：功能分解，将不同职能的模块分成不同的服务。...下面看一下AKF的拆分实践：拆分应用 •X轴：从单体系统或服务，水平克隆出许多系统，通过负载均衡平均分配请求。...•Y轴：面向服务分割，基于功能或者服务分割，例如电商网站可以将登陆、搜索、下单等服务进行Y轴的拆分，每一组服务再进行X轴的扩展。...对于服务的拆分，要使用迭代演进的方式，不能一次性完成所有的服务的拆分，需要确保团队可接受，粒度适中，同时需要优先考虑API的版本兼容性。不能够单纯以代码量来对服务拆分的成果进行评估。

1K2 0

微服务拆分的一些基本原则

单一职责原则案例以一个简单的电商系统为例，可以拆分为用户服务、商品服务、订单服务、物流服务等微服务，每个微服务只负责单一的业务领域。...涉及用户身份信息的修改，只需要变更用户服务，其他服务不受影响。实现单一职责原则的挑战与应对在微服务架构中，实现单一职责原则，其实最大的挑战职责边界不够清晰。...服务自治原则什么是服务自治原则微服务架构的服务自治原则（Service Autonomy）是指每个微服务都应该具备高度自治的能力，即每个服务要能做到独立开发、独立测试、独立构建、独立部署，独立运行。...服务自治原则是微服务架构中的一条基本原则，它有利于提高整个系统的可靠性和弹性，并能够更快速地响应业务需求和变化。...分层单向依赖原则什么是分层单向依赖原则在更为复杂的业务中，微服务的水平拆分已经无法满足微服务治理的需求。针对不同的功能定位，可以做纵向的分层。

4583 0

微服务 - 拆分微服务的问题和拆分方法

拆分微服务遇到的问题微服务我就不说了，在这里写写那些设计的要素和一定能遇到的坑。...2.服务数量太多，团队效率急剧下降，这里的误区是微字就意味着拆分的很细。3.没有自动化支撑，无法快读交付，现在极客时间里有GitOps，可以看这个，写的很好。...拆分微服务方法梳理从网上梳理了一些拆分微服务的方法论，希望对你有一些参考的价值：1.纵向拆分和横向拆分从业务维度进行拆分，标准是按照业务的关联程度来决定，关联比较密切的业务适合拆分成一个微服务，而功能相对比较独立的业务适合拆分为一个微服务...拆分原则3个火枪手原则：一个微服务由三个人开发，在进行微服务架构时，根据团队规模来划分数量也是合理的。...AFK拆分原则：X轴，水平复制，多加载几个应用实例，以集群加负载均衡的模式进行拆分Y轴，微服务经常采用的按业务逻辑划分Z轴，按照数据进行划分康威定律第一定律：组织沟通方式会通过系统设计表达出来，人月神话中总结出了随着人员的增加沟通成本呈指数增长的规律

1K7 0

微前端拆分实践

当然此时的业务还在发展，我们可以采取两种策略：一种是以拆分任务为高优先级，新的业务开发基于新的架构一种是先在旧的架构上持续开发，在拆分的过程中由负责拆分的同学将业务和技术一起迁移过去拆分原则我们在拆分微前端的时候一定是带有某种目的的...，有可能是想对技术栈进行渐进式升级，也有可能像我们一样想提升各个独立团队的自治力，在不同的目的下我们可能会秉持不同的原则，这也是另一个为什么微前端的拆分没办法简单抄作业的原因。...在这样的大前提下，我们可以按照业务为主模块为辅的方式指导拆分，基于此，我们定义了一些拆分时候的原则：保证业务独立，一条业务线应该由一个独立的app来支撑，使得该业务团队拥有这个app的完全控制权跨业务的页面不应该各个业务各自持有...巧了么不是，一开始我们就是按照后端 DDD 的方式来指导拆分的，然后就发生了这些问题，至少在我们的实践过程中，微服务的拆分方式不能照搬到前端来。 CSS 冲突问题这是我们遇到的另一个比较严重的问题。...引用 [1] single-spa [2] 迭代开发中的微服务拆分 [3] 微前端——前端开发新体验 [4] systemjs

1.3K0 0

微服务：如何拆分服务？

在微服务的落地中，第一步就需要进行微服务的拆分，服务的拆分很困难也很重要，本文就讲讲怎么进行服务的拆分。...技术发展到现在，还没有一个具体的，设计完善的标准方法来完成服务的拆分，服务的拆分是一门技术更是一门艺术。...对于服务的拆分，有两种情况： 1、从零开始开发新的产品，采用微服务架构，进行服务拆分； 2、将现有的单体架构的产品重构成微服务架构，进行服务拆分。...，整体还是在一个大的工程中，如下图：服务的拆分的一个最大的作用就是解耦，但并不是说一定要拆开才是解耦，在一个工程中，合理地使用面向对象的一些原则，比如依赖倒置、接口隔离等，也能做到解耦。...所以在拆分服务时要遵循两个原则： 1、通用功能，使用共享库，比如工具类，提取成 NuGet 包或者 Maven 包，在服务中进行引用； 2、业务相关的公共部分，使用单独的服务，提供 API 的方式供其他服务调用

1.2K1 1

遗留系统的服务拆分

这次拆分的目标是：将 A 业务的代码和数据库表从原有代码和数据库中拆分出来，形成独立的 A 服务及其数据库，实现 A 业务的代码独立、数据独立、部署独立。...图2 拆分目标总体策略这次服务拆分的策略归纳起来有三条： 1. 先代码拆分、后数据拆分代码和数据是服务拆分的两个重要物理实体。...结合我们以页面请求为单位进行拆分的方式，我们引入 feature toggle 作为切换新旧系统的开关，控制前端发来的请求是发送给原有系统还是发送给拆分出来的服务。...既然将回滚作为快速恢复功能的手段，那引入了一项开发约定：在拆分过程中，只允许修改新服务的代码，不允许修改原有系统的代码。...使用 Code Owner 保持新旧代码的一致在拆分过程中，如果有新需求涉及 A 业务的变更，则原有系统和新服务中的代码都需要同步修改，否则就会出现二者的功能不一致：如果只修改了原有系统而未修改新服务

3552 0

服务拆分之基础设施拆分

服务拆分之基础设施拆分 Infrastructure unbundling of services 背景: 因历史原因, 前期多个服务共用一个rds实例和一个redis实例, 在实际使用中经常会因某一个服务异常导致...rds或redis负载异常，进而影响其他服务造成雪崩。...故进行基础资源拆分来隔离风险。...本次拆分基于AWS平台 The split is based on AWS 创建原实例的只读副本实例 Create a read-only copy instance of the original instance...0损失，因进行了k8s pod 副本数调整，会对对拆分的服务根据实际情况会有部分时间不可用，建议在服务访问量低时进行此操作 This split can ensure zero data loss.

3.4K7 2

JAVA单服务应用拆分成多个服务的实践(1)--拆分的设计思想

最近跟朋友在沟通,问我私下作的开发平台支不支持拆分成多个微服务,让可以支持水平扩展. 我回去细想了一下,确实,现在做项目,如果不搞成多个微服务,都不好意思说,我是搞IT的....拆分目标: 支持ALL in One, 即还是可以单体应用部署,这样在小企业可以快速实施,因为小企业对性能要求不高支持多个应用服务,各服务的相互独立,服务之间的通讯使用dubbo,这样降低耦合,可以快速持水平扩展...,各个服务如有需要,从该服务中取该功能配置的数据该数据过滤的功能请参考文章通用数据级别权限的框架设计与实现附件上传其实附件上传我一直很犹豫,是做为系统组件,还是微服务.理论上,附件承载了各个应用的业务附件数据...组织管理这个微服务化,肯定没异义,对外输出组织的相关接口. 权限管理这里说的权限管理指的是系统资源及角色的管理.这个才需要做微服务化....但定时任务的触发,我考虑了很久,让各个系统自己定时触发,还是做成一个微服务,如果做成一个微服务,触及到定时任务调用多个微服务,如何去寻找对应的服务呢.

1.5K3 0

论微服务拆分

微服务拆分的起点使用微服务架构模式的思想对目标系统进行拆分之前，我们需要先明白服务拆分起点和终点，以及需要考虑的因素与坚持的原则。...---- 服务拆分分析如果一个系统拥有买家端和卖家端，我们可以根据这一点拆分成两个服务。也可以根据业务功能进行拆分，例如可以拆分为商品服务、订单服务、用户服务等，这样拆分的粒度就更细一些。...那么如何拆 “功能” 呢，可以参考以下几点：遵循单一职责、松耦合、高内聚原则关注点分离按职责按通用性按粒度级别如何拆 “数据” ：每个微服务都有单独的数据存储依据服务特点选择不同结构的数据库类型...在微服务架构中，每个服务一般都会拥有各自的数据源，服务和数据的关系如下：先考虑拆分业务功能，在考虑拆分业务对应的数据无状态服务，所谓状态就是只一个数据需要被多个服务共享才能完成一个请求，那么这个数据就可以被称为状态...而依赖这个状态数据的服务被称为有状态服务，反之称为无状态服务 ? 我们来通过一张图片，直观的看一下，服务拆分的前后对比： ?

3504 0

微服务的灾难(3) -- 拆分

在之前写事故驱动开发的时候，提到过，在企业中的项目进行开发时，只要是自己方便，一个人可以用拆分和收敛同时作为自己的标准。所以大家都是双标狗。...所以在拆分阶段，就没有什么硬性的标准了，每个公司可能风格都有差别，并且都可以阐述出自己的条条以支持自己的架构是“正确”的。显然，这件事情没有绝对正确的解法。无论哪种拆分方式，都会遇到业务边界的问题。...除去人的问题，业务部门的大多数一线领导是需要有业务上的业绩的。这种业绩怎么来？一般都是揽各种各样的活儿，能揽多少就揽多少。从设计原则上来讲，逻辑上相同或者类似的代码应该放在一个地方来实现。...即使 Domain Driven Design 的观点讲述了再多的上下文划分技巧，你在实际工作中会发现没有多少人把这些思想、原则当回事，一线 leader 在乎的就是揽活儿而已。...但演化到微服务的时代，原来很简单的重构就没那么简单了。

4321 0

服务拆分的几种处理思路

场景说明目标是需要拆分出内部服务 Y 为独立的系统，且暂时不改变系统 A 的被依赖关系，拆分前的情况如下图。...更具体的说，接口层的业务接口 1 中包含业务逻辑，于是会产生对内部服务 Y 的两个及以上接口的调用。处理思路那么你会遇到以下几种情况需要处理。...针对 case2 的 HTTP 接口逻辑也有两种处理方式：左图：同样，基于内部服务 Y 接口定义，迁移服务层逻辑到系统 B ，实现基于 BizDto 定义的 rpc 接口，系统 A 在接口层保留业务逻辑...针对 case 3 的内部服务调用：对于内部服务调用，基于内部服务 Y 接口定义，迁移服务层逻辑到系统 B ，实现基于 BizDto 定义的 rpc 接口，系统 A 只需要增加 BizDto 到...更优解如果我们要拆分内部服务 Y，从上游的依赖来看，有系统 A 和手机客户端的依赖关系（通过虚线表示）。

4913 0

如何拆分微服务

以我们的之前公司项目枕聊直播间送礼为例子：用户A对用户B送礼物：两者判定是否关注关系，如果没关注，直接建立关注关系、添加游戏好友；用户A随机中奖金币、元宝（货币）、增加富豪值，如果中了大奖，还需要发送全服消息...用户B增加魅力值用户A、用户B更新当日、周、月富豪榜、魅力榜的排名用户B礼物墙要展示收到的礼物实际业务比我上面描述更加复杂。...上述案例：我们直接简单拆分为：好友服务中奖翻倍服务排行榜服务魅力、富豪积分服务礼物墙服务全国消息服务上述服务都暴露接口，供我们实际业务使用。...子服务之间也可以相互调用：中奖了需要发送全国消息服务，那就是中奖翻倍服务调用全国消息服务。实际微服务拆分以及远程调用开发过程中：没必要完全拆分。...特殊说明：以上文章，均是我实际操作，写出来的笔记资料，不会盗用别人文章！烦请各位，请勿直接盗用！转载记得标注来源！

7101 0

如何避免单点风险：基于实践经验分享服务拆分原则的一些思考

因此，服务拆分不仅是为了简化系统，也有助于让系统更好地适应未来的变化。微服务拆分的原则：化大而复杂为小而简单。...进行服务化拆分，把一个大而复杂的问题化解为多个小而简单的问题，服务之间通过契约来约定依赖，做到服务独立发布和演进。微服务到底有多微，是个仁者见仁，智者见智的问题，最重要的是团队觉得是合适的。...但注意，要达成“团队觉得合适”的结论，至少还应该遵循以下两个基本前提：业务独立性首先，应该保证微服务是具有业务独立性的单元，并不能只是为了微而微。关于如何判断业务的独立性，也有不同的考量。...那么，以“三个火枪手”为原则的微服务拆分粒度，即一个微服务三个人负责开发。...具体拆分的时候，核心服务可以是一个，也可以是多个，只要最终的服务数据满足“三个火枪手”的原则就可以。

640 0

服务设计原则

标准化服务合约 1.1 服务合约建立了与服务交互有关的术语提供了技术限制和需求，及服务的拥有者希望对外公布的所有语义信息 image.png 1.2 标准化服务合约使用形式化或者标准化的合约服务功能描述的标准化...策略的模块化和集中化结构化标准其他的设计原则也会直接影响到合约的定位、设计以及最终的使用 2.3 合约与服务设计数据表示标准化和转换的避免在对服务记性集成时，统一的数据结构减少转换环节...服务松散耦合 2.1 服务耦合（服务内及消费者依赖）关注服务耦合在哪里发生关注一个服务组合中的各部分之间以及服务内部的各部分之间以及服务内部的各部分之间应该耦合到什么程度 2.2 服务松散耦合原则...，从而保障服务在合约的前提下进行演化的能力服务抽象原则就是为了获得信息隐藏的正确平衡点 3.1 服务抽象原则服务合约中发布的信息越多，随后的“消费者-合约”耦合就会越深向负责设计服务消费程序的人呈现的信息越多...在使用策略时，可能导致暴露服务底层的逻辑、行为和参数选择的细节其他的面向服务原则（如服务松散耦合和服务自治）也提倡在服务合约中减少约束 3.6 服务抽象与服务模型实体服务与应用服务抽象程度往往和所封装的定制逻辑

7171 0

关于游戏服务器的服务拆分

在游戏服务器中，我们做服务拆分，大部分情况下都是为了可伸缩，而不是为了高可用（这里暂不考虑那些使用WEB模式实现游戏服务器的思路。...在服务拆分过程中，我们往往需要关注服务间的数据依赖关系、服务的内聚性、服务间的交互频率、每个客户端请求所经过的链路长度等指标。...同时，遵循“如无必要，勿增实体”原则，服务的拆分应该尽可能的少，这不但会减少链路长度，同时还会降低整个分布式系统出现故障的概率。这是因为，每个服务都是单点。...如果我们在拆分服务时，服务的内聚性不够好（比如将联盟和国家数据拆分成“联盟服务”和“国家服务”。...我们就需要考虑，违反“服务内聚”原则将国家数据，挪到“城池服务”中，即使这会使“城池服务”和“联盟服务”变成循环引用。

8531 0

点击加载更多

扫码

添加站长进交流群

领取专属 10元无门槛券

手把手带您无忧上云

扫码加入开发者社群

相关资讯

热门标签

活动推荐

运营活动

活动名称

广告关闭