架构设计

移动互联网平台的架构设计是支持整个业务的基础，需要在业务架构、应用架构、数据架构和技术架构上进行全面的设计。与单个应用的架构设计不同，本文讨论整个互联网平台的架构设计。

架构设计的整体愿景

京东的整体架构目标就是“多、快、好、省”。为了达到这一目标，总体的策略就是维持高可用性、高可扩展性和低成本的平衡。而这一目标对产品的质量提出了更高的要求，例如运行时质量、设计质量、系统质量和用户质量（呈现给用户体验的质量）。

平衡三角

一般来说，架构的组成分为四个部分，即业务架构、应用架构、数据架构和技术架构。其结构如下：

分层架构模型

对于具体模块间的配合，应当遵循整体横向分层抽象，局部纵向贯穿分解的原则。阿里架构是比较典型且优秀的一个范例：

阿里巴巴整体架构示例

可以看到，整体呈现出 $\text{SaaS}$、$\text{PaaS}$、$\text{IaaS}$ 三层抽象，而针对安全和管理模块，则实现了全局的贯穿和分解。

业务架构

业务架构是整个平台业务之间协助配合的整体方针。一般来说，业务架构的设计应当满足下面的原则：

• 业务平台化和基础业务下沉。基础业务下沉即把常用的基础业务做成底层可复用的模块或平台。例如，京东平台就将用户、商品、订单等基础业务下沉，减少了冗余。
• 核心业务分离。精简核心业务，保证核心业务的稳定性。
• 隔离不同类型业务。将追求高可用性、高并发和强一致性的业务分离开，满足不同需要。
• 区分主流程和辅流程。先保证主流程的执行，辅流程可以异步执行。

应用架构

应用架构设计开始涉及具体服务的细节，以及服务间的协作。这一部分与软件工程中的体系结构设计和详细设计的知识有相关之处。同样，与业务架构相近，应用架构的设计也遵循一些原则：

• 稳定性原则。架构的设计以稳定性为中心，尽可能简化，不过度设计。
• 解耦和拆分。根据业务架构，将不同的部分进行解耦。例如，可以将核心业务和非核心业务分离；将应用和数据分离。解耦的部分尽可能实现异步化。
• 抽象化。应用只依赖服务的抽象，而不在乎服务的细节；虚拟化部署等。
• 高容错性。服务之间能自治，不会发生连锁反应；集群部署，提高容错性。

我们可以看如下一个交易订单应用的架构实例：

一个交易订单应用的架构实例

这一应用采取分层的架构，服务之间耦合性比较低，每一个服务都比较简洁。

前面说过，应用架构的设计应当进行解耦和拆分，那么具体如何去拆分、拆分什么，我们需要一个方法论。实践中常用的架构分解原则有如下几点：

• 水平扩展：简单扩展集群，提高并发能力。
• 垂直拆分：按照业务领域的不同拆分。如酒店和车票。
• 业务分片：按照业务功能的特点进行拆分。如限时秒杀和天天领现金。
• 水平拆分：服务分层，功能与非功能分离。

另一方面，我们还需要明确架构之间应当如何互相协作或依赖，这一点与体系结构设计中的各个原则比较接近，主要的原则就是稳定依赖原则。

针对每一个服务，有如下的具体设计原则：

• 无状态和幂等性。服务尽量做成无状态的，尽量不要在本机存储状态数据。接口调用应当考虑幂等性。
• 松耦合。跨服务域调用时尽量异步进行；必须同步调用时，应当设置超时和队列大小。
• 可治理。服务应当配备监控、降级、限流等装置。

服务间的访问——远程过程调用 $\text{RPC}$

仿照进程间通信的过程（如管道、信号量等），$\text{RPC}$ 的关注点是与远程的软件系统进行通信、甚至进行方法调用。$\text{RPC}$ 主要回答了下面三个问题：

• 如何表示数据？$\text{RPC}$ 交互双方可能各自使用不同的程序语言，或者同样的数据类型在不同硬件指令集、不同操作系统下，也可能存在数据宽度、字节序等等的差异。$\text{RPC}$ 将交互双方所涉及的数据转换为某种事先约定好的中立数据流格式来进行传输，将数据流转换回不同语言中对应的数据类型来进行使用。
• 如何传递数据？“传递数据”通常指的是应用层协议，实际传输一般是基于标准的 TCP、UDP 等标准的传输层协议来完成的。$\text{RPC}$ 双方信息交换的需求除了序列化的数据，还包括异常、超时、安全、认 证、授权、事务等。常见的协议有 $\text{JRMP}$ 和 $\text{SOAP}$ 以及最简单的 $\text{JSON-RPC}$。
• 如何表示方法？一般使用语言无关的接口描述语言，如 $\text{JSON-WSP}$ 和 $\text{WSDL}$。

服务间的访问——表征状态转移 $\text{REST}$

表征状态转移是一种软件架构，目的是方便不同软件或服务在网络之间传递信息。一般来说，服务端向浏览器返回的 HTML 等信息就被称之为“表征”。

$\text{REST}$ 强调资源的概念。资源是由 URI 来指定，且表现形式是 XML 或者 HTML，取决于接受信息的客户端。$\text{REST}$ 架构的主要限制条件如下：

• 客户端-服务器分离。
• 无状态。
• 统一接口。请求中包含资源的标识，资源通过标识来进行操作，且标识具有自我描述性。
• 超文本驱动。是 $\text{REST}$ 的最高等级。

常用的 Web API 有 GET、PUT、DELETE 和 POST。

数据架构

数据架构主要对持久化数据的存储进行统筹设计。一般来讲，它包含以下衡量标准：

• 统一数据视图：保证数据的及时性、一致性、准确性、完整性等。（$\text{ACID}$ 原则）
• 数据、应用分离：应用系统不直接访问其它宿主的数据库，只能通过服务访问。
• 数据异构：源数据和目标数据内容相同时，做索引异构，如商品库不同维度；内容不同时，做数据库异构，如订单买家库和卖家库。
• 数据读写分离：有时大量读写的比例不同，或吞吐量过大，此时需要进行读写分离。
• 合理使用缓存：数据库有能力支撑时，尽量不 要引入缓存，但可以合理利用缓存做容灾。

技术架构

技术架构是对整个平台的技术选型和技术方案的设计，是由多个系统和服务组成的复杂技术体系。例如，京东的技术架构分为了基础平台、虚拟平台、运营管理、治理平台等。

京东的技术架构

整个技术架构在系统运行时应当做到：

• 高容错性：服务可监控，自身有修复能力；使用多机房部署，发生故障时可以快速切换。
• 高灵活性：服务可动态扩容，可动态调整配置；应用也可以动态部署和回滚降级。
• 高安全性：确保系统的保密性和完整性，具有足够的防攻击能力。

在部署时，也可以适当遵循下面几个原则：

• N+1原则：保证系统的高可用性，即在每个时刻都有多于一个的备份。
• D-I-D原则：即设计 $20$ 倍的容量，实现 $3$ 倍的容量，部署 $1.5$ 倍的容量。
• 灰度发布：新版本发布时，先在少量用户中进行测试，再逐步扩大范围。
• 虚拟化部署：二级系统、三级系统采用虚拟机部署，节省资源和管理成本。
• 业务子网：基本服务和数据库，相同业务域的服务器部署在一起;不同业务域的服务器物理隔离。