本文将体系化总结这几天撰写的解耦系列文章，可收藏，可转发。数据库
1、IP产生的耦合与解耦
文章：《小小的IP，大大的耦合》
内容：缓存
- 什么是架构耦合
- 发现系统架构耦合方法论
- IP耦合，典型场景
- IP耦合，解耦方案
2、公共库产生的耦合与解耦
文章：《小小的公共库，大大的耦合》
内容：架构
3、数据库产生的耦合与解耦
文章：《小小的数据库，大大的耦合》
内容：ide
- 多个业务由于数据库(例如join)耦合，典型场景
- 数据库耦合，解耦方案
4、服务化产生的耦合与解耦
文章：《服务化了，耦合却更加严重？》
内容：中间件
- 服务化是解耦方法，为什么不完全的服务化，耦合会更加严重
- 不完全服务化，典型场景
- 不完全服务化，解耦方案
5、MQ，互联网架构解耦神器
文章：《MQ，互联网架构解耦神器》
内容：it
- 该用MQ，却用了RPC，致使耦合，典型场景
- 使用MQ，解耦方案
- MQ，逻辑解耦，物理解耦
6、配置中心，互联网架构解耦利器
文章：《配置中心，互联网架构解耦利器》
内容：系统架构
- 扩容缩容，致使耦合，典型场景
- 使用配置中心，解耦方案
- 配置中心，逻辑就，物理不解耦
近期很多人说“最近的文章太水”，还挺沮丧的：class
- 一个，个人时间碎片化，你们的时间也碎片化，把知识点拆细了
- 二个，每一个人的背景，工做年限，行业领域，实战经验不同，把架构理论抽象出来，搭配具体的案例，写成容易理解，可实施落地的技术文字，对经验丰富的资深架构师，可能确实看起来“太容易”，可写起来“不简单”，没有写做过侠客们，能够写几篇试试，就明白了
- 三个，说“不成体系”的朋友，我只想说，我心中是有知识体系的，我也会按期成体系的汇总，就像这一篇
近期会写一些常见的“有分歧”的架构方案，以及我我的的观点，例如：配置
- 引起思考：服务读写分离，是否可行？
- 个人观点：服务读写分离架构，毫不推荐
- 引起思考：经过“缓存”传递数据，是否可行？
- 个人观点：下一篇
有时候，让人觉的累的，并非天天写到1-2点钟，近期可能休息一段时间吧。互联网
知其然，知其因此然。
不必定高深，但必定有收获，可收藏，可转发。
上一篇总结：数据库中间件技术系列汇总