应用服务架构一直处于不断演进的过程中，上图通过对比5种比较主流的架构模式，展示了应用架构的演进历程和变化。
1、单体架构
在业务发展初期，为了快速落地应用、满足客户需求，一般会使用AllinOne的单体架构。
单体架构的特点是：在每个节点服务器中，包换应用的全部功能模块代码等所有模块都耦合在一个进程里，系统完全封闭且很复杂，牵一发动全局；应用系统很臃肿，维护和版本升级开销非常大。使用负载均衡分散访问会话，提高并发处理能力。
单体架构是围绕web容器打包及部署的架构模式，随着业务的快速发展，要求实现服务的快速迭代和快速交付，应用架构也演进为以服务为中心的架构模式。
2、RPC架构
RPC架构在现在应用系统的早期还是比较常见的架构模式，就是增加服务层，把冗余的代码和可以复用的业务应用进行拆分提取，封装成服务。系统架构更加清晰，代码质量提高，利于升级和维护，稳定性高。应用层可以更专注于与前端用户交互。业务处理放在服务层来进行，服务和应用的管理不是自动化，服务层能够实现HA的功能，适用中小型WEB系统的场景和高并发场景，性能比较好。RPC就是一个典型的RPC架构。
RPC架构也存在一些问题，通过共享分布式对象实现远程方法调用，如果在其中一个对象中添加一个属性，就会对共享对象的生产者与消费者产生影响，所以RPC架构也是紧耦合的模式。系统交互采用RPC私有TCP协议，服务生产者和消费者存在强代码依赖，对异构系统集成不友好。
3、SOA架构
个人认为SOA架构经历了两个阶段，一是以ESB中心化的架构，二是以注册服务为中心的服务注册发现架构（上图）。
1）ESB中心化架构
ESB中心化架构实现了松耦合，依赖于ESB消息总线技术实现异构系统的信息交互和集成集中式架构管理，因此它虽然是面向服务的，但它本质上依旧是一个中心化的架构。
****
其优势在于：基于WebService技术，拥有重量级的消息通讯机制。当团队规模比较大、要实现异构系统集成时，它可以提供统一的解决方案和技术实现方式，快速集成异构系统对外服务。
2）以注册服务为中心的服务注册发现架构
以注册服务为中心的服务注册发现架构适用大型及超大型网站应用架构。所以ESB中心化架构的问题也比较明显：中心化架构难以满足灵活性的服务迭代和需求交付。
4、微服务架构
微服务架构实现了系统解耦和持续集成，有清晰的服务边界，相对ESB架构和传统SOA架构来说粒度更小，使用轻量级的通讯机制（HTTP+REST）交互，具备更强的扩展性和弹性，能够更灵活、更快响应业务变化。
5、服务网格架构
服务网格架构是容器化的产物，引入了类似代理的Sidecar，在微服务SDK里面保留协议编解码能力，把服务注册与发现、负载均衡、熔断、限流、降级等服务治理能力下沉到Sidecar。当该sidecar在微服务中大量部署时，这些sidecar节点自然就形成了一个网格。
服务网格架构的优势：支持用多语言开发业务、省去或轻量化SDK，为异构服务框架/平台创造了融合和发展的机会，让服务框架/平台的演进更自主、更敏捷，让业务开发聚焦业务本身，无需关心安全、灰度、熔断、限流、降级等普遍服务，治理能力更敏捷、更好管控，加速业务探索。
ServiceMesh的终局：Mesh所有协议或框架。目前货拉拉已经实现了RedisMesh。
通过上述对比，我们不难发现，应用服务架构是在不断演进的，而且其演进背后存在一定的逻辑，服务架构的演进主要取决于以下2个维度：
****综上所述，应用架构演进的底层逻辑就是：一切为了敏捷（低投入，快速满足业务需求）。
二、货拉拉的AllInOneWeb到微服务治理
货拉拉应用架构到现在为止经历了AllInOneWeb的单体架构，RPC架构，与现在的微服务架构。
1、货拉拉微服务治理的背景
1）微服务化碰到的问题
从2020年开始微服务化改造，当时阶段属于类似的RPC架构，是基于域名+HTTP的服务交互方式（图上）。痛点在于：
2）微服务化需要解决的问题
2、货拉拉微服务治理的框架选型
综合上述需要解决的问题，技术选型和参考的框架：
公司内部基础设施还未全面容器化，所以服务网格架构方式Istio先淘汰，剩下就是Dubbo和SpringCloud。我们选型思考的出发点：框架上的缺点或者不足点是不是我们能接受或者克服的。
1）Dubbo2.X的缺点
2020年Dubbo3.0还未Release，所以我们研究了Dubbo2.X。
2）SpringCloud的缺点
3）自研微服务框架
我们对比后的结论是自研微服务框架，具体微服务体系中组件选型和设计思考如下：
3、货拉拉微服务治理的实现思路
框架设计参考Dubbo代码的分层架构和优秀设计：
1）泛化调用的实现方式
①参考FeignClient定义接口方式
@FeignClient(value=“XC-SERVICE-MANAGE-CMS”)其中XC-SERVICE-MANAGE-CMS为下游应用的APPID，FeignClient在SpringCloud体系中以APPID的方式发现服务。
②参考jsonrpc4j接口的定义方式
@JsonRpcService("/path/to/MyService")interfaceMyService{...servicemethods...}③泛化调用的接口定义方式
④标准JSONRPC接口的定义方式
2）服务治理能力整体实现方式
服务治理管控平台：soa-admin控制台
3）JavaAgent版本服务治理能力实现方式
4、货拉拉微服务治理的未来规划
未来往ServiceMesh演进，但生产落地仍有挑战。
1）增加的复杂性
在一个已经很复杂的环境中引入代理、sidecar等组件会极大地增加运维的复杂性。
2）需要的专业知识
在容器编排器(如Kubernetes)之上添加Istio之类的服务网格，通常需要运维人员成为这两种技术的专家。
3）延迟
服务网格是一种入侵的、复杂的技术，它能向服务架构中添加显著的延迟。
4）平台的依赖性
服务网格的侵入性迫使开发人员和运维人员适应一个高度自治的平台，并遵守其规则。