架构的演技是有原因的：
当一个模块直接调用另外一个模块，当被依赖的模块的发版影响了调用方，就需要考虑是否中间通过一个代理层
来屏蔽这种发版感知，当然，也不一定非要这样，但是如果发版非常频繁，或者必须保证调用者不能感知到
这种发版变化，就需要添加一个代理层，这个代理层的作用也就不仅仅是屏蔽发版感知，也要做一些负载均衡等功能；
为什么要做负载均衡呢。因为一个服务调用另外一个服务，如果是一对一的还好说，不过现在都是分布式的，所以，
被依赖的服务一般都是多实例的甚至要按照分布式的集群来对外提供服务，因此，如果把负责均衡的功能放到
调用方，那么是不恰当的，更糟糕的情况是，如果调用方的语言非常杂，那么就要每个客户端都要实现一个负载均衡的功能模块。
而且，从架构上来讲，让客户端来实现负载均衡，也是耦合的，不适合大型应用的开发和维护；
所以，架构的演进是一个进化的过程，当没有收到外部刺激的情况下，也许保持系统的平衡与不变是很恰当的。
因此，时机很重要，这个时机要考虑的因素非常多，比如说成本，时间，以及复杂架构的维护成本等等。
往细的地方说，代理一般都是作用在用网络调用的环境下。假设A服务通过网络调用B服务，那么A和B之间一定有一个
网络协议，这个协议可能是公网协议，也可能是内网协议。可能是公有协议，也可能是私有协议。但是一般情况下，
都是基于TCP之上的一些应用层协议，比如http或者http,如果是应用层协议，那么可以借助一些开源的组件，比如Nginx,
apache等。
如果是一些建立在tcp之上的自定义协议，那么就需要好好设计一个代理层组件了；
提出一个问题：nginx支持自定义的tcp协议吗？
说点题外话：融会贯通，意思是指各方面的知识或道理融合贯穿起来，从而得到系统透彻的理解；那么没有多方面的知识是无法做到
融会贯通的，所以多方面知识的学习是基础和前提；这还不够，也要多思考，就要贯通；
多方面的知识可以通过经验获取，也可以通过多读书获取，但是读书也不是饥不择食，要有选择的读好书，读经典的书，
毕竟人的时间是有限的；
在工作中，碰到的问题越多，就需要你担当的责任多，因为你接触的多了，再加上你乐于发现问题，面对问题，总结问题和勤于思考，
那么你就会潜在的通过问题驱动思考和学习，这种方法是很好的。因为从问题中来，到解决问题中去。能够产生更直接的价值和输出；