微服务架构整体思路

常见场景实施建议:
| 拆分方式 |
基础设施要求 |
服务拆分落地方式 |
|
从0开始构建业务系统 |
按业务拆分微服务 |
搭建完善基础设施,按照微服务基 础设施优先级逐步落地 |
一步到位 |
单体架构微服务化 |
按业务拆分微服务, 先从非核心业务开始拆分 |
搭建完善基础设施,按照微服务基 础设施优先级逐步落地 |
逐步落地 |
粗粒度服务微服务化 |
按质量拆分微服务 |
重用已有基础设施 |
逐步落地 |
局部系统优化 |
按质量拆分微服务 |
重用已有基础设施 |
逐步落地 |
2.如何按业务拆分微服务
实际项目中的业务边界划分(1/2)

实际项目中的业务边界划分(2/2)
| 做法 |
风险 |
技巧 |
|
业务专家 |
以业务专家意见为准 |
业务专家太水 |
从行业挖人才 |
粗分 + 演进 |
先按照某个维度粗粒度划分,后面 随着业务发展而演进,划分为细粒 度边界 |
太粗导致频繁演进 |
微服务数量 = 服务端开发人数 /3 |
|
参考业界实现 |
直接参考业界类似业务的划分方式 |
照搬导致水土不服 |
微服务数量 = 服务端开发人数 /3
|
实际项目中的服务拆分

服务拆分技巧

三个火枪手案例(微服务数量 = 服务端开发人数 /3)

一对一服务映射

多对一服务映射

一对多服务拆分技巧 - 业务流程拆分

3.如何按质量属性拆分微服务
按性能拆分
方法:根据运维系统统计请求量排名前3的业务,将流量最大的业务以及强关联的业务拆分出来。
目的:降低业务互相影响程度,拆分后优化流量大的业务,提升性能降低成本。
按业务重要程度拆分
方法:将重要程度高的业务拆分出来,注意重要程度高不一定是流量大的。
目的:降低业务互相影响程度,拆分后提升重要程度高的业务的可用性。
案例:儿童电话手表的电话功能。平时的电话都是不怎么用的,但是只要打电话都是非常紧急的事情,都是家长在找孩子,所以虽然使用频率不高,但是只要一使用都很紧急。
按可用性拆分
方法:将经常出问题的业务拆分出来。
目的:降低业务互相影响程度,拆分后有针对性的提升问题多的业务。
按稳定性拆分
方法:将稳定的业务拆分出来。
目的:降低业务互相影响程度,拆分后有利于不断变化的业务快速迭代。
思维导图

原文作者:二进制跳动;如有侵权,请联系管理员删除。