7個典型場景，學會互聯網架構「解耦」

本文將體系化總結這幾天撰寫的解耦系列文章，可收藏，可轉發。

1、IP產生的耦合與解耦
文章：《小小的IP，大大的耦合》
內容：

• 什麼是架構耦合
• 發現系統架構耦合方法論
• IP耦合，典型場景
• IP耦合，解耦方案

2、公共庫產生的耦合與解耦

文章：《小小的公共庫，大大的耦合》
內容：

• 公共庫耦合，典型場景
• 公共庫耦合，解耦方案

3、數據庫產生的耦合與解耦

文章：《小小的數據庫，大大的耦合》
內容：

• 多個業務由於數據庫(例如join)耦合，典型場景
• 數據庫耦合，解耦方案

4、服務化產生的耦合與解耦

文章：《服務化了，耦合卻更加嚴重？》
內容：

• 服務化是解耦方法，爲什麼不完全的服務化，耦合會更加嚴重
• 不完全服務化，典型場景
• 不完全服務化，解耦方案

5、MQ，互聯網架構解耦神器

文章：《MQ，互聯網架構解耦神器》
內容：

• 該用MQ，卻用了RPC，致使耦合，典型場景
• 使用MQ，解耦方案
• MQ，邏輯解耦，物理解耦

6、配置中心，互聯網架構解耦利器

文章：《配置中心，互聯網架構解耦利器》
內容：

• 擴容縮容，致使耦合，典型場景
• 使用配置中心，解耦方案
• 配置中心，邏輯就，物理不解耦

近期很多人說「最近的文章太水」，還挺沮喪的：

• 一個，個人時間碎片化，你們的時間也碎片化，把知識點拆細了
• 二個，每一個人的背景，工做年限，行業領域，實戰經驗不同，把架構理論抽象出來，搭配具體的案例，寫成容易理解，可實施落地的技術文字，對經驗豐富的資深架構師，可能確實看起來「太容易」，可寫起來「不簡單」，沒有寫做過俠客們，能夠寫幾篇試試，就明白了
• 三個，說「不成體系」的朋友，我只想說，我心中是有知識體系的，我也會按期成體系的彙總，就像這一篇

近期會寫一些常見的「有分歧」的架構方案，以及我我的的觀點，例如：

• 引起思考：服務讀寫分離，是否可行？
• 個人觀點：服務讀寫分離架構，毫不推薦
• 引起思考：經過「緩存」傳遞數據，是否可行？
• 個人觀點：下一篇

有時候，讓人覺的累的，並非天天寫到1-2點鐘，近期可能休息一段時間吧。

知其然，知其因此然。
不必定高深，但必定有收穫，可收藏，可轉發。

上一篇總結：數據庫中間件技術系列彙總