1. 小小的IP，大大的耦合，你痛过吗？
如何解除IP耦合？
常见的方法是：使用内网域名替代内网IP，如果没有做这个优化，强烈的建议马上实施，将配置文件中的内网IP全部干掉，全部改为内网域名。
使用内网域名，就不需要上游配合重启了吗？
假设现在不用内网IP，改用内网域名了，一个服务或者数据库的IP变更，只需要一个地方更改，而不是所有上游更改：
-
运维修改内网DNS，将内网域名指向新的IP，如果是短连接调用，未来新的请求流量，自然会切到新的IP上；如果是长连接调用，新的长连接会连到新的IP上，但旧的长连接仍然连接的是旧IP
-
运维统一将旧IP上的连接切断，如无意外，服务或者数据库的连接池都有重连功能，重连后就会自动连到新IP上去
如此这般，只要运维配合就可以完成IP的迁移，对于所有上游的调用方不需要配合修改配置重启。
2. 小小的公共库，大大的耦合，你痛过吗？
如何解除公共库耦合？
方案一：代码拷贝一份
别嘲笑这个方案，谁敢说自己写代码的时候没这么干过？
我们都知道这不是一个好的方案，但不可否认，拷贝之后，代码各自演化，一个地方升级出错，只影响一方，拷贝方只要不动原有代码，至少是不会受影响的。
代码拷贝缺点很多，系统拆分时，万不得已不要使用这个方案。
方案二：垂直拆分，将公共库里业务个性化的代码拆到调用方去，不要放在公共库里
需要把业务个性的代码拆分到各个业务线自己的工程，自己的业务库里去，例如s1.jar / s2.jar / s3.jar，修改各自的代码，至少不会扩大影响范围。
大家为什么都把代码往一个公共库里塞？
很多时候，因为惰性，一点一点的惰性，日积月累，终成大坑。
这个垂直拆分是一个架构重构的过程，需要各业务方配合。
方案三：服务化，将公共库里通用业务代码拆到下层去
完成了第一步，业务个性化的代码提取到业务侧上游。
接下来是第二步，业务通用的代码，下沉抽取一层服务，服务对上游提供RPC接口：
-
每次修改底层接口，需要测试接口的兼容性，保证不影响旧调用方
-
如果是新的业务，则建议新增接口
最终，达到通过服务RPC调用的方式来解除耦合。
个性业务代码上浮，共性业务代码服务化下沉，只是一个很小的优化点，但对于公共库解耦却是非常的有效。
3. CA，给了数据库，给了机器，为啥也扩不了容？
如何解除公共数据库与业务数据库的耦合？
第一步：公共数据访问下沉服务化
第二步：垂直拆分，个性化数据访问上浮
此时各业务有自己的库，公共有公共的库：
-
早期：可以放在一个数据库实例里
-
后期：可以很容易地通过新增数据库实例，把user库或者业务A/B/C的库拆分出来，实现增加机器增加实例就实现扩容
4. 服务化了，没想到耦合更加严重？
1). 讨论技术方案时，不要总以：
“放在你那边做代码少”
“放在你那边做时间短”
作为设计折衷的理由，而要多问：“怎么做合理”
2). 尽量杜绝底层出现switch case(biz_type)走不同分支的代码。
业务代码上浮，通用代码下沉，服务化彻底，只是一个很小的优化点，但对于底层服务解耦却是非常的有效。
5. MQ，互联网架构解耦神器
1). 一个架构常识：当调用方需要关心执行结果，通常使用RPC调用。但如果调用方不关心执行结果，却仍然使用RPC调用，会引发上下游极大的耦合与瓶颈。
2). 如果事件发出方不关心订阅方的执行结果，不能用RPC，应该用MQ。
MQ能够做到上下游物理上和逻辑上都解耦：
-
物理上解耦，增加MQ之后，上游互不知道彼此的存在，不会建立物理连接了，大家都只与MQ建立物理连接
-
逻辑上解耦，事件发布方甚至不用知道哪些下游订阅了这个消息，新增消息的订阅方只需要连接MQ就行了，不需要上游关注
MQ是一个非常常见的物理上解耦、逻辑上也解耦的利器。
关注下游执行执行结果，用RPC；不关注下游执行结果，用MQ，不用RPC；
这只是一个很小的优化点，但对于通知解耦却是非常有效。
6.