货拉拉应用架构演进，堪称单体落地微服务避坑指南

徐少敏

货拉拉 技能中心 中心基础设施部

Java技能专家

  • 首要担任货拉拉Java开发结构、脚手架、使命调度中心、装备中心、SOA和微服务结构的架构规划及结构和工具在货拉拉技能中心的施行和落地。在互联网、物联网、车联网有多年的运用架构规划与微服务架构转型的施行落地经历。

从单体到SOA架构，再从微服务架构到服务网格(Service Mesh)架构，企业运用架构范畴每一次技能架构的演进都会给企业带来更多的价值：责任解耦、才能复用、关注点别离、沟通功率进步、快速演进、快速交给和快速反应。本次分享首要环绕运用架构演进以及货拉拉微服务办理的技能选型等进行思考。

一、运用架构的演进

货拉拉应用架构演进，堪称单体落地微服务避坑指南

运用服务架构一向处于不断演进的过程中，上图经过比照5种比较主流的架构形式，展示了运用架构的演进进程和改变。

1、单体架构

货拉拉应用架构演进，堪称单体落地微服务避坑指南

在事务开展初期，为了快速落地运用、满意客户需求，一般会运用All in One的单体架构。

单体架构的特点是：在每个节点服务器中，包换运用的悉数功用模块代码等所有模块都耦合在一个进程里，系统彻底关闭且很杂乱，牵一发起大局；运用系统很臃肿，维护和版别晋级开支十分大。运用负载均衡分散访问会话，进步并发处理才能。

单体架构是环绕web容器打包及布置的架构形式，跟着事务的快速开展，要求完成服务的快速迭代和快速交给，运用架构也演进为以服务为中心的架构形式。

2、RPC架构

货拉拉应用架构演进，堪称单体落地微服务避坑指南

RPC架构在现在运用系统的早期仍是比较常见的架构形式，便是增加服务层，把冗余的代码和可以复用的事务运用进行拆分提取，封装成服务。系统架构更加明晰，代码质量进步，利于晋级和维护，安稳性高。运用层可以更专注于与前端用户交互。事务处理放在服务层来进行，服务和运用的办理不是自动化，服务层可以完成HA的功用，适用中小型WEB系统的场景和高并发场景，功用比较好。RPC便是一个典型的RPC架构。

RPC架构也存在一些问题，经过同享分布式目标完成远程方法调用，如果在其间一个目标中增加一个特点，就会对同享目标的出产者与消费者产生影响，所以RPC架构也是紧耦合的形式。系统交互选用RPC私有TCP协议，服务出产者和消费者存在强代码依靠，对异构系统集成不友好。

3、SOA架构

货拉拉应用架构演进，堪称单体落地微服务避坑指南

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

1）ESB中心化架构

ESB中心化架构完成了松耦合，依靠于ESB音讯总线技能完成异构系统的信息交互和集成集中式架构办理，因而它尽管是面向服务的，但它本质上依旧是一个中心化的架构。

**
**

其优势在于： 根据WebService技能，具有重量级的音讯通讯机制。当团队规模比较大、要完成异构系统集成时，它可以提供一致的处理方案和技能完成方法，快速集成异构系统对外服务。

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

**
**

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

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

  • 运用层和服务层可以依据需求进行动态水平扩展，运用与服务完成负载均衡；

  • 经过随机、轮询、权重等策略与开放式、规范化的结构，满意接口调用的服务都可以接入服务结构（RPC）监控服务调用状况，可进一步对服务层再分层，依据事务需求和服务运转状况对服务进行编列、梳理以及服务办理。

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

4、微服务架构

货拉拉应用架构演进，堪称单体落地微服务避坑指南

微服务架构完成了系统解耦和继续集成，有明晰的服务边界，相对ESB架构和传统SOA架构来说粒度更小，运用轻量级的通讯机制（HTTP+REST）交互，具有更强的扩展性和弹性，可以更灵活、更快呼应事务改变。

5、服务网格架构

货拉拉应用架构演进，堪称单体落地微服务避坑指南

货拉拉应用架构演进，堪称单体落地微服务避坑指南

