1.2　分布式架构设计理念和目标

1.2.1　设计理念

分布式架构的核心理念按照一定维度（功能、业务、领域等）对系统进行拆分，通过合理的拆分结构，实现各业务模块解耦，同时通过系统级容错设计，在廉价硬件基础设施上构建起高可用、可扩展的开放技术体系。

1.2.2　设计目标

设计目标可以明确方向，通过设计驱动和方向的把控，朝着既定方向前行并最终实现目标。分布式架构中较为完整的架构体系设计包括以下几个方面。

1. 系统拆分

系统拆分思路如下所示。

• 以业务为导向，充分了解系统业务模型，按不同层面的业务模型可以将其划分为主模型、次模型。业务模型在一定比例上能够凸显出系统的业务领域及边界。
• 业务依赖范围，由于业务存在重复依赖，从业务边界中按照业务功能去细分。
• 把拆分结构图梳理出来，按照系统周边影响从小到大逐渐切换。
• 拆分过程中尽量不要引入新的技术或者方案，如有需要，应讨论评估后再实施。

以购物平台为例，按照业务功能可以简单拆分为如下几个模块。

（1）用户模块

• 用户管理（新增用户、用户锁定、用户修改、用户删除、用户活跃状态）。
• 用户分类（用户类别，定义多种用户体系，针对不同用户体系管理）。
• 用户社交（用户之间关注、聊天）。
• 用户行为收集、反馈、会员处理。
• 用户统计。

（2）商品模块

• 商品管理（增加商品、修改商品信息、删除商品、查询商品信息、商品上下架、预/批处理等）。
• 商品目录管理（商品的虚拟路径、商品之间关联）。
• 商品类别（种类、自定义商品的各种信息）。
• 商品社交（商品的评价、回复、点赞）。

（3）订单模块

• 订单管理（增删改查订单、拆分管理、订单处理）。
• 支付管理（支付查看、人工支付处理）。
• 结算管理（数据核对、费用结算）。

（4）库存模块

• 库存管理（数量动态调整、库存处理、数量提醒）。
• 库存明细。
• 处理非正常完成订单（退货、换货）。
• 备货。

2. 业务模块解耦

在拆分之前，模块和模块之间、系统和系统之间可能有非常强的依赖，所以我们在拆分过程中需要思考，哪些模块需要减少依赖。依赖越少，独立性越强。

例如，用户强依赖商品，为了减少用户依赖而把商品从用户中剔除，显然并不合理。所以可以减少用户依赖商品细粒度。

用户模块和商品模块独立出来后，两者之间如何交互调用呢？我们可以把两者之间通用性较强的业务独立到共通的服务中，通过调用共通服务减少耦合性。

这样做的优点是：

1）减少模块和模块之间的大量耦合交互；

2）后期修改维护成本少；

3）简单透明。

通过以上优化，如两者之间还存在少量的依赖，考虑是否进一步拆分。如需拆分，可以通过一定维度（规划计划、系统后续完整性、后续维护工作量等）拆分，也可以通过接口的方式解耦，例如用户、商品之间提供一个共用接口，用户调用接口，商品实现接口。这种方式比较烦琐。

3. 系统容错

容错是为了避免系统架构和业务层面发生故障而引起其所在系统的不稳定。优秀的容错设计能让系统的反馈对故障不敏感，甚至是自适应的。容错设计包括以下两个层面。

（1）架构设计层面

• 重试： 因网络传输、超时、业务短暂异常等系统问题而提供的一种补偿机制，能更大程度弥补因异常导致的丢失。实现方式为利用消息中间件自动重试。若无自动重试，可自行实现重试推送。
• 服务降级： 可分为自动降级和手动降级。当系统压力上升、出现各种延迟卡顿时，系统会自动检测影响面范围。若影响面积小，可自动降级，反之，需要人工去分析是否需要降级以及替换。实现方式有两种。第一种是全局合法请求拦截，根据系统的运行状态去判断是否需要手动/自动关闭。另一种是检测调用系统方是否正常，利用超时机制，规定某时间范围内超过多少次则自动替换。
• 熔断和限流： 熔断和限流是为了应对性能过载的情形。高压力期间如全部业务都失败，可控制拒绝大部分请求失败，尝试利用小部分流量去重试。当发现小部分流量某范围内成功频率很高时，可适当开放流量入口，依次递增，直到最终流量全部正常访问。应尽量使用熔断器实现，如无可自行实现。

（2）业务功能层面

• 幂等： 系统可能会出现多次同样的请求，如重试的请求、网络超时的请求等，因此需要针对这些场景设置一些优化手段，防止业务执行出错、数据异常等。大部分请求具有时效性，幂等需保证在一定时间内，重复的请求不再消费。实现方式如下：为分布式的缓存或者数据库设置唯一主键，对比请求中的唯一标识，如不存在则处理请求业务，否则不处理，直接返回之前处理的结果。
• 异步处理： 由于请求的生命周期漫长，会经历多个环节，且请求完成时间较长，导致大量线程处于等待状态，久而久之会形成堵塞、假死。如采用异步处理方式，系统在收到请求后会立即处理并返回结果，无须等待，可以减少请求耗时，也可以充分利用重试来保证收到消息后立即处理。实现方式为利用消息特性提供异步处理，如可自主实现阻塞队列。
• 事务补偿机制： 业务程序中需要支持这种补偿，针对重要场景提供多种处理方案，特定情况下其中一种方案通过即可。业务程序中可设置开关，通过开关切换实现事务补偿。

4. 高可用

通过设计和监控可以提高系统正常提供服务的可靠性，那么，如何才能保障系统的高可用？单点系统面临严重高可用问题，所以在设计过程中要尽量避免系统的单点出现，保证系统处于多机状态，俗称冗余。冗余指重复配置系统某些部件，当系统发生故障不可用时，冗余配置的部件介入并承担故障部件的工作，减少系统的故障时间。分布式架构中，互联网调用过程如下。

1）客户端层：首页、App。

2）代理服务层、请求加速层：减少请求访问次数，达到加速。

3）应用服务层：系统业务服务。

4）数据缓存层：业务数据内存存储。

5）数据库层：业务数据数据库存储。