34、解耦：配置中心，与配置架构演进。

• no34：配置文件架构有什么核心痛点？
  • 1.上游痛：扩容的是下游，改配置重启的是上游(耦合，典型反向依赖)
  • 2.下游痛：不知道谁依赖于自己(难以实施服务治理)
• no34：配置文件架构怎么解耦？
  • 1.「配置私藏」架构
    • 
    • 上游把下游的配置私藏在自己单独的配置文件里
    • 不足：例如需要扩容时，下游需要通知所有的上游调用方去修改各自私藏的配置，并重启上游，将连接连到新的集群节点上去，将流量从下线的节点迁走
  • 2.「全局配置文件」架构
    • 
    • 运维制定一系列配置文件规范，将通用的服务的配置放到 global.conf 全局配置文件里，调用方升级，不再读取本地的私有配置文件，而是读取全局配置文件去获取通用服务的配置，配合文件监控组件和动态连接池组件能够实现自动的扩容与缩容，但依然解决不了下游服务治理的问题
    • 优点
      • 下游容量变化时只需修改一个地方，调用方重启后会自动读取新配置，对架构的改动较小
    • 不足
      • 如果调用方一直不重启，就没办法迁移
  • 3.「配置中心」架构
    • 
    • 由服务、zookeeper、后台配置文件和落地的数据库组成
    • 所有服务的配置都维护在配置中心里，所有调用方需要注册配置中心，去配置中心拉取相关的配置，此时全局调用关系图和服务治理，以及按照上游的调用方来限流，就容易实现

35、MQ，互联网架构解耦利器。

• no35：什么时候不用 MQ？什么时候用 MQ？
  • 不用
    • 上游实时关注执行结果，通常采用 RPC
  • 用
    • 1.数据驱动的任务依赖，如下一个任务依赖上一个任务的执行结果
    • 2.上游不关心执行结果
    • 3.上游关注结果，但执行时间很长，如是离线处理或者跨公网调用的时候，经常使用回调网关加 mq 解耦的方案
    • 4.削峰填谷，流量控制，保护下游：使用 MQ 的拉取模式，消息的消费方根据自己的处理能力来拉取消息，可实现流量控制，能够达到自身保护的效果

36、解耦：MQ，平滑迁移。

• no36：如何实现 MQ 的平滑迁移？如何快速实现统一迁移？
  • 步骤
    • 1.消费方双向订阅
      • 
    • 2.生产方升级为新发布
      • 
    • 3.消费方下线旧订阅
      • 
  • 快速实现统一迁移
    • 浅浅地封装一层后，可简单地升级一下组件即可

37、解耦：IP耦合，公共库耦合，解耦实践。

• no37：如何发现系统中的耦合？
  • 查找「被动联动」的点
• no37：「IP 耦合」如何解耦
  • 使用内网域名来替代内网 IP
  • 
• no37：「公共库耦合」如何解耦
  • 1.代码各自拷贝一份
  • 2.垂直拆分，个性业务代码「上浮」
    • 
  • 3.服务化，共性业务代码「下沉」
    • 

38、解耦：数据库耦合，解耦实战！

• no38：如何对「数据库耦合」进行解耦？
  • 1.公共数据访问服务化，屏蔽底层数据访问的复杂性，屏蔽分库分表，屏蔽读写分离，屏蔽缓存与数据库，将数据私藏
    • 
  • 2.个性数据访问，自己家的数据自己管理，要么通过 DAO 访问数据库，要么子业也建立个性化数据访问的服务，本质是垂直拆分