他说用MQ，终于把耦合解了！！！-技术圈

《大专栏》第七阶“架构解耦”已经放出。

配置文件，是互联网架构中不可缺少的一环。依赖（调用）某个下游服务集群，将下游集群信息放在自身配置文件里是一种惯用做法，该做法可能导致什么问题？

可能导致上下游严重耦合：

（1）上游痛：扩容的是下游，改配置重启的是上游；

画外音：架构设计中典型的反向依赖。

（2）下游痛：不知道谁依赖于自己，难以实施服务治理，按调用方限流；

为了解决上述问题，常见的配置架构演进是怎么样的？

（1）“配置私藏”架构；

（2）“全局配置文件”架构；

（3）“配置中心”架构；

除了配置中心，消息总线MQ也是互联网架构中的常见解耦利器。

一般来说，什么时候不使用MQ？

上游实时关注执行结果时，通常不使用MQ，而使用RPC调用。

什么情况下，可以使用MQ来解耦？

以下四种情况，可以使用MQ来解耦：

（1）数据驱动的任务依赖；

（2）上游不关心执行结果；

（3）上游关注结果，但执行时间很长，例如跨公网调用第三方服务；

（4）削峰填谷，流量控制，保护下游；

上下游IP耦合，可以如何解耦？

使用内网域名来代替内网IP。

多个模块，因为公共库而耦合在一起，可以如何解耦？

粗暴方案：代码各自拷贝一份（不太推荐）。

优化方案：

（1）垂直拆分，个性业务代码“上浮”；

（2）服务化，共性业务代码“下沉”；

多个模块，因为数据库而耦合在一起，可以如何解耦？

数据库耦合，需要对架构进行调整：

（1）第一步，公共数据访问服务化，数据私藏；

（2）第二步，个性数据访问，自己家的数据自己管理；

画外音：数据库耦合，当数据库成为瓶颈时，增加数据库实例也难以拆分扩容，非常头疼。

微服务拆分不完全，导致耦合，可以如何解耦？

（1）底层微服务功能要尽量通用；

（2）杜绝底层switch case不同业务类型的业务逻辑代码；

（3）个性化代码上浮，公共代码下沉，是更古不变的架构解耦准则；

画外音：架构复杂时，微服务是好事，但拆分不彻底反而会有坑。

18次直播回看，以及《架构师第七阶：架构解耦》的6节也已经放出，系统性的详聊了上面这些问题，感兴趣的同学可以扫码看细节。

18次直播精华回看，有哪些内容？

（1）每秒100w请求，秒杀架构
（2）千万粉丝，feed架构
（3）千万同时在线，IM架构
（4）每秒100w检索，搜索引擎内核架构
（5）MQ内核细节
（6）RPC内核细节
（7）数据库架构
（8）多机房多活架构与细节
（9）分布式调用链追踪架构与细节
（10）3周自研自动化上线平台
（11）区块链中的架构理念
（12）数据库性能瓶颈定位
（13）反范式数据库设计
（14）微服务抽离与解耦
（15）经典架构10问
（16）微服务与数据库架构10问
（17）技术人职业发展规划
（18）InnoDB内核架构与细节

每次1-2小时不等，全部已放出。

50节架构师训练营干货重放，有哪些内容？

第一阶：技术选型（5节，已放出）
第二阶：接入层架构（5节，已放出）
第三阶：极速性能优化（3节，已放出）
第四阶：微服务架构（7节，已放出）
第五阶：数据库架构（6节，已放出）
第六阶：缓存架构（7节，已放出）
第七阶：架构解耦（6节，已放出）
第八阶：架构分层
第九阶：架构进阶

把控住这些，应该能成为一名P8的架构师吧？

其他内容何时放出？

2.21之前全部放出。

《大专栏》，有没有折扣？

（1）巨折899（原价1699）;

（2）2.20之前，还可领150优惠券（749）；

画外音：仅限这几天了，抓紧时间。

如何领优惠券？

扫码领券，直减150，仅限2.20之前

如何入手《大专栏》？

扫码，入手架构师之路《大专栏》

白嫖了这么多年，欢迎为情怀补票，希望大家有收获，早日成为P8P9架构师。

画外音：建议平均每天花2小时，倍速看1-2集直播，5节训练营，春节20天假期搞定。

讨论：

你碰到哪些坑人的耦合案例？

阅读原文，订阅《大专栏》，早日P8P9。