22｜微服务拆分（二）：三招搞定数据库表解耦
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文介绍了微服务拆分过程中解决数据库表解耦的三种有效方法，分别是通过API调用取代连表查询、建立单独的查询数据库实现读写分离、以及冗余数据到核保服务中。这些方法为解决数据库表解耦提供了实用的技术指导。文章还提到了快照数据、业务数据和参考数据的冗余方式，以及它们的优缺点和应用场景。此外，还提到了在处理INSERT、UPDATE和DELETE的SQL时可以用API调用来取代。总的来说，本文为读者提供了解决微服务拆分过程中数据库表解耦问题的有效方法和实用技术指导。
《遗留系统现代化实战》，新⼈⾸单¥59
全部留言(2)
- 最新
- 精选
- Williamleelol姚老师你好： 咱们本个专栏主要讲遗留系统现代化，传统意义上基本都是一个大泥球式的单体服务开始。最近我接手却正好相反，服务分的很碎很细，并且有很多坏味道比如一个需求需要修改很多服务，典型的分布式单体。在众多问题中我有一点没想清楚，因为用到了非常多的faas，每个faas有薄（比如只做消息体转换）有厚（做业务流程处理）。个人风格是非常不建议这么做的因为会导致认知负载太高，几十个faas最终没人说的全，不知道一个流程是从哪里开始的，有问题排查成本也升高。但是话说回来faas真正解决的问题是什么呢？强调function的话最终我想不管如何管理也一定会变得数量特别多直到难以管理，最佳实践是什么样的？ 辛苦～
作者回复: 你好，这是一个非常好的问题，为了更准确地回答，我特意咨询了一下我的前同事，现腾讯云的Serverless专家架构师杨政权，以下是他的回答： FaaS解决的问题：FaaS平台的特点是更精细的资源分配、更精确的计费粒度、低运维成本以及弹性伸缩的能力，在我来FaaS主要解决两个问题： 1）企业的IT投资分配问题：FaaS属于Serverless的一个分支，对于大部分企业来说，尤其是成长期的SMB企业，运维一个K8S集群、虚拟机集群或者IDC并不会带来核心竞争力的提升，通过Serverless提供的低运维成本的方案，降低企业在基础运维、资源调度等方面的成本，从而把更多的IT投资分配到那些核心的业务能力提升上 2）传统容量预测的矛盾问题：资源准备的太多导致利用率多，资源准备的太少又可能会影响线上业务，FaaS这种跟随请求量进行主动扩容的模式让「准备的资源」和「实际所需的资源」尽量贴合；所以更适合的通常也是矛盾最突出的场景，那些业务有波峰波谷、量级难以预测，同时业务又对于实时性有较高要求的业务场景，如电商大促、批量的音视频处理、服务端渲染SSR 等 FaaS的粒度：一个好的FaaS应用设计应该可以充分地利用平台所提供的优势 1）通过业务的逻辑拆分分离特定的业务，代码体积、内存消耗和应用初始化时间降低，从而获得更快速的弹性扩容，提升该业务场景的吞吐量；和微服务类似，拆分之后在编程语言和技术栈的选择上也会更加灵活。 2）但是正如您所说，过度的拆分的确会带来新的问题，2019年Thoughtworks技术雷达就提出「Lambda pinball」的概念，并放到了On Hold的位置，过度的FaaS拆分很容易陷入构建分布式单体的陷阱中，还会导致冷启动过多的问题，降低FaaS实例的复用率。在拆分的时候仍然需要关注业务逻辑的内聚性，让每一个FaaS包含一个相对完整的应用场景，在逻辑边界的基础上进行物理边界的优化，通过Faas的实际运行消耗，如冷启动速度、内存闲置情况、实例并发数等指标进行优化。 3）目前FaaS的应用设计还缺少成熟的方法论支持，最佳的方式还是通过实际的运行结果，结合业务场景的要求进行实际压测，然后观察性能、成本和平台指标进行针对性的优化。
2022-05-317 
peter文中以图片表示的复杂查询令人吃惊，没见过这么长的查询。 Q1 这么长的查询，一般需要多长时间？ 比如100ms？ Q2 除了时间，从实际应用的角度，这种复杂查询还有哪些问题？作者回复: 其实时间并不是主要问题，它既然能长成这个样子，业务方也一定是可以忍受的。最主要的问题是：1. 无法维护，2. 数据所有权不清楚
2022-05-311