服务网格架构是容器化的产品，引进了相似代理的Sidecar，在微服务SDK里边保留协议编解码才能，把服务注册与发现、负载均衡、熔断、限流、降级等服务办理才能下沉到Sidecar。当该 sidecar 在微服务中大量布置时，这些 sidecar 节点自然就形成了一个网格。

服务网格架构的优势： 支撑用多语言开发事务、省去或轻量化SDK，为异构服务结构/渠道创造了交融和开展的机会，让服务结构/渠道的演进更自主、更灵敏，让事务开发聚焦事务自身，无需关心安全、灰度、熔断、限流、降级等普遍服务，办理才能更灵敏、更好管控，加速事务探究。

货拉拉应用架构演进，堪称单体落地微服务避坑指南

Service Mesh的结局：Mesh所有协议或结构。现在货拉拉现已完成了Redis Mesh。

经过上述比照，咱们不难发现，运用服务架构是在不断演进的，并且其演进背面存在必定的逻辑，服务架构的演进首要取决于以下2个维度：

  • 事务维度， 技能架构是由事务开展所在的时期和阶段决议的，要可以处理事务开展过程中的痛点。在进行架构选型时，需求考虑这个架构是否能满意当前事务的需求，事务需求能否跟着架构的演进完成增量式的迭代。

  • 技能维度， 要满意非功用需求，使事务快速跟上技能生态的开展。

****综上所述，运用架构演进的底层逻辑便是：全部为了灵敏（低投入，快速满意事务需求）。

二、货拉拉的All In One Web到微服务办理

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

货拉拉应用架构演进，堪称单体落地微服务避坑指南

  • 单体架构阶段： 2014年发布的第一个版别便是PHP的All In One Web，一向延续到2016年。

  • RPC架构阶段： 从2016年开端，事务量不断上升，单体架构难以满意事务需求，从单体运用里边拆出几十个dcore，ucore等中心服务。尽管服务之间选用HTTP+REST的调用方法，不是RPC的调用方法，但这阶段和RPC架构一样，都不具有服务办理才能。

  • 微服务阶段： 从2020年开端微服务化改造，一向到现在都还处于微服务阶段。

1、货拉拉微服务办理的背景

1）微服务化碰到的问题

货拉拉应用架构演进，堪称单体落地微服务避坑指南

从2020年开端微服务化改造，其时阶段属于相似的RPC架构，是根据域名+HTTP的服务交互方法（图上）。痛点在于：

  • 根据域名的办理方法本钱十分高： 服务调用都还用域名的方法，内部新服务上线都必须申请内部域名，其时已接近500个域名，域名维护本钱十分高。

  • 协议不一致： PHP和Java服务调用、选用HTTP+JSON的协议方法，但事务恳求方法不一致，导致研制功率低，插入办理切面反常困难。其时内部事务协议恳求方法有GET恳求方法、JSON数据以HTTP BODY的POST方法、还有HTTP FORM表单方法。

  • 没服务办理才能： 没有服务注册中心，没有熔断、降级等保证性才能。服务之间强相关，调用链脆弱。若某旁支服务不可用，或许导致整条关键链路不可用，安稳性无法保证。

  • 技能转型： 公司事务快速开展，大部分事务仍是PHP开发，需求向Java转型或许运用Java来重构。内部500+的运用/服务不能同时转型或许重构，需逐步推进。

2）微服务化需求处理的问题

货拉拉应用架构演进，堪称单体落地微服务避坑指南

  • 跨语言： 支撑内部PHP和JAVA服务相互调用。

  • 时刻窗口： 开发周期3个月左右。

  • 服务办理才能： 具有熔断、限流、降级等服务办理才能以及全链路灰度发布才能。

  • 协议兼容要求： 具有泛化调用才能（需求相似FeignClient的调用方法，兼容老的PHP和Java服务）。

  • 协议规范要求： 提供规范化RPC的才能。

  • 服务注册发现： 根据APPID的方法，考虑到后续容器化Service Mesh方法的服务办理要求。

2、货拉拉微服务办理的结构选型

归纳上述需求处理的问题，技能选型和参阅的结构：

  • SOA架构：Dubbo

  • 服务网格架构：Istio

