有赞技术架构分析

我喜欢去分析一个公司的技术架构，这让人感觉很有趣，有赞是一家很有技术氛围的公司，今天就来一探究竟。

华星时代广场（扎根电商福地文三西路，风水真好！）

前端：

react

服务端渲染层

node

服务端业务层

java
dubbo 分布式服务框架

服务端基础层

java

创业初期，php时代，那时候有赞还是个小孩子，一切为了业务

随着公司业务的发展，网站应用的规模不断扩大，垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键，所以在这个时候，分布式服务架构就势在必行了。

业务稳定期，node+java时代
所以等到了一定时候，开始做服务化拆分，那么首先考虑的就是底层技术的选择，我们从下面几点考虑：
第一个是这门技术的生态是否足够完善，也就是相关的开源软件、工具是否成熟；
第二个是否能够快速招到你需要的人才。
对于 Node 层，我们的定位是一层很薄的中间层，Node 这一层不会过多地处理业务逻辑，业务逻辑全部都交给 Java 来处理，它只负责下面三件事情：
模板渲染：模板渲染说的就是 HTML 模板的渲染；
业务编排：对于一个稍微复杂一点的页面，通常需要聚合多个接口返回的数据才能显示完整的页面，所以在这种情况下，Node 就需要聚合多个接口的返回结果，然后将合并后的数据返回给前端。
接口转发：Java 的服务是不会直接暴露到公网提供给前端使用的，所以在这种情况下，Node 需要承担接口转发的角色。

Node 如何调用 Java 接口？

那么服务化拆分之后，首先要解决的一个问题是：Node 如何调用 Java 提供的接口。首先，我们想到的就是 HTTP 的方式，这里说明一下，我们公司采用的分布式服务化框架是阿里开源的 Dubbo 框架，而 Dubbo 框架本身是支持通过添加注解的方式生成 Restful API 的，所以在初期，我们就是采用这个现成的方案。

而随着应用数目的增加，这种方式的弊端也逐渐显现出来，主要有下面几点：

如果某个接口需要暴露给 Node 使用，就需要手动再去添加额外的注解。
每增加一个应用，运维都需要针对每个应用配置域名，不同的环境又需要配置不同的域名，所以随着应用数的增加，应用域名的管理越来越难维护。
相应的，node 也需要维护一份很长的域名配置文件。
由于 Java 是直接提供 HTTP 接口，所以性能上相对 RPC 的方式会低一点。
所以，我们就调研了下，看其他公司在使用 Dubbo 框架时，Node 是如何调用 Java 的？如下图所示：

资料来源：
https://www.cnkirito.moe/dubbojs-in-qianmi/
https://tech.youzan.com/youzan-node/