应用架构演进 这里的架构演进应该是从服务化的角度来说，应该说随着业务发展，应用规模扩大，系统的一些公共服务就会抽取出来，独立开发，部署，维护，用来解决并发，扩展，维护的问题 。
传统垂直架构
有的地方也叫单体应用，以mvc模式开发：
- 所有应用代码统一打包，代码所有接口本地api调用，很少存在远程服务调用;单机或主备，应用做集群部署；DB主从等 。
但是必须明白这种简单架构存在的一些问题：
1. 业务不断发展，功能逐渐增多，应用的开发维护成本变高，部署效率降低，随便改个代码，编译一次十几分钟就浪费了 。悲剧，我们有个系统才开发3年，就碰到这种情况，一次打包编译部署，13分钟结束 。
2. 不同的人负责不同的部分，一些通用代码、公共代码就各写各的，不能复用，如果只是util还好，但是一些外部服务的都有重复，那就happy了（不过这种情况的出现，不一定是架构问题，更多可能是管理）；
3. 不断地上新需求，不断地改代码，有时测试不到位，指定哪里埋了bug，上生产后系统就down了，牵一发而动全身；
4. 可维护性，可靠性，扩展性变差 。
既然有这些问题，就要解决啊，业务就会提要求，你要解决啊，要不然影响我业务发展，影响我ipo上市啊，苦逼的码农开始干活了 。
不提应用的拆分主从那些手段，但从拆分后应用交互看，原来的本地api交互变成的远程api的调用，这里就出现了rpc，当然也有走esb，webservice 。其实拆分后挺麻烦的，光一个分布式事务就能折腾死人 。
RPC架构
Remote Procedure Call，远程方法调用，屏蔽底层实现细节，像调用本地方法一样调用远程服务 。
上个作者的图：
这个图对于大多数rpc框架通用，实现的几个技术点：
1. 服务提供者发布服务：服务接口定义，数据结构，服务提供者信息等；
2. 客户端远程调用：通常是使用jdk的代码代理拦截；
3. 底层通信：现在应该更多是使用netty吧，当然也有走支持http的；
4. 序列化：关注序列化反序列性能，xml，json，hessiaon，pb，protostuff，kryo等；
作者给了个socket实现简单demo，来实现远程调用，说明上面几个技术点 。
常用的rpc框架
1. Thrift；
2. Hadoop的Avro-RPC;
3. Hessian；
4. gRPC;
单论rpc的话，没太多可说的，可是如果加上服务治理，那复杂度就几何倍数增长了 。服务治理里面东西太多了，动态注册，动态发现，服务管控，调用链分析等等问题这些问题，单凭rpc框架解决不了，所以现在常用的说的服务化框架，通常指的是rpc 服务治理2个点 。
推荐阅读
- 数码知识：华为mate30怎么设置两个系统 有两个系统吗
- r语言lag函数用法 java怎么把负数转正数
- 联想开机f2修复电脑步骤 联想拯救系统怎么用
- 教大家Windows10系统提示缺少mscomctl.ocx文件的解决方案
- 教大家Windows10系统下word工具栏消失了如何找回的方法
- 王者荣耀一天可以玩几个小时，王者荣耀健康系统时长限制介绍
- 华为手机系统修复教程，这种方法简单又实用
- 教大家windows10系统如何查看内存型号的方法
- erp系统操作方法 财务erp系统是什么软件
- 自助建站系统哪个好，国内最大自助建站介绍