垂直架构与RPC

一、垂直架构图

垂直架构图.png
垂直MVC项目主要有表现层，业务逻辑层，数据访问层组成的MVC架构，项目部署在一个web容器上，适合于 访问量小，用户数不多的业务。
作为一个大而全的项目，主要有以下的缺点：

1. 这是一个大而全的项目，项目的部署效率很低，代码全量编译和部署一次发布需要很长时间，更重要的是 如果某个功能出错有问题，所有的功能都需要再重新打包编译，部署效率极低。
2. 团队协作难度高，如多人使用SVN很可能在同一个功能上，多人同时进行了修改，作为一个大而全的项目，可能个人只是需要开发其中一个小的模块的需求，却需要导入整个项目全量的代码。
3. 系统的可靠性变差，即使是使用负载均衡，假设其中一个节点由于内存溢出而导致宕机，则一个节点故障，其他节点会分摊这些流量，同样的问题还是存在，很可能引起“雪崩”。

集群

对于上面的MVC垂直架构，一个大而全的项目放在一个web容器上，当访问量用户数不断增多的时候，光靠一台web容器工作，宕机的几率和带来的风险都是很高的。对此，人们想到，一台机器有风险，那就多来几台机器一起分担分担呗，于是，就有了集群。

负载均衡.png

客户端发送web请求到nignx服务器上，nginx服务器根据集群上的tomcat负载情况，将请求转发给最合适的web容器，从而实现负载均衡。
正向代理： 比如说VPN，浏览器将请求发送给VPN，vpn再将请求发送给目标，隐蔽了发送者的信息。
反向代理： 隐蔽了 目标的信息。

RPC架构

RPC是指远程过程调用，也就是说两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的函数/方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。
构建RPC架构需要解决考虑的问题：

1. 通讯问题，客户端和服务端是按需连接还是长连接
2. 寻址问题
3. 序列化和反序列化

RPC架构这里我使用过的是Dubbo，RPC架构可能存在的问题：

1. 服务多。
2. 服务间关系复杂，哪个服务需要先启动，哪个服务才能启动。
3. 每个服务的调用量不同，可能需要根据具体的调用量，对该服务加载机器。
4. 可能需要对具体的一些服务，做安全权限控制。

对此，需要一个治理中心dubbo-admin。