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

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

一、IP产生的耦合与解耦

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

内容：

什么是架构耦合

发现系统架构耦合方法论

IP耦合，典型场景

IP耦合，解耦方案

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

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

内容：

公共库耦合，典型场景

公共库耦合，解耦方案

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

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

内容：

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

数据库耦合，解耦方案

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

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

内容：

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

不彻底服务化，典型场景

不彻底服务化，解耦方案

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

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

内容：

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

使用MQ，解耦方案

MQ，逻辑解耦，物理解耦

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

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

内容：

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

使用配置中心，解耦方案

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

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

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

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

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

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

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

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

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

我的观点：下一篇

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

知其然，知其所以然。

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