在业务发展初期，为了快速落地应用、满足客户需求，一般会使用All in One的单体架构。

单体架构的特点是：在每个节点服务器中，包换应用的全部功能模块代码等所有模块都耦合在一个进程里，系统完全封闭且很复杂，牵一发动全局；应用系统很臃肿，维护和版本升级开销非常大。使用负载均衡分散访问会话，提高并发处理能力。

单体架构是围绕web容器打包及部署的架构模式，随着业务的快速发展，要求实现服务的快速迭代和快速交付，应用架构也演进为以服务为中心的架构模式。

RPC架构在现在应用系统的早期还是比较常见的架构模式，就是增加服务层，把冗余的代码和可以复用的业务应用进行拆分提取，封装成服务。系统架构更加清晰，代码质量提高，利于升级和维护，稳定性高。应用层可以更专注于与前端用户交互。业务处理放在服务层来进行，服务和应用的管理不是自动化，服务层能够实现HA的功能，适用中小型WEB系统的场景和高并发场景，性能比较好。RPC就是一个典型的RPC架构。

RPC架构也存在一些问题，通过共享分布式对象实现远程方法调用，如果在其中一个对象中添加一个属性，就会对共享对象的生产者与消费者产生影响，所以RPC架构也是紧耦合的模式。系统交互采用RPC私有TCP协议，服务生产者和消费者存在强代码依赖，对异构系统集成不友好。

个人认为SOA架构经历了两个阶段，一是以ESB中心化的架构，二是以注册服务为中心的服务注册发现架构（上图）。

1）ESB中心化架构

ESB中心化架构实现了松耦合，依赖于ESB消息总线技术实现异构系统的信息交互和集成集中式架构管理，因此它虽然是面向服务的，但它本质上依旧是一个中心化的架构。

其优势在于：基于WebService技术，拥有重量级的消息通讯机制。当团队规模比较大、要实现异构系统集成时，它可以提供统一的解决方案和技术实现方式，快速集成异构系统对外服务。

2）以注册服务为中心的服务注册发现架构

• 注册中心负责服务地址的注册与查找，相当于目录服务；

   

• 服务提供者和消费者只在启动和订阅后发生变化时与注册中心交互，注册中心不转发请求，压力较小；

   

• 应用层和服务层可以根据需求进行动态水平扩展，应用与服务实现负载均衡；

   

• 通过随机、轮询、权重等策略与开放式、标准化的框架，满足接口调用的服务都可以接入服务框架（RPC）监控服务调用情况，可进一步对服务层再分层，根据业务需求和服务运行情况对服务进行编排、梳理以及服务治理。

   

以注册服务为中心的服务注册发现架构适用大型及超大型网站应用架构。所以ESB中心化架构的问题也比较明显：中心化架构难以满足灵活性的服务迭代和需求交付。

微服务架构实现了系统解耦和持续集成，有清晰的服务边界，相对ESB架构和传统SOA架构来说粒度更小，使用轻量级的通讯机制（HTTP+REST）交互，具备更强的扩展性和弹性，能够更灵活、更快响应业务变化。

综上所述，应用架构演进的底层逻辑就是： 一切为了敏捷（低投入，快速满足业务需求）。

货拉拉应用架构到现在为止经历了All In One Web的单体架构，RPC架构，与现在的微服务架构。

@FeignClient(value= “XC-SERVICE-MANAGE-CMS”)

@JsonRpcService("/path/to/MyService")interface MyService {... service methods ...}