每天净瞎搞

关注:CS/AI/数学/自我提升等

0%

《沈剑架构师训练营》第7章 - 架构解耦

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 访问数据库,要么子业也建立个性化数据访问的服务,本质是垂直拆分