APP架构设计

客户端包括web浏览器端，移动手机端，用户通过客户端发送一个请求后，Nginx接收到请求后，会做负载均衡，定向到当前最适合（相对没那么繁忙）处理这个请求的服务器端，服务端接收到请求后，再访问数据库，一些热点数据需要做缓存，比如淘宝首页的商品。从上面的图中看，服务器端的某一个出现故障后，nginx会将请求定向到剩下的能正常运行的服务器上面，而数据库端也是采用的集群，这样就达到了高可用，就是任意一台机器出现故障，对整个网站的运行不会产生太大的影响，这里可能有人会问如果nginx这台服务器出现问题了怎么办？可以做虚拟ip（vip）,配置主从入口，就是nginx1和nginx2的虚拟ip是一样的，其中有一个是主入口，在主入口没有出现问题的时候，从机是不会工作的，当主入口机出现问题了，从入口机就会顶替，如果主从都出现问题了，那网站将无法访问。

服务器端的spring与spring之间的调用又是如何的？现在都是分布式调用，比较经典的是dubbo+zookeeper。这里有同步调用和异步调用。

同步调用：提出问题的一方直接调用处理问题的一方。

异步调用：提出问题的一方将问题交个消息中间件，由消息中间件去将问题发放给处理问题的一方，在这里，提出问题的一方称为“生产者”，处理问题的一方称为“消费者”，他们彼此是不知道对方是谁，达到业务解耦的效果，这样做的好处是以后在部署项目、程序的升级、接口的变更的时候，它的影响面就很小。比如说生产者项目开发地有问题，然后用其他语言再做了一个项目，对消费者不会产生任何影响，只要生产生能正常往消息队列里面发送消息就好；再比如用户注册一个淘宝账号，我们连带着把支付宝账号也给你开通，然后其他的投资的项目也给用户一些优惠（给你2张淘票票的电影票，免费一个月的虾米音乐会员等等），对应淘宝这一端，它发起一个消息传达给消息队列，至于接收端是支付宝还是淘票票还是虾米音乐，淘宝这一端不知道也不需要关心，等以后阿里再有什么投资项目需要给新用户优惠的时候，只需要从消息队列里接收消息就可以，对生产者而言，没有任何影响。如果是同步调用（dubbo或者webservice调用），其中一端有修改，另一端必然也要改，这种强耦合是不好的。
以下是异步调用方案图：