应用架构演进

这里的架构演进应该是从服务化的角度来说，应该说随着业务发展，应用规模扩大，系统的一些公共服务就会抽取出来，独立开发，部署，维护，用来解决并发，扩展，维护的问题。

传统垂直架构

有的地方也叫单体应用，以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个点。

SOA服务化架构

感觉soa架构应该是在rpc之前出现，用来解决异构系统的交互，通常的实现是通过ESB，WSDL来处理。其粒度通常来说是比较粗的。也存在服务治理方面的问题。

微服务

MSA也是一种服务化架构风格，正流行ing，服务划分

1. 原子服务，粒度细;

2. 独立部署，主要是容器;

分享篇文章:云栖肥侠的文章 微服务(Microservice)那点事 。

MSA与SOA的对比:

服务拆分粒度:soa首要解决的是异构系统的服务化，微服务专注服务的拆分，原子服务;

服务依赖:soa主要处理已有系统，重用已有的资产，存在大量服务间依赖，微服务强调服务自治，原子性，避免依赖耦合的产生;

服务规模:soa服务粒度大，大多数将多个服务合并打包，因此服务实例数有限，微服务强调自治，服务独立部署，导致规模膨胀，对服务治理有挑战;

架构差异:微服务通常是去中心化的，soa通常是基于ESB的;

服务治理:微服务的动态治理，实时管控，而soa通常是静态配置治理;

交付:微服务的小团队作战。

感觉在有了docker后，微服务这个概念突然火了起来，总结就是微服务+容器+DevOps。

分布式服务框架入门

背景

应用从集中式走向分布式

随着业务的发展导致功能的增多，传统的架构模式开发，测试，部署整个流程变长，效率变低，后台服务的压力变大，只能通过硬件扩容来暂时缓解压力，但解决不了根本性问题:

应用规模变大，开发维护成本变高，部署效率降低;

代码复用:原来是本地api调用，导致一些公用功能可能是按需开发，不统一，随意等问题;

交付面临困难:主要是业务变得复杂，新增修改测试变得困难，拉长整个流程。

文章来源：《电脑编程技巧与维护》 网址: http://www.dnbcjqywh.cn/zonghexinwen/2020/0824/401.html