高性能微服务架构设计模式@霞落满天

Posted 2022-06-21 21aspnet

高性能微服务架构设计模式

主讲：霞落满天

现在企业开发都是微服务架构，但是有很多问题，比如分布式定义，分布式的微服务怎么拆分，什么时候拆分，怎么做到高性能，中台怎么设计，读写分离模式难道仅仅是mysql做主从就够了么？分库分表怎么使用，缓存和数据库之间怎么保持一致性，领域模型中的CQRS模式又应该怎么结合自己公司的业务呢？面试过程老是被问题一些系统架构相关的问题，怎么面对新问题可以在面试中短短的时间征服面试官？针对这些问题我录制了一期学习视频。有任何学习问题可以给我留言

视频地址：https://edu.csdn.net/course/detail/27256/

 

课程大纲
开篇 高性能系统架构的分布式理论基础
模型 可无限扩展的AKF立方
问题 亿级QPS的电商网站遇到的问题
模式 CQRS模式进行架构设计
模式 事件溯源模式进行架构设计
结尾 新问题

课程收益
高性能：亿级QPS的电商网站怎么做到高性能？是不是用了分库分表就万事大吉了？如果还不行是不是扩容加机器就可以了？Kafka为什么可以做到那么高性能？怎么实现可以系统接近无限扩容等等。
开发效率：产品提出一个需求，往往改一发而动全身。怎么样既要做到高性能也要做到易维护易扩展？
技术选型：异步解耦，微服务拆分，领域驱动模型设计这些理论怎么用。
面试：突击押宝，短时间帮你把面试常见知识点提纲挈领。
听懂：只有精心设计的课程才能让人听懂。

分布式系统的定义和特征
缘起：首先只有先学习优秀的分布式架构自己才可以做出优秀分布式架构，第二不管多么炫的技术架构，后面的一些分布式思想和理论都是很多年前的，最少也是15年前的。
现状：关于分布式系统的定义其实现阶段也并没有得到普及，一些分布式的经典著作有定义，但是不统一。大家都在说分布式系统，但是很多人包括一些架构师并没有理解分布式，做系统架构并不是分布式的，如果访问量很小不会显现出问题，如果访问量很大就会暴露很大问题，这时候可能会用一些不太好的方案来解决问题，比如乱加机器，甚至有时候加机器也解决不了问题。
定义：分布式系统是其组件分布在联网的计算机上，组件之间通过传递消息进行通信和协调的系统。
特征：组件的并发性，缺乏全局时钟，组件故障的独立性。
关键技术：名字服务，间接通信，复制技术，分布式事务。

正交性设计：

定义：两条直线相交成直角，就是正交的。正交也就是两条直线互不依赖。如果一个系统的变化不影响另一个系统这些系统就是正交的。
直接应用正交性原则，构建的系统的质量可以得到很大提高，可以让你的系统易于设计、开发、测试及扩展上线。
高内聚：每个服务是功能独立单一的。系统与系统之间，服务与服务之间是独立互相独立，隔离的。
正交的好处：提高开发效率，降低风险。

 

举例Kafka为什么是分布式的
Kafka 是最流行的消息中间件，有别于RabbitMQ, RabbitMQ不是真正意义上的分布式系统，因为他没有做到分布式，他只是做了镜像。阿里巴巴开源的RocketMQ也是分布式的系统。
Kafka的消息通过Toplic（主题）进行分类，这就好比数据库的表，或者文件系统里的文件夹。 Toplic可以被分为若干个Partition(分区)，一个分区就是一个提交日志。消息以追加的方式写入分区。
分区可以并发读写，提高性能。数据在多节点之间复制提高可用性。

 

间接通信：对于分布式系统，间接的概念也越来越多地应用于通信范型。间接通信被定义为在分布式系统中实体通过中介者进行通信，没有发送者和接受者之间耦合，中介者的确切特性随方法的不同而不同。

空间解耦：发送者不知道也无需知道接收者，接收者也同样无需知道发送者，因为空间解耦使得系统开发者有很大的自由去处理改变：参与者可以被替换，更新，复制甚至迁移。

时间解耦：发送者和接收者可以有独立的生命周期，也就是说发送者和接收者不需要同时存在才可以通信，发送者可以随时进入离开。

tips：所有计算机问题，都可以通过引入一个新的间接层次来解决，那些已经有过多间接层次的问题除外。（1965年剑桥Titan项目）

 

分布式系统在电商微服务中台的表现
电商业务中台微服务拆分为商品中心(商品详情+商品列表)，购物车中心，订单中心，用户中心。
微服务镜像部署在不同的服务器上。
好处：高内聚，低耦合，易维护，易扩展。
问题：分布式事务，调用链复杂，一致性问题等…

 

标准CQRS模式
实现：标准CQRS由命令模型和查询模型组成，这是按照领域模型来设计的，命令模型实现新增，更新，删除操作，查询模型订阅命令端发布的事件并更新查询视图，最终视图是最新的，有时候需要添加新视图来支持不同的查询类型。
查询模型使用的数据库不限于MySQL也可以是ES，Redis，MongoDB等。

事件溯源模式简介
Event Sourcing Pattern代表事件溯源模式也有称为事件源模式。使用仅追加存储来记录描述在域中对数据执行的操作的完整系列事件，而不是仅存储当前状态，以便可以使用该存储来实现域对象。
通过避免同步数据模型和业务域的需求，该模式可以简化复杂域中的任务。提高性能，可伸缩性和响应能力；提供交易数据的一致性；并保持完整的审计追踪和历史记录，以支持采取补偿措施。

下面是课程的一些精彩截图：