由于工作的原因，近两年多的时间开始接触分布式系统，在学习分布式系统之前，我认为的分布式仅仅就是把系统模块化独立部署，模块化之间采用webservice等可远程调用的方法进行连接，共同协助完成一个实际的业务流程，当然了，分离带来的部署复杂度也增加了，但是毕竟是分布式系统架构，这个缺点还是可以接受的，类似这样的概念，在我的潜意识中存在的很多年，直到近两年对分布式系统的 粗浅的学习，才发现里面涉及太多的细节，大量的这些细节其实都是在弥补分布式系统的天生不足，当然，采用分布式系统的好处也是显而易见的。毕竟，利大于弊，特别是近几年的互联网、电商等的飞速发展，面对高并发的用户请求，在优化到一定程度下，只能把架构从单机版向分布式迁移，才能满足日益增加的系统用户的体验。
上述开篇废话较多，分布式系统存在如下的几方面的先天不足，每一条都会架构师感到揪心，特别是处女座的架构师（哈哈），记得以前的一句歌词，用谎言来满足谎言，类似现在的场景，引入新的技术需要解决当前的问题，但是引入新技术的同时，还要继续引入其他的技术来屏蔽前者的不足，这貌似是一个无解的道路，一条没有尽头的道路。
分布式下首当其冲的就是 【网络的不稳定性】，作为分布式架构，这个是首先需要纳入考虑的一点，分布式下，系统之间的功能调用时基于网络传输的，与API方式比较，网络带来了不稳定性与延迟性。不稳定性是指 网络的网线可能在传输的过程中断掉，或者网络拥堵造成的网络堵塞，毕竟核心交换不是单独给一个服务器使用的。
第二点就是【网络的延迟性】，延迟性带来的最直接的不好体验就是用户使用时等待的时间可能较长，延迟是一个动作，延迟的时间则是一个不确定的因素，一个不确定的因素在 网络频繁的交互下，会引起蝴蝶效应一样的结果。所以 这一点也是作为架构师需要考虑的，就是不同模块之间的远程调用 需要有一个总的时间等待限制，超过这个时间范围，无论结果如何 都作为异常进行处理。
第三点则是【网络带宽是有限的】利用网络传输，相对比本地硬盘的IO 一定会存在瓶颈，而且这种瓶颈更加有可能出现在网络风暴时，这个时候就是考研分布式系统架构抗外界干扰性了时候了，在网络带宽有限的情况下，适当的采用队列技术，降低并发高峰期的网络风暴，从而换取系统的稳定性，还是有着一定的参考意义的
第四点【网络是不安全的】一旦数据库是网络的另外一端传递，则一定需要对对方的身份进行确认，第一种是采用身份确认的方式，保证对方系统的合法性，或者采用传输消息内部的 数字签名等，用于验证对方身份的合法性，另外一点就是采用加密传输协议等，充分的考虑分布式系统之间网络传输过程中的不确定性。
第五点【网络的异构型】这个在分布式系统下是一种常见的场景，很多系统会采用分层架构，从安全性考虑，不同的层次会分配在不同的网络规划区，而不同的网络规划区会采用各种各样的网络策略，以及中间架设N中网络物理设备，用于构建安全的网络，在这种情况下，就需要考虑 系统通信采用的协议了，一般而言 基于http协议是最好的选择方式，他可以消除许多TCP/IP 协议传输带来的很多问题
第六点【消息的投递与确认】 分布式系统下，网络的不稳定 会让系统消费者不知道自己的远程调用是否成功，这个时候就需要提供一个 反馈机制说明远程调用是正常投递并且得到了合法的响应，针对这个问题，很多企业都选用MQ 来保证消息的投递。
第七点 【方法的幂等性设计】 网络问题会导致引入的一些 消息中间件 造成消息重发等，在这种状态下 需要考虑方法调用的幂等性，通俗来讲 就是同样的业务请求，无论调用多少次，处理的结果都是一致的。设计这个代价就比较高。
第八点 【接口返回参数的自我描述性】 异构系统之间的传输，时面型接口协议的，一般协议除了定义正常模式下的数据返回，同时也要描述异常情况下的错误返回，尽可能的封装异常在接口调用内部，而不是通过传输协议传递异常，这样对不同系统之间的调用带来了一致的 接口返回确认机制，特别是 基于http协议，它有很多预定义的状态码 而这些状态吗就可以很好的 阐述 网络调用下的各种异常。
第九点【分布式系统构建ACL层】不系统之间的接口依赖，在远程调用的ACL设计，保证多变的通信协议不会影响到 模块内部的核心领域
第十点【分布式事务】 这个一直都是一个头大的难题
第十一点 【长时间处理过程状态的方案选型】：待补充
