这里的架构演进应该是从服务化的角度来说，应该说随着业务发展，应用规模扩大，系统的一些公共服务就会抽取出来，独立开发，部署，维护，用来解决并发，扩展，维护的问题。
传统垂直架构
有的地方也叫单体应用，以mvc模式开发：
所有应用代码统一打包，代码所有接口本地api调用，很少存在远程服务调用;
单机或主备，应用做集群部署；
DB主从等。
这种并没有什么不好，发展初期大多是这样，体量没那么大，也不需要考虑高并发大流量可扩展性什么的，简单粗暴，解决业务需求就好，活下去才能活的更好。
但是必须明白这种简单架构存在的一些问题：
1.业务不断发展，功能逐渐增多，应用的开发维护成本变高，部署效率降低，随便改个代码，编译一次十几分钟就浪费了。悲剧，我们有个系统才开发3年，就碰到这种情况，一次打包编译部署，13分钟结束。
2.不同的人负责不同的部分，一些通用代码、公共代码就各写各的，不能复用，如果只是util还好，但是一些外部服务的都有重复，那就happy了（不过这种情况的出现，不一定是架构问题，更多可能是管理）；
3.不断地上新需求，不断地改代码，有时测试不到位，指定哪里埋了bug，上生产后系统就down了，牵一发而动全身；
4.可维护性，可靠性，扩展性变差。
既然有这些问题，就要解决啊，业务就会提要求，你要解决啊，要不然影响我业务发展，影响我ipo上市啊，苦逼的码农开始干活了。
不提应用的拆分主从那些手段，但从拆分后应用交互看，原来的本地api交互变成的远程api的调用，这里就出现了rpc，当然也有走esb，webservice。其实拆分后挺麻烦的，光一个分布式事务就能折腾死人。
RPC架构
RemoteProcedureCall，远程方法调用，屏蔽底层实现细节，像调用本地方法一样调用远程服务。
上个作者的图：
这个图对于大多数rpc框架通用，实现的几个技术点：
1.服务提供者发布服务：服务接口定义，数据结构，服务提供者信息等；
2.客户端远程调用：通常是使用jdk的代码代理拦截；
3.底层通信：现在应该更多是使用netty吧，当然也有走支持