如出一辙的云存储下的数据交互方式和程序访问入口

随着云服务提供商的越来越多，很多小的互联网公司开始考虑使用云服务。可以想象：在不久的将来（或者现在已经出现），用户打开一应用（包括web网页和移动客户端），访问的主要信息内容是某一家公司提供的，但图片可能是从另一个专门负责处理图片的云服务商获取的、视频也可能是从第三家专门负责处理视频信息云服务商得到，这样，网站或应用内容提供商就有更多的时间来管理自己的核心内容，而对于一其它非核心内容，交给更专业的云服务上去处理，比如上面提到的图片和视频。在云服务的模式下，专业的人做专业事，有利于资源的合理利用，也降低了一些小型互联网公司的人力成本和服务器压力，但对于内容维护以及和云服务数据交互的解决方案，还要下一番功夫的，如果前期考虑不够周全，后期可能会更有一番折腾。下面就结合前几天工作中的一些想法整理的两套方案，其中也算是各有利弊吧！

方案一：

方案一图解说明：

1：客户端从主服务器请求访问云服务的token；

2：主服务器返回token值；

3：利用token上传图片到云服务器；

4：客户端接收云服务器返回的结果；

5：客户端把云服务返回的图片路径和其他文本域数据提交主服务器保存。

方案二：

方案二图解说明：

1：客户端把图片上传至主服务器；

2：主服务器生成token，直接与云服务器交互，把图片上传至云服务器；

3：云服务返回处理结果到主服务器；

4：主服务器把图片的处理结果返回到客户端；

5：客户端根据图片的处理结果选择是否继续向主服务器提交其它表单数据。

在以上两种方案中，我个人比较推崇第二种解决方案（其实正是由于在工作中决策者使用了第一种方案，我才有了写这些东西的想法）。

第一种方案号称减少了与主服务器的交互，可以缓解服务器压力，但维护成本太高，别忘了，我这里所说的客户端包括了，web浏览器，手机端的ios和android，说不定在某个时候又要添加其它的平台，和云服务器间的交互的入口太大、代码独立在各自客户端的内部，一旦调整就要调整所有的平台的代码，这恐怕是任何一个程序员不想看到的。

而第二种方案和云服务器交互的口子比较小，客户端不用做任何调整，甚至根本不知道云服务器的存在，其只要做好自己的事，把数据提交到主服务器入口拿到返回结果任务就完成了，即便以后加入其它平台，有可能主服务器代码都不用做任何修改，只要新的平台按规则提交数据到入口就行了。这也是我作为一个喜欢偷懒的程序员比较推崇这种方案原因所在。

有点不靠谱的总结：不仅是这种服务器之间的交互，就平时在写程序也应有这种观点（类似于第二种解决方案，在写程序代码时，我暂且称之为“观点”吧），通俗来说就是：做的一件事（不管业务逻辑上的还是其它的各种解决问题的方案），尽量统一对外界提供小的入口，这种入口越小，我们逻辑就越可控，越容易维护。不然后期有任何哪怕一丁点的修改，也会出现这样那样的问题。