货拉拉应用架构的演进堪称单体微服务实现的避坑指南演进将为企业带来更多价值：职责解耦、能力复用、关注点分离、通信效率提升、快速演进、快速交付，快速反馈。本次分享主要围绕应用架构的演进和货拉拉微服务治理的技术选型展开。1.应用架构的演进应用服务架构一直处于不断演进的过程中。上图通过五种主流架构模型的对比展示了应用架构的演进和变化。1.单体架构在业务发展初期，为了快速实现应用和满足客户需求，一般采用AllinOne单体架构。单体架构的特点是：在每个节点服务器中，替换应用程序的所有功能模块代码和其他模块耦合在一个进程中。而且版本升级开销非常大。使用负载均衡来分配访问会话并提高并发处理能力。单体架构是一种以Web容器的打包和部署为核心的架构模式。随着业务的快速发展，需要实现服务的快速迭代和快速交付，应用架构也演变为以服务为中心的架构模式。2、RPC架构RPC架构在应用系统早期还是比较常见的架构模式，就是增加一个服务层，将冗余代码和可复用的业务应用拆分和提取出来，打包成服务。系统架构更清晰，代码质量提升，易于升级维护，稳定性高。应用层可以更专注于与前端用户的交互。业务处理在服务层进行。服务和应用程序的管理不是自动化的。服务层可以实现HA的功能，适用于中小型WEB系统场景和高并发场景，性能更好。RPC是典型的RPC架构。RPC架构也存在一些问题。远程方法调用是通过共享分布式对象来实现的。如果将属性添加到其中一个对象，它将影响共享对象的生产者和消费者。因此，RPC架构也是一种紧耦合模型。系统交互采用RPC私有TCP协议，服务生产者和消费者之间存在很强的代码依赖，对异构系统集成不友好。3、SOA架构我个人认为SOA架构经历了两个阶段，一个是以ESB为中心的架构，一个是以注册服务为中心的服务注册发现架构（上图）。1）ESB集中式架构ESB集中式架构实现松耦合，依托ESB消息总线技术实现异构系统的信息交互和一体化集中式架构管理。因此，它虽然是面向服务的，但本质上还是一个Centralized的架构。它的优势在于：基于WebService技术，具有重量级的消息通信机制。当团队规模较大，需要实现异构系统集成时，可以提供统一的解决方案和技术实现方法，快速集成异构系统的对外服务。2）以注册服务为中心的服务注册发现架构。注册中心负责服务地址的注册和查找，相当于目录服务；服务提供者和消费者只有在启动和订阅后发生变化时才会与注册中心交互。注册中心无转发请求，压力小；应用层和服务层可根据需求动态横向扩展，应用和服务实现负载均衡；通过随机、轮询、权重等策略和开放标准化的框架，满足接口调用的要求所有服务都可以接入服务框架（RPC）监控服务调用，服务层可以进一步分层，可以根据业务需求和业务运营，对业务进行编排、梳理和服务。以注册服务为核心的服务注册发现框架，适用于大型、超大型网站应用框架。因此，ESB集中式架构的问题也很明显：集中式架构难以满足灵活的服务迭代和需求交付。4、微服务架构微服务架构实现了系统解耦和持续集成，服务边界清晰。与ESB架构和传统SOA架构相比，粒度更小，采用轻量级通信机制（HTTP+REST）进行交互。具有更强的扩展性和弹性，可以更加灵活，更快地响应业务变化。5.服务网格架构服务网格架构是容器化的产物。它引入了类似于代理的sidecar，保留了微服务SDK中的协议编解码能力，集成了服务注册与发现、负载均衡、熔断、限流、降级等功能。服务治理能力下沉到Sidecar。当Sidecar在微服务中被大量部署时，这些Sidecar节点自然形成了一个网格。服务网格架构优势：支持多语言业务开发，节省或轻量SDK，为异构服务框架/平台创造融合发展机会，让服务框架/平台的演进更加自主敏捷，让业务发展聚焦业务本身，无需关心安全、灰度、熔断、限流、降级等通用服务。治理能力更敏捷，管控更好，业务探索加速。ServiceMesh的终局：Mesh的所有协议或框架。目前，货拉拉已经实现了RedisMesh。通过以上对比不难发现，应用服务架构是在不断演进的，其演进背后是有一定逻辑的。服务架构的演进主要取决于以下两个维度：业务维度，技术架构由业务发展决定。它是由业务的时期和阶段决定的，必须能够解决业务发展过程中的痛点。在选择架构时，需要考虑架构是否能够满足当前业务的需求，以及业务需求是否可以随着架构的演进进行增量迭代。在技??术方面，需要满足非功能性需求，让业务快速跟上技术生态的发展。综上所述，应用架构演进的底层逻辑是：一切为了敏捷（低投入，快速满足业务需求）。2.货拉拉的AllInOneWeb转微服务管理货拉拉的应用架构经历了AllInOneWeb单体架构、RPC架构，以及现在的微服务架构。单体架构阶段：2014年发布的第一个版本是PHP的AllInOneWeb，一直持续到2016年。RPC架构阶段：2016年以来，业务量不断增加，单体架构难以满足业务需求。数十个dcore、ucore和其他核心服务已从整体应用程序中删除。虽然服务之间使用HTTP+REST代替RPC，但是这个阶段和RPC架构一样，不具备服务治理能力。微服务阶段：2020年开始微服务转型，到现在还在微服务阶段。一、货拉拉微服务治理背景1）微服务改造遇到的问题。2020年开始微服务转型，当时属于类似RPC的架构，基于域名+HTTP服务交互方式（上图）。痛点是：域名化管理的成本非常高：服务调用仍然使用域名，内部新业务必须申请内部域名。当时有近500个域名，域名的维护成本非常高。协议不一致：PHP和Java服务调用采用HTTP+JSON协议方式，但服务请求方式不统一，导致研发效率低，插入管理难度大。当时内部业务协议请求方式有GET请求方式、JSON数据POST方式带HTTPBODY、HTTPFORM表单方式。无服务治理能力：无服务注册中心，无熔断、降级等保障能力。服务之间有很强的关联，调用链很脆弱。如果一个侧支服务不可用，可能导致整个关键环节不可用，稳定性无法保证。技术改造：公司业务发展迅速，大部分业务仍采用PHP开发。它需要转换为Java或使用Java进行重构。内部500+应用/服务不能同时进行改造重构，需要逐步推进。2）微服务跨语言需要解决的问题：支持内部PHP和JAVA服务相互调用。时间窗口：开发周期3个月左右。服务治理能力：具备熔断、限流、降级等服务治理能力，以及全链路灰度发布能力。协议兼容要求：通用的调用能力（需要类似FeignClient的调用方式，兼容老的PHP和Java服务）。协议规范要求：提供标准化RPC的能力。服务注册发现：基于AppID的方式，兼顾后续容器化ServiceMesh方式的服务治理需求。2.货拉拉微服务治理的框架选择基于以上需要解决的问题，技术选择和参考框架：SOA架构：Dubbo微服务架构：SpringCloud服务网格架构：Istio内部基础设施还没有全面容器化，所以服务网格架构方法Istio先被淘汰，剩下的就是Dubbo和SpringCloud。我们选型思维的出发点：框架的缺点或不足是否可以被我们接受或克服。1）Dubbo2.X的缺点2020年，Dubbo3.0还没有发布，于是研究了Dubbo2.X。Dubbo2.X协议对云原生支持不友好；Dubbo2.X不支持熔断、限流、降级等服务治理能力，需要Sentinel等额外的框架支持；Dubbo3.X发布时间和版本稳定时间未知；强RPC契约，无泛化调用能力，不兼容老Java、PHP服务需求；Dubbo2.X是基于接口/服务（Inteface/Service）的服务注册发现方式，ServiceMesh未来的方向是基于APPID的服务注册发现方式，支持不友好。2）SpringCloud的缺点是臃肿，系统过于复杂，不够轻便。虽然使用门槛低，但深入改造成本高；打包后的包太大，一般大于100M，启动后占用内存比较大；service调用协议采用HTTP+REST方式，协议控制能力较弱。3）自研微服务框架我们对比后得出的结论是自研微服务框架。具体微服务体系中的组件选择和设计考虑如下：标准服务调用协议：JSON-RPC（支持Java和PHP服务相互调用）；登记处：领事；服务治理：融合Hystrix（Hystrix有PHP版本支持）；泛化调用：参考FeignClient的client和jsonrpc4j服务定义机制；框架设计：参考了Dubbo的分层机制和优秀的设计。3、货拉拉微服务治理的框架设计参考了Dubbo代码的分层架构和优秀设计：dubbo-commondubbo-configdubbo-filterdubbo-metadatadubbo-monitordubbo-registrydubbo-remotingdubbo-rpcdubbo-serializationdubbo-springboot1)广义调用实现方式①参考FeignClient定义接口方法@FeignClient(value="XC-SERVICE-MANAGE-CMS")，其中XC-SERVICE-MANAGE-CMS为下游应用的APPID，FeignClient以APPID的形式发现服务SpringCloud系统。②参考jsonrpc4j接口定义方法@JsonRpcService("/path/to/MyService")interfaceMyService{...servicemethods...}③广义调用接口定义方法④标准JSONRPC接口定义方法2)服务治理能力整体实现融合能力：集成Hystix框架。治理配置：整合公司内部的配置中心。监控能力：整合公司内部监控中心。治理控制台：开发治理控制平台soa-admin。服务治理控制平台：soa-admin控制台3）JavaAgent版本服务治理能力实现方法服务治理能力下沉到JavaAgent；JavaAgent是模块化和插件化的。目前插件包括Metric、Trace、SOA；JavaAgent插件支持动态升级和灰度升级。4、货拉拉微服务治理的未来规划，未来将向ServiceMesh演进，但生产落地仍有挑战。1）增加的复杂度在已经很复杂的环境中引入代理、sidecar等组件，会大大增加运维的复杂度。2)需要专业知识在容器编排器（如Kubernetes）之上添加像Istio这样的服务网格通常需要操作员成为这两种技术的专家。3)延迟服务网格是一种侵入式的复杂技术，会显着增加服务架构的延迟。4）平台依赖性ServiceMesh的侵入性迫使开发人员和运维人员必须适应高度自治的平台并遵守其规则。
