信长笔记2.0

Appearance

微服务架构 ​

参考: https://www.cnblogs.com/liconglong/p/16263648.html

微服务架构六大陷阱 ​

1745226286908

微服务架构四大挑战 ​

1745226293258

分布式事务 ​

详细参考: https://www.cnblogs.com/liconglong/p/16277356.html#_label5

  • 本地事务消息
    • 每个服务都要有消息表

1745226299340

1745226327083

  • 消息队列事务消息
    • 得看架构是否用RocketMQ

1745226333800

1745226339686

  • TCC
    • 每个功能要写try, confirm, cancel三个接口

1745226362196

1745226368047

  • SAGA

1745226374550

全局幂等 ​

  • 分布式数据只能通过消息来实现最终一致性，而消息可能会丢失，因此需要重试，重试就需要保证幂等。
  • 在保证幂等时，有可能不同服务发出相同的数据，在业务上可能是两条数据，这种也是需要做幂等处理的，因此，一般会使用全局幂等，保证每个幂等操作都是全局唯一的。
  • 全局幂等的处理思路有：全局唯一 ID 和 状态机，全局唯一 ID 一般用于增删操作，而状态机一般用于更新操作。

方式一

  • 下图第四步要是处理业务成功, 更新消息状态失败该怎么处理? 如果有使用数据库, 则利用数据库的事务来保证, 如果没有, 则可以使用定时任务扫表来补偿更正消息状态

1745226381100

方式二

  • 方式一的简化, 当业务处理很快时, 可以直接保存处理完成的消息

1745226386393

接口兼容 ​

接口兼容是指某个微服务的某些接口升级，依赖这些接口的微服务不一定能够全部同时升级。解决方案：

（1）接口多版本，直接拷贝一份旧接口代码，在旧接口代码上修改，接口 URL 加上 v1/v2 这种标识；

（2）接口逻辑兼容，同一份接口代码，兼容新旧逻辑，容易互相影响，且旧接口下线时又要修改代码（不推荐）。

接口循环调用 ​

某次业务处理过程中，A调用B，B又过来调用A，A的处理又进入了之前的处理逻辑，导致循环调用，整个业务进入死循环。例如用户登录服务调用风控服务进行安全检查；风控服务又来调用登录服务获取用户登录地址信息；获取登录地信息的接口又依赖了风控服务进行安全检查。这就是因为服务拆分，不同的微服务间调用导致的问题。

这种几乎没有好的解决方案，运气好靠测试发现，运气不好靠上线发现。

微服务基础设施选型 ​

微服务基础设施架构 ​

  • 优先级: 按下图的1,2,3,4先后落地
  • 一般都是1-4个开发语言，这是因为对于基础设施建设来说，对于不同的语言可能都要搭建一套基础设施，例如自动化测试、自动化部署这种与语言强相关的基础设施

1745226395617

微服务框架模式 ​

1745226401713

微服务拆分技巧 ​

微服务整体架构思路 ​

微服务落地主要从服务拆分方式、基础设施要求、落地方式三个方面。 1745226407925

如何按业务拆分微服务 ​

实际项目中的业务边界划分，一般看有没有业务专家，有的话，就让业务专家来划分边界，如果没有，再看是否是全新的业务，如果不是，可以参考业界的现有实现，如果是全新业务，可以先粗粒度的划分边界再逐步演进。 17452264140581745226419903

  • 服务拆分技巧 - 三个火枪手原则
  • 定义：平均3个开发人员负责一个微服务。
  • 剖析：1. 为什么不是1个？因为没有备份，且一个人思维有局限。2. 为什么不是2个？因为异常情况下剩余1个，压力会很大；2个人负责维护一个微服务，微服务复杂度偏低。3. 为什么不是4个或者5个？如果4个或4个以上，每个人不一定能掌握单个服务所有细节。
  • 技巧：1. 微服务数量 = 服务端开发人数 /3 ；2. 3 = 1 +2，1个有经验的(P7/P6+)，2个普通的(P5/P6)；3. 处于维护期的服务，维护人员为2人。

如何按质量属性拆分微服务 ​

按性能拆分：

  • 方法：根据运维系统统计请求量排名前3的业务，将流量最大的业务以及强关联的业务拆分出来。
  • 目的：降低业务互相影响程度，拆分后优化流量大的业务，提升性能降低成本

按业务重要程度拆分：

  • 方法：将重要程度高的业务拆分出来，注意重要程度高不一定是流量大的。
  • 目的：降低业务互相影响程度，拆分后提升重要程度高的业务的可用性。
  • 案例：儿童电话手表的电话功能。

按可用性拆分：

  • 方法：将经常出问题的业务拆分出来。
  • 目的：降低业务互相影响程度，拆分后有针对性的提升问题多的业务。

按稳定性拆分：

  • 方法：将稳定的业务拆分出来。
  • 目的：降低业务互相影响程度，拆分后有利于不断变化的业务快速迭代。

中台深入剖析和实现技巧 ​

中台概念 ​

  • 共享架构模式 1745226429069

  • 理解中台概念 - 业务中台（针对相似业务）

业务中台总的来说是将企业内多个相似业务的通用业务能力沉淀到平台，以减少重复建设，提升业务开发效率的一种架构模式。

  • 理解中台概念 - 数据中台（针对所有业务）

数据中台总的来说是将企业所有业务的数据沉淀到同一平台，支持业务间数据打通以及数据复用，提升企业运营效率的一种架构模式。

中台价值

  • 业务中台：相似业务的能力共享，避免大量重复开发，提升开发效率。

业务相似度越高，业务中台价值越大，建议相似度达到60%以上的多个业务共建中台，例如“快车+专车”，“淘宝+天猫+咸鱼”，”火山 + 抖音 + 西瓜“。

评估业务相似度，需要依赖业务专家，而不是一个单纯的技术工作。

强行将相似度低的业务塞进一个中台，不但不会提升开发效率，还会大大降低效率。

  • 数据中台：数据打通和复用，避免数据孤岛，提升运营效率。

使用数据中台的业务越多，数据中台价值越大。

数据中台的价值体现在：统一数据平台、跨业务的数据打通、跨业务的数据复用（挖掘）。

跨业务的数据复用：理想很丰满，现实比较骨感，受限于业务熟悉度和组织结构的相关约束。