下载掌阅APP，畅读海量书库
立即打开
由于服务和数据分别部署在不同的机器上，它们之间的交互通信会存在如下问题。
1）网络延迟。延迟是指在传输介质中传输所用的时间，如部署在同一个机房，网络I/O传输相对较快，但是很多公司为了增加系统的可用性，有多套机房（线上、线下），此时会面临跨机房、跨网络传输等情况。尤其是跨IDC，其网络I/O会存在不确定性，出现延迟、超时等情况，虽然可以通过换网卡解决宽带瓶颈，但不能从根本上解决物理延迟。由于这些现象会给整个设计带来整体性的难点，我们在做分布式架构设计的同时需要考虑这些要素，并且提供相关高效解决方案，从而规避此问题。
2）网络故障。若出现网络故障问题，可以先了解数据是以什么协议方式在网络中传输导致丢包、错乱，然后采用比较稳定的TCP网络协议进行传输。
为了保证服务器正常运行，可对服务器进行监控，如探针、心跳检测等，而这些仅仅是针对服务器的运行数据和日志分析。为了提高服务器服务的可用性，可进一步实施服务器负载均衡、主从切换、故障转移等。
探针监控是定时去请求访问服务器，需要通过请求回应来收集服务器状态。定时需设置在合理范围值内，太短会给服务器带来压力，太长会导致不能及时收集报错信息而错过最佳时机。基于以上情况，可以采用服务器集群化的方式，根据系统场景，设置合理探针请求频率，当发现异常时及时剔除替换。
【示例】 电商系统
电商系统分为（用户、商品、订单）模块，当用户模块中用户数量逐渐增多时，由于用户模块依赖商品、订单模块，潜移默化会给它们带来高额压力，所以需要监控并跟踪模块之间调用链路的状况，以及时发现并优化调用过程产生的问题，提供系统模块调用直观图，如图1-6所示。
图1-6 电商多模块调用直观结构图
图1-6体现了整个系统的调用链条，包括服务、数据、交互方式、请求频率以及错误率统计，其中，实线条代表运行正常，虚线条表示存在调用缓慢、异常等相关问题。通过上图可以看到应用内部调用服务存在缓慢处理的情况，同时通过数值可以直观看到服务较慢的数量，这些数值可以协助反馈目前系统的运行状态。通过反馈的问题点可以提前预知系统服务的瓶颈，从而优化处理。
系统运行健康变化趋势可以直观体现系统的吞吐量，如图1-7所示。
图1-7 电商多模块调用线性趋势图
从图1-7中可以看出，系统稳定运行占比高达84%，较慢的请求占用15%，这里的较慢指请求过程中由于其他原因导致的运行缓慢，如网络异常、超时等。重点需关注很慢、停滞的请求，这部分请求可反馈出系统应用层面的问题，需要进行特定优化。
由于数据架构需要提供多节点部署，不同节点之间通信存在数据差异，在很多场景下往往会产生脏数据、异常数据，让业务不能正常运转。数据一致性指关联数据之间的逻辑关系是否正确和完整。那么在分布式情况下如何让不同模块之间的数据保证完整性、一致性？
可以从系统构建层面考虑，采用分布式事务处理，牺牲一部分性能去保证数据一致性。
【示例】 电商系统
在购物平台看中一款商品，然后加入购物车，下单成功后生成订单，支付成功后扣除账户余额，然后通知仓库发货，生成物流轨迹。如果商品库存、订单、支付、仓库等应用模块独立部署，各模块之间通过远程调用，则正常流程是所有应用模块调用都正常返回。若出现异常，需要考虑以下场景。
1）商品库存数量已扣除，订单正常下单成功，由于网络异常等原因，提示用户“下单失败”，用户刷新页面后，显示一个“未支付订单”；
2）订单正常下单成功，用户支付成功后，由于网络异常等原因，提示用户“支付失败”，用于刷新页面后，显示“已支付成功”；
3）用户支付成功后，通知仓库发货，由于网络异常等原因，仓库系统未发货，无轨迹；
4）用户支付成功后，通知仓库发货，仓库可能没有货品，但商品数量已扣减，用户余额已扣除等。
系统拆分成多个应用模块后，往往会存在数据不一致性等问题，不同模块之间通过远程调用存在多种不确定因素，如调用过程中顺序不同，网络、宽带、超时等一系列问题，增加了系统复杂性。
假如把商品库存、订单、支付、仓库多个应用模块并行调用，也就是同时调用这些模块进行业务处理，由于同时调用不同模块存在延迟、网络异常等情况，需要设定合理的超时机制。并行执行过程中任意模块执行失败或者超时时，模块执行状态差异需要通过消息发布/订阅等模式，通知以上全部模块进行失败处理，相关模块收到消息后，进行幂等处理，进而执行失败处理。
注意
保证消息发布/订阅的可用性、可靠性，让业务模块都能正常接收消息。任意模块执行失败或者超时等情况出现时，由于涉及模块众多，业务复杂，应通知相关模块进行失败处理。