互联网业务背景
随这移动互联网、云计算、大数据、物联网技术的发展，促进电子商务、工业互联网和互联网金融等业务领域健康发展。无论是互联网公司，还是传统行业，一切商业都将互联网化，这几乎是所有大佬能达成的唯一共识。所以目前我们面临的首要任务就是构建和改造我们的系统使其面向互联网。
互联网应用的几个特性：
Ø 高性能
Ø 高可用性
Ø 大数据
Ø 低成本
互联网系统设计原则
面向互联网化的过程中，系统架构应该按照以下几个规则进行设计。
1.1 业务架构设计原则
1.1.1 业务平台化
Ø 业务平台相互独立，如交易平台、支付平台、广告平台。
Ø 基础业务下沉，可复用。如，用户、商品、类目。
1.1.2 核心业务、非核心业务分离
Ø 系统核心业务与非核心业务分离，核心业务精简（利于稳定），非核心业务多样化。如，如主交易服务、通用交易服务。
1.1.3 区分主流程、附流程
Ø 区分哪些是系统主流程。运行时，优先保证主流程顺利完成，辅流程可以采用后台异步化的方式。避免主流程失败导致主流程的回滚。如，下单时，同步调用快照，异步通知台账，发表。
1.1.4 隔离不同类型的业务
Ø 交易业务就是签订买家、卖家之间的交易合同，需要确保高可用性，让用户能够快速下单。
Ø 履约业务对可用性没有太高的要求，可以优先保证一致性。
Ø 秒杀业务对高并发要求很高，应该跟普通业务隔离。
1.2 应用架构设计原则
1.2.1 稳定性原则
Ø 一切以稳定为中心
Ø 架构尽可能简单、清晰
Ø 不过度设计
1.2.2 解耦/拆分
Ø 稳定部分与易变部分分离
Ø 核心业务与非核心业务分离
Ø 主流程与辅流程分离
Ø 应用与数据分离
Ø 服务与实现细节分离
1.2.3 抽象化
Ø 应用抽象化：应用只依赖服务抽象，不依赖服务实现细节、位置
Ø 数据库抽象化：应用只依赖逻辑数据库，不需要关心物理数据库的位置和分片
Ø 服务器抽象化：应用虚拟化部署，不需要关心实体机配置，动态调配资源
1.2.4 松耦合
Ø 跨域调用异步化：不同业务域之间尽量异步化解耦。
Ø 非核心业务尽量异步化：核心、非核心业务之间，尽量异步解耦
Ø 必须同步调用时，需要设置超时时间和任务队列长度
1.2.5 容错设计
Ø 服务治理：服务能彼此独立修改、部署、发布和管理。避免引发连锁反应
Ø 集群容错：
Ø 集群容错：应用系统集群，避免单点
Ø 多机房容灾：多机房部署，多活
1.3 数据架构设计原则
1.3.1 统一数据视图
Ø 保证数据的及时性、一致性、准确性、完整性
1.3.2 数据、应用分离
Ø 应用系统只能依赖逻辑数据库
Ø 应用系统不能直接访问其他宿主的数据库，只能通过服务访问
1.3.3 数据异构
Ø 源数据和目标数据内容相同时，做索引异构。如，商品库不同维度
Ø 内容不同时，做数据库异构。如，订单买家库和卖家库
1.3.4 数据读写分离
Ø 访问量大的数据库做读写分离
Ø 数据量大的数据库做分库分表
Ø 不同业务域数据库做分区隔离
Ø 重要数据配置库
1.3.5 合理使用缓存
Ø 数据库有能力支撑时，尽量不要引入缓存
Ø 合理利用缓存做容灾
1.4 技术架构设计原则-运行时原则
1.4.1 可监控
Ø 服务的TPS和RT是否符合SLA
Ø 是否出现超出预期流量
1.4.2 应用可回滚，功能可降级
Ø 应用出现问题时，要求能回滚到上一版本，或做功能开关或降级。
1.4.3 在线扩容
Ø 超预期流量时，应用系统可选择在线水平扩展
1.4.4 安全保证
Ø 确保系统保密性和完成性
Ø 具有足够的防攻击能力
1.4.5 可容错
Ø 核心应用要求多活，避免单点设计，并且自身有容错和修改能力。故障时间TTR小
1.4.6 故障转移
Ø 多机房部署，发生故障时，能即时切换
1.5 技术架构设计原则-部署原则
1.5.1 N+1原则
Ø 确保为故障多搭一套系统，避免单点问题。
Ø 功能开发与运维分开。系统开发完成后，交给专业的运维团队管理和运营。
1.5.2 D-I-D原则
Ø 设计20倍的容量（Design）
Ø 实现3倍的容量（Implement）
Ø 部署1.5倍的容量（Deploy）
1.5.3 支持灰度发布
Ø 系统新上线，要求支持“灰度发布，分步切流量，故障回滚”
1.5.4 虚拟化部署
Ø 虚拟部署：系统采用虚拟机部署，节省资源和管理成本
1.5.5 业务子网
Ø 机房部署以业务域划分：基本服务和数据库，相同业务域的服务器部署在一起；不同业务域的服务器物理隔离
系统升级选取规则
对典型的社交类应用的架构及技术进行分析，目前社交类应用一般会包含的
架构风格有：微服务，EDA、CQRS、前端 SPA，通过这些架构风格实现系统的可
扩展性，高可用，以及在大用户、高并发下的高性能等，具体的架构风格和关键
设计约束对应关系如下：
