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