以下内容来自于腾讯PCG工程师Chaoweili
不同地区都提供业务服务，一个地区故障（机器宕机、机房故障、网络故障），其他地区可用，故障地区用户可请求到其他地区进行服务。异地多活实现复杂成本高，并不是所有系统都无脑的实现异地多活。
同城异区：同一城市双机房部署，例如北京双机房
跨地异区：不同城市多机房，例如：北京和广州两个机房
跨国异区：不同国家多个机房，例如：中国亚马逊，美国亚马逊
1） 核心业务异地多活
2） 核心数据最终一致性
3） 多种手段同步数据：1）消息队列表； 2）二次读取；3）存储同步；4）回源同步；5）重新生成数据
4） 只保证大部分用户异地多活
1） 业务分级：访问量大；核心业务；收入高的业务
2） 数据分类：数据量；唯一性；实时性；可丢失性；可恢复性
3） 数据同步：存储系统同步；消息队列同步；重复生成
4） 异常处理：多通道同步；同步和访问结合（数据分区同步）；日志记录；用户补偿（点券会员资格等安抚用户）
内部：程序bug；外部：黑客攻击
业务接口功能降低，只提供部分功能。比如：只读不写；部分功能停止；尽量保证核心功能。
降级操作：1）单个服务提供接口打开降级开关；2）降级系统批量操作
某个接口响应很慢会拖慢整个系统，熔断就是不在访问这个接口直接报错。
降级：接口本身功能故障处理；熔断：外部被调接口故障
降级：故障时按优先级处理
限流：故障时减少用户请求压力
限流方式：
1） 基于请求限流：
a. 总量限流：一个直播不能超过100万人
b. 时间段限流：一分钟最多接收N个人请求
2） 基于资源限流
例如：cpu、内存、句柄数等按可支持的qps负载限流
排队是限流的一个形式，限流是拒绝，排队是等待，比如用kafka队列缓存用户请求
排队模块将超量请求放入消息队列，调度模块读取队列，调用服务模块提供服务处理
【第4部分】 可扩展架构模式
不断迭代，产生新的功能
拆成不同子模块，拆分方式：按流程；按服务；按功能
1） 面向流程拆分: 分层架构
2） 面向服务拆分: SOA、 微服务
3） 面向功能拆分 : 微内核架构。
1） C/S、B/S架构
2） MVC结构、MVP架构
3） 逻辑分层架构：接入层、应用层、逻辑层、存储层
SOA（ Service Oriented Architecture）：面向服务的架构，解决传统企业IT系统重复建设和扩展效率低的问题。
1） 服务：所有业务功能都是一个服务
2） ESB（Eneterprise Service Bus）企业服务总线
3） 松耦合：各个服务之间减少依赖和相互影响
1） 划分过细，服务之间的关系复杂
2） 服务数量过多，团队效率下降：功能改动需要N个服务同时配合改动
3） 调用链太长，性能下降，也增加了定位问题的成本：rpc链路长，增加了网络耗时
4） 如果没有自动化支撑，无法快速交付
5） 如果没有服务治理，微服务数量多了后管理混乱
1） 合理拆分，粒度不易过细
2） 基础设施：自动发布、服务治理、服务发现、负载均衡、监控上报
1） 基于业务逻辑拆分：按功能拆分服务模块
2） 基于可扩展拆分：稳定服务粒度粗一些，不稳定服务拆分细一些
3） 基于可靠性拆分：核心服务保证高可高，和非核心服务拆分开
4） 基于性能拆分：对于要求不同的模块拆分开，同一个模块的读写性能按需也可以拆分（比如，写少读量非常巨大）
1） 自动化测试：单元测试，接口测试，集成测试
2） 自动化部署：自动编译发布部署，版本管理，资源管理，灰度和回滚
3） 配置中心
4） RPC框架和协议：HTTP/REST，json/pb
5） API网关：微服务内部互联互通，对外部使用API网关：接入鉴权、权限控制、加密、路由、流量控制、协议转换
6） 服务发现：各个服务注册、状态维护、路由调度等。服务发现两种实现方式：自理式和代理式
7） 服务路由：服务路由调度算法：随机、轮询、最小负载（cpu内存等）、最小连接数等
8） 服务容错：容错方式：重试、流控（频控）、服务隔离（故障节点剔除）
9） 服务监控：上报监控系统
10） 服务跟踪：跟踪一个请求的整个链路。跟踪方式：采样跟踪、染色跟踪
11） 服务安全：接入安全、数据安全、传输安全
微内核架构（Microkemel Architecture）：也被称为插件化架构( Plug-in Architecture)，是一种面向功能进行拆分的可扩展性架构。包含：核心系统和插件模块
1） 插件管理
2） 插件连接
3） 插件通信
OSGi 的全称是 Open Services Gateway initiative，本身其实是指 OSGi Alliance。
(1) 模块层( Module 层〉：插件管理，插件配置文件等
(2) 生命周期层( Lifrcycle层）：插件连接，提供执行时模块管理，对层OSGi框架的访问
(3) 服务层( Service层）：插件通信
【第5部分】 架构实战
消息队列为例
列出三种方案：kafka、MySQL、自研存储
评审对比后选择：2，MySQL
然后继续优化：表设计、主从部署、主备切换、读写服务
1） 潮流派
2） 保守派
3） 跟风派
除非是开创新的技术能够创造一种新业务，其他情况下都是业务发展推动技术的发展。
1） 初创期：创新
2） 发展期：快。功能迭代和优化
3） 架构期：量级越来越大，海量服务之道
4） 竞争期：平台化/服务化
5） 成熟期：对于弱势不断优化
1） 性能
2） 可用性
1）SQL
2）NoSQL
3）小文件存储
4）大文件存储
1） 开发框架
2） Web服务器
3） 容器
1） 配置中心
2） 服务中心
3） 消息队列
1） 负载均衡：CDN、Ngnix 、LVS、F5
2） CDN
3） 多机房：同城多机房、跨城、跨国
4） 多中心
1） 用户管理
2） 消息推送
3） 存储云与图片云
复杂性的一个主要原因就是系统越来越庞大，业务越来越多 ，降低复杂性最好的方式就是 “拆”，化整为零、分而治之，将整体复杂性分散到多个子业务或子系统里面去 。
1） 配置
2） 部署
3） 监控
4） 应急
运维平台核心要素：标准化、平台化、可视化
1） 用例管理
2） 资源管理
3） 任务管理
4） 数据管理
1） 数据管理
2） 数据分析
3） 数据应用
1） 身份认证
2） 权限控制
1） 后台系统重构：解决不合理的耦合
2） 游戏后台重构：解决全局单点的可用性问题
3） X系统：解决大系统带来的开发效率问题
团队内部达成一致
外部团队协调合作
重构实施：
1） 划分优先级
2） 问题分类
3） 先易后难
项目管理
技术能力
1） 开源：解决痛点
2） 二次修改开源项目：优化轮子
原文作者：鹅厂架构师