重新理解事件和数据 -《微服务与事件驱动架构》读后感

liuwill

于 2024-07-31 10:52:46 发布

阅读量369

点赞数 7

分类专栏：开发技术读书笔记文章标签：架构微服务云原生

本文链接：https://blog.csdn.net/liuwill/article/details/140817064

版权

读书笔记同时被 2 个专栏收录

11 篇文章 0 订阅

订阅专栏

开发技术

5 篇文章 0 订阅

订阅专栏

理解事件驱动型微服务架构，需要重新思考数据是什么以及服务要如何访问和使用数据。

事件驱动的核心是把事件作为唯一的事实，为此就需要把全部操作的事件流持久化存储，下游服务消费事件，计算出应用业务逻辑当前的状态，服务自己维护的数据，只是状态的物化视图。通过Flink这样的流式计算框架，指定偏移量，幂等的下游服务，就可以重建所有状态。

微服务不是零成本的，微服务税是与实现微服务架构的工具和组建相关的成本总和，包括财务、人力和机会成本;包含了管理、部署、操作事件代理、CMS、监控和日志的开销。

业务的界限上下文，是拆分事件和微服务的标准，而不是技术边界和服务治理的需要。作者建议采用混合和渐进式的方式。

要从业务代码中解放事件流可以用查询、日志和中间表等方式，从底层数据存储中提取数据并创建事件流。当然这一切是以事件代理为核心的。

事件驱动中的编制器模式

刚知道SAGA的时候，觉得很高大上。但是如果回到计算机系统运行的基本原理，其实并没有什么神奇的力量在里面。

在事件驱动的语境下，这一类的分布式异步操作的顺序执行过程，被作者称之为编制模式。

我的理解是这样的。如果我们有一系列操作，是异步而且独立执行的，最后有一个业务逻辑的结果，又依赖所有操作的执行结果，那么毫无疑问，必须要有一个中间的协调者，也就是编制器，负责触发事件流或者发起请求，监控执行过程，并且确认结果。

编制器用自己的内存、支持事务或者锁机制的外部存储，就可以实现对整体执行过程的管理，通过状态持久化，还可以在异常发生时重新恢复现场。

对应的就会要求消费者或者执行器，能够对操作有幂等和回滚的支持，这样就可以作为原子操作，整体撤销。

如果不影响业务逻辑和产品交互，可以从存储中直接物理或者逻辑删除数据，重置状态。但是更符合现实世界的方式，可能是像会记记账一样，用冲销的方式来回滚，下单成功的订单加一个取消操作，就可以采用一致性的方式完成回滚撤销。

微服务和微服务团队

微服务可以根据自身需要存储和管理数据，并且能达到之前仅限于批处理大数据解决方案的规模。

微服务本身是微小且定制的，能在两周内实现，应该像是出自一个人。

作者提出了两种微服务团队的结构，一种是后端微服务，一种是微前端，我觉得应该叫做全栈微服务，但是这种拆分的边界，应该是组织的沟通结构，产品形态决定如何组织开发团队，不可能从技术角度去拆分，虽然服务治理需要通过度量发现瓶颈，然后拆分数据库、拆分计算资源，但是只有业务的边界才是决定系统演进方向最重要的决定性力量。

微服务的结构

就像凤凰架构这本书里说的，微服务带来的是整个组织和系统的反脆弱能力，微服务的确可以为架构带来健壮性，独立正交的上下线服务和裁剪扩展团队，降低复杂性，但是这种复杂性是架构和团队层面。

与代码如何组织是正交的，有清晰的结构设计、良好的约定和规范，并且能够坚定执行，同一个代码仓库，同样可以构建大型复杂的系统。

微服务每个代码服务独立代码库，最佳的场景，一定是业务之间正交非常少，而且没有非常复杂的聚合层的情况。

关于健壮性，从硬件领域的RAID磁盘阵列我们就知道，冗余带来健壮性，代价就是我们所知道的微服务税，要先交税才能享受微服务带来的反脆弱性。

冗余这个词，本身就充满矛盾，既可以是褒义词，带来健壮性；也可以是贬义词，带来重复和降低单位效率，取决于观察的角度。

说到代码拆分的冗余，我觉得至少对领域和界限上下文的业务建模，是不可消除的元信息。信息系统顾名思义就是对特定领域业务知识的数字化，业务架构，需要把业务逻辑转化成计算机可以理解的文本、代码，只有充分才能反映业务本身，这就是必不可少的工作量，无论如何，就是要把这些领域相关术语和关系，一个字一个字的打出来，写到代码里。

多一个系统需要领域知识，就要根据对业务的理解和需要，完成建模。有了元数据，才能编写代码然后运行。

事件驱动结构中的数据

在作者所推崇的事件驱动架构中，所有事件流只能有一个唯一的生产者这是非常重要的选择，表流二元性是创建状态的基础，事件都必须以不可变数据的方式存储，这样系统才能将事件流物化成当前的状态。

整本书看下来，是对数据存储的重新理解，非常不同于数据库为核心的系统的，共享数据库带来了迁移和查询的便利，不过任何共享必然都会带来耦合，不耦合就只能用冗余，只能根据项目和业务的实际情况来判断，适应当前情况才是最好的。

还有一点是关于Schema固然可以有代码生成器支持和自动检查，但是本身也带来了一定耦合，尤其是变化很快的地方，这也是需要权衡，schema本身只是活文档，纯文本是计算机可以运行人类也可以理解的，但是要在schema上加多少约束和扩展，是需要权衡取舍的，不然SOAP这样的重量级架构早就到处都是，微服务就不会是用微来修饰。