怎样在SOA中避免数据和架构的高耦合
极客时间编辑部
讲述：初明明大小：3.98M时长：04:21
你好，欢迎收听极客视点。
不知你有没有遇到过这样的情况，有的公司转向面向服务架构也就是 SOA，最后以失败告终又迁移回单体架构。当然，尝试新架构没什么错，SOA 也并不适合所有公司。如果不适合，那就坚持使用单体架构，如果适合，那就要用对 SOA。有些公司会在 SOA 中使用单体系统的开发实践，这样会带来很多风险。
想要在 SOA 世界中取得成功，就要避免数据和架构的高度耦合，这点很重要。每一个服务都应该建立在深思熟虑的抽象基础之上。在某种程度上，服务应该是独立的，理想情况下，它们不需要知道其他服务的存在。
而在以下这些情况中，很容易创建出高度耦合的服务：
为了临时紧急用例，而构建了临时的服务；
抽象的成本可能很高。对于企业来说，耦合服务是阻力最小的一条路径；
有些产品的数据模型是中心化的，如果由数据模型来决定抽象的定义，那么服务就会存在某种程度的耦合。
如果不注意，你可能会得到一个高度耦合的服务生态系统。这会是分布式单体的征兆，开发单体的痛苦一点都不会少，面向服务的好处却一点都不会有。此外，高度耦合的服务通常会让你越陷越深。换句话说，如果不解决这些问题，随着服务生态系统的增长，情况会变得更糟。
当数据高度耦合时，你需要使用同步 API 和异步任务来保持数据同步。这些同步过程也可能以 Saga 的形式出现。但不管怎样，你不得不做这些事情：
在基础设施上大力投入，并进行大量的测试，以确保数据正确同步；
培训开发人员，这样他们就不会意外地做出一些会导致数据同步故障的变更；
在多个服务之间同步足够多的数据之后，开发人员肯定会犯错，而且可能是灾难性的错误；
在可见性和异常检测方面做很多工作，确保在同步过程出现中断时能够收到警报。当出现故障时（很可能会出现），你不得不去诊断问题并解决它们。根据系统要求，这两种方法的成本都非常高。
但是，如果服务生态系统的数据耦合程度很低或者没有耦合，就可以避免这些麻烦。
当你发现自己正处在这样的境地，你该怎么办？当然，并不存在放之四海而皆准的解决方案，这里只是提供一些建议。
首先，如果服务很稳定，并且没有人在修改它，那就不要管它了。你不会想成为那个打破这种“宁静”的人。
如果当前的架构出了问题，那么你要做的第一件事就是分析当前系统的维护成本、修改系统的成本以及新系统所节省的成本之间存在怎样的关系。做好这件事情并不容易，但如果去做了，你会惊讶地发现使用一些指标比如交付时间、Bug 个数或宕机次数、受影响的用户数量等会给你带来些什么。在进行了彻底分析之后，你会发现迁移可能是没有必要的。但是，如果分析之后确定需要进行迁移，那么就可以使用分析结果来获得管理层的支持。
另外，在很多情况下，修改已有的系统是不现实的。迁移会影响企业的运营，成本可能很高。不过没关系，只要你确保系统的设计是正确的，那就可以继续这样下去。
除了要避免数据和架构的高度耦合以外，还有一件事非常关键，那就是不要把单体系统的开发习惯带到 SOA 的世界。如何改变单体系统的开发习惯而适应 SOA 的开发习惯呢？且看下文分享，欢迎持续关注。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论