架构设计过程中的传输延时考量

       对于绝大部分后台开发人员来说，工作核心关注点在于设计高性能(承载请求量大)、低延时(平均延时低，延时波动小，最高延时低)、高可靠性(程序不轻易崩溃)、高稳定性(程序运行一个星期后，跟刚启动时没有明显区别，不能刚启动时表现好，运行一个星期后就各种无响应)、高安全性(对安全性有适当的考量)的架构。通常情况下的网络应用并不侧重其中任何一点，而是要求总体没有明显短板即可。然而对于游戏后台而言，低延时、高稳定性显得尤为重要。

       在当前常见的架构设计中，单层架构(这里说架构是业务逻辑的层面，在当前云计算大势已定的情况下数据存储层的分离是必然的需求)是很难满足业务需求的。尽管不排除单层架构适用于部分场景的业务需求，也不排除少数优秀的攻城狮可以设计出单层架构的程序来满足较为复杂的业务需求，但是摒弃对单层架构的执着和偏执，可以带来单层架构前提下无法满足的优势，比如业务灵活性。

        那么问题来了：如果摒弃单层架构，那么多层架构不同架构层之间的访问要付出什么样的代价？

        1. 机器成本是显而易见的，毕竟增加了计算量以及数据通信成本；

        2. 延时增加；

        3. 其他开支。

        这里只对延时增加展开考量。第一点是平均延时增加了多少，第二点是最高延时增加了多少，第三点是是否会产生消息丢失。按照“勇往直前”的思维，我们就需要写程序进行测量，尽管这是不到500行代码可以搞定的事情，然而自己写代码来测量这三个因素也许得到的结果并不客观。因为自己写的代码，还是可能有失公允的。

        我们这样分析：

        1. 这三个数据与传输协议相关，也与源地址和目标地址之间的网络距离有关；

        2. 如果源地址和目标地址相同，那么通信协议除了TCP/IP协议族，还可以使用本机的通信；

        3. 如果使用TCP/IP协议族通信，无论采用TCP，UDP还是自定义协议，对这三个数据的评估结果，都某种程度上类似于PING的结果；

        4. 这三点数据跟机器的网络负载有关；

        5. 这三点数据跟机器的CPU负载，内存使用情况也相关。

 

        因此无需写应用程序，直接使用ping结果即可分析。然而，高负载的情况下表现如何，还是要表演真正的技术。