核心痛点
上游痛：扩容的是下游，改配置重启的是上游（耦合，典型反向依赖）
下游痛：不知道谁依赖于自己（难以实施服务治理）
怎么解耦，怎么解决？
“配置私藏”架构
“全局配置文件”架构
“配置中心”架构
MQ是一个互联网架构中常见的解耦利器
什么时候不使用MQ？
什么时候使用MQ？
数据驱动的任务依赖
上游不关心执行结果
上游关注结果，但执行时间很长
削峰填谷，流量控制，保护下游
平滑迁移
步骤一：消费方双向订阅
步骤二：生产方升级为新发布
步骤三：消费方下线旧订阅
典型耦合场景与解耦实践
如何发现系统中的耦合？
场景一：“IP耦合”如何解耦？
场景二：“公共库耦合”如何解耦？
优化方案：
垂直拆分，个性业务代码“上浮"
服务化，共性业务代码“下沉"
场景三：“数据库耦合”如何解耦？
第一步：公共数据访问服务化，数据私藏
第二步，个性数据访问，自己家的数据自己管理
解耦之前：
代码简单，一次数据库访问
逻辑实现在SQL里
数据库耦合
解耦之后：
代码更复杂，多次数据库访问
逻辑实现在服务层
数据库解耦
场景四：“微服务耦合”如何解耦？
如何解耦？
讨论技术方案时，不要总以：
“放在你那边做代码少””
“放在你那边做时间短"
作为设计折衷的理由，而要多问：
尽量杜绝底层出现switch case（biz type），走不同分支的代码。
分层架构，是一个“数据移动”，然后“被处理”，被“呈现”的过程！
数据移动的过程中，以下两点尤其重要：
数据传输的格式
数据在各个层次的形态
架构分层方法论：
让上游更高效的获取与处理数据，复用
让下游能屏蔽数据的获取细节，封装
DAO与服务化
为了屏蔽数据库数据细节，需要引入DAO
为了屏蔽垂直拆分，分库分表，缓存细节，需要基础数据服务化分层
业务服务层
前后端分离
数据库中间件
分层架构，是一个“数据移动”，然后“被处理”，被“呈现”的过程！
架构分层方法论：
让上游更高效的获取与处理数据，复用
让下游能屏蔽数据的获取细节，封装
业务的归业务，技术的归技术，服务网格（ServiceMesh），本质也是分层解耦
Istio
数据平面，主要负责高效转发
控制平面，主要负责控制与应用
mixer模块：支持跨平台，标准化API的adapter；
pilot模块：控制与配置envoy的大部分策略；
citadel模块：安全相关；
galley模块：与底层平台（例如：K8S）配置解耦；
单机房架构：全连接
理想多机房架构：同连接（适用于能按照业务进行数据分割的场景）
折衷多机房架构：最小化跨机房连接（通用）
机房迁移步骤
先迁移站点层、业务服务层和基础服务层
准备新机房与专线
搭建集群，充分测试，子业务垂直拆分迁移
灰度切流量
缓存层迁移
搭建新缓存；
运维修改缓存内网DNS，切断旧缓存连接，重连新缓存，切流量
数据库迁移
搭建新数据库
同步数据
旧库ReadOnly，同步完成后（秒级），服务指向新库，改配置重启，切流量（会有一个高可用的损失）
原文：https://www.cnblogs.com/ltaodream/p/15267862.html