公司内部基础设施还未全面容器化，所以服务网格架构方法Istio先淘汰，剩下便是Dubbo和Spring Cloud。咱们选型思考的起点：结构上的缺陷或许缺乏点是不是咱们能接受或许克服的。

1）Dubbo2.X的缺陷

2020年Dubbo 3.0还未Release，所以咱们研讨了Dubbo 2.X。

  • Dubbo 2.X协议对云原生支撑不友好；

  • Dubbo 2.X不支撑熔断、限流、降级等服务办理才能，需求别的的Sentinel等结构支撑；

  • Dubbo 3.X Release时刻和版别安稳时刻未知；

  • 很强的RPC契约，没有泛化调用才能，达不到兼容老的Java和PHP服务要求；

  • Dubbo 2.X根据接口/服务(Inteface/Service)的服务注册发现方法，对未来Service Mesh方向即根据APPID的服务注册发现方法支撑不友好。

2）Spring Cloud的缺陷

  • 臃肿、系统过于杂乱、不行轻量，尽管运用门槛低，但深入和改造本钱较高；

  • 打包的包过大，一般都大于100M，发动后占用的内存也比较大；

  • 服务调用协议选用HTTP+REST方法，协议管控才能较弱。

3）自研微服务结构

咱们比照后的结论是自研微服务结构，详细微服务系统中组件选型和规划思考如下：

  • 规范服务调用协议： JSON-RPC（支撑Java和PHP服务相互调用）；

  • 注册中心： Consul；

  • 服务办理： 熔断Hystrix（Hystrix有PHP版别支撑）；

  • 泛化调用： 参阅FeignClient的客户端和jsonrpc4j服务界说机制；

  • 结构规划： 参阅Dubbo的分层机制和优秀规划。

3、货拉拉微服务办理的完成思路

结构规划参阅Dubbo代码的分层架构和优秀规划：

货拉拉应用架构演进，堪称单体落地微服务避坑指南

  • dubbo-common

  • dubbo-config

  • dubbo-filter

  • dubbo-metadata

  • dubbo-monitor

  • dubbo-registry

  • dubbo-remoting

  • dubbo-rpc

  • dubbo-serialization

  • dubbo-springboot

1）泛化调用的完成方法

① 参阅FeignClient界说接口方法

货拉拉应用架构演进，堪称单体落地微服务避坑指南

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

其间XC-SERVICE-MANAGE-CMS为下流运用的APPID，FeignClient在Spring Cloud系统中以APPID的方法发现服务。

② 参阅jsonrpc4j接口的界说方法

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

③ 泛化调用的接口界说方法

货拉拉应用架构演进，堪称单体落地微服务避坑指南

④ 规范JSONRPC接口的界说方法

货拉拉应用架构演进，堪称单体落地微服务避坑指南

2）服务办理才能全体完成方法

  • 熔断才能： 集成Hystix结构。
  • 办理装备： 集成公司内部的装备中心。
  • 监控才能： 集成公司内部的监控中心。

  • 办理控制台： 开发办理管控渠道soa-admin。

货拉拉应用架构演进，堪称单体落地微服务避坑指南

服务办理管控渠道：soa-admin控制台

货拉拉应用架构演进，堪称单体落地微服务避坑指南

3）Java Agent版别服务办理才能完成方法

  • 服务办理才能下沉到Java Agent；

  • Java Agent模块化、插件化，现在插件有Metric、Trace、SOA；

  • Java Agent插件支撑动态晋级和灰度晋级。

货拉拉应用架构演进，堪称单体落地微服务避坑指南

4、货拉拉微服务办理的未来规划

未交游Service Mesh演进，但出产落地仍有挑战。

1）增加的杂乱性

在一个现已很杂乱的环境中引进代理、sidecar等组件会极大地增加运维的杂乱性。

2）需求的专业知识

在容器编列器(如Kubernetes)之上增加Istio之类的服务网格，一般需求运维人员成为这两种技能的专家。

3）延迟

服务网格是一种侵略的、杂乱的技能，它能向服务架构中增加明显的延迟。

4）渠道的依靠性

服务网格的侵入性迫使开发人员和运维人员习惯一个高度自治的渠道，并恪守其规则。