7个典型场景，学会互联网架构“解耦”

本文将体系化总结这几天撰写的解耦系列文章，可收藏，可转发。

一、IP产生的耦合与解耦

文章：《小小的IP，大大的耦合》

内容：

• 什么是架构耦合

• 发现系统架构耦合方法论

• IP耦合，典型场景

• IP耦合，解耦方案

二、公共库产生的耦合与解耦

文章：《小小的公共库，大大的耦合》

内容：

• 公共库耦合，典型场景

• 公共库耦合，解耦方案

三、数据库产生的耦合与解耦

文章：《小小的数据库，大大的耦合》

内容：

• 多个业务因为数据库(例如join)耦合，典型场景

• 数据库耦合，解耦方案

四、服务化产生的耦合与解耦

文章：《服务化了，耦合却更加严重？》

内容：

• 服务化是解耦方法，为何不彻底的服务化，耦合会更加严重

• 不彻底服务化，典型场景

• 不彻底服务化，解耦方案

五、MQ，互联网架构解耦神器

文章：《MQ，互联网架构解耦神器》

内容：

• 该用MQ，却用了RPC，导致耦合，典型场景

• 使用MQ，解耦方案

• MQ，逻辑解耦，物理解耦

六、配置中心，互联网架构解耦利器

文章：《配置中心，互联网架构解耦利器》

内容：

• 扩容缩容，导致耦合，典型场景

• 使用配置中心，解耦方案

• 配置中心，逻辑就，物理不解耦

近期不少人说“最近的文章太水”，还挺沮丧的：

• 一个，我的时间碎片化，大家的时间也碎片化，把知识点拆细了

• 二个，每个人的背景，工作年限，行业领域，实战经验不一样，把架构理论抽象出来，搭配具体的案例，写成容易理解，可实施落地的技术文字，对经验丰富的资深架构师，可能确实看起来“太容易”，可写起来“不简单”，没有写作过侠客们，可以写几篇试试，就明白了

• 三个，说“不成体系”的朋友，我只想说，我心中是有知识体系的，我也会定期成体系的汇总，就像这一篇

近期会写一些常见的“有分歧”的架构方案，以及我个人的观点，例如：

• 引发思考：服务读写分离，是否可行？
  

• 我的观点：服务读写分离架构，绝不推荐
  

• 引发思考：通过“缓存”传递数据，是否可行？

• 我的观点：下一篇

有时候，让人觉的累的，并不是每天写到1-2点钟，近期可能休息一段时间吧。

知其然，知其所以然。

不一定高深，但一定有收获，可收藏，可转发。

上一篇总结：

数据库中间件技术系列汇总