行云部署前端架构解析-前言-京东云开发者社区

## 一个简单的自我介绍

### 项目规模
截止目前上万次代码提交，总代码行数[<sup>1</sup>](#代码统计方法) 超过21万行，其中人工维护的代码超过 13万行，近千个文件。

前端线上服务直接对接的后端服务，达十多个。

跟很多应用一样, 它有行云的入口, 也有独立的服务, 还有单独的插件接口

它是行云的子应用, 也是其它应用的主应用

### 技术栈
#####  代码本身是 monorepo 的结构，通过 nx + pnpm 进行管理

1. [nx](https://nx.dev/) 是一个优秀的项目管理工具，可以自动分析项目依赖、构建缓存(package 级别)等;
2. [pnpm](https://pnpm.io/) 相比npm, 可以更省空间、更快安装, 重要的是, 包版本管理更稳定.
		
##### 项目直接通过 webpack 进行构建，而非 vue 官方的 cli-service；
		
后者虽提供了良好的封装, 适于大多数项目, 但如果需要进行精细化构建过程管理，其学习成本与坑量也翻倍了。

##### 项目框架采用 vue2 + JModule
	
[JModule](https://jmodule.jd.com/) 可以帮助我将项目拆分为多个模块, 这对于这个大型项目的管理带来了诸多裨益, 其中细节在后续章节阐述.
    
> 似乎有很多项目因为JModule执行了两次构建，一份自己独立部署使用，一份对接行云应用，从而导致构建时间直接翻倍，这应该没有必要. 相反用好了可以通过拆分模块来加速构建，而这也是本项目的处理方案。

### monorepo 下的包构成与依赖关系
主要包含3部分: 
    
1. API SDK `@jindowin/api-jdos*`
2. 公用组件库 `@jindowin/common`
3. 业务模块 `@jindowin/jdos3*`

其依赖关系可以通过 nx 工具直观的看到:

![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-11-29-20-03KAhLFCBdS8E29f80.png)

项目分两层，底层为基础包(1和2)，上层为业务模块(3), 这其中还有些细节:

1. 单向引用: 只允许存在代码上层对下层的依赖, 反之不行.
2. 无横向引用: 每层包之间不存在代码上的横向依赖关系, 互相隔离
3. @jindowin/jdos3 这个包是主入口，通过 JModule 将其它模块进行组合

## 架构设计的来由

回忆一个项目的成长:

框架设计者准备了模板, 只需要一行 create 命令

她五脏俱全, 结构统一

项目启动很快

很顺利

不用担心端口冲突, 它能自动检测并调整

不用时刻刷新页面, 它内置了热加载

不用担心代码规范, 它提供了构建时校验

后来

我们加入了 host, 单点登录解决了

我们写好了 proxyTable, 数据就有了

到这里, 世界更加美好了

再后来

项目逐渐长大, 而最初的美好

也开始慢慢消散

直到有一天

电脑风扇发出八级大风的哀嚎

引以为傲的 proxyTable 开始频繁冲突

代码校验失效了

产品问, 这俩站点的功能要合并

开发问, 昨天还好好的, 今天就跨域了

测试问, 我要部署一套测试环境

设计问, 这个页面的标题咋比另一个页面大呢

领导问, 服务挂了怎么办

用户问, 网页真白, 不知道还要再白多久

...

我开始怀念

我开始行动

我需要沉淀

## 架构设计的细节

在不久前, 我在草图上写下了一个粗糙的结构, 原计划一篇写完

有性格测试说, 我是一个P人, 不爱做计划

后来, 计划真的破产了, 一周过去了我只写完了《前言》

没有拖延, 但真的低估了它的细节与难度

梳理了一下分支, 从TODO开始, 分别来写:

### 模块设计

模块化是一个常规的设计方案, 但在具体实现层面, 仍有一些细节可以探讨, 比如:
1. 设计时的基本原则
2. 如何界定一个模块? 
3. 预期能获得哪些收益? 
4. 模块间是否存在依赖、层级关系?
5. 模块的分类?
6. 模块间的通信方式?

详情: [行云部署前端架构解析-模块设计](http://sd.jd.com/article/26155?shareId=5298&isHideShareButton=1)

### 开发体验

如何优化构建速度?
新成员介入开发时,如何做最少的配置来启动项目?
多人协作时, 如何减少公共配置的冲突?
如何减轻电脑的负担, 让编码更加顺畅?
微前端的项目, 如何顺畅进行开发联调?

详情: [行云部署前端架构-开发体验](http://sd.jd.com/article/27858?shareId=5298&isHideShareButton=1)

### 首屏加载
`TODO`
这是一个很常见的问题, 不解释

### 权限模型
`TODO`
这可能涉及角色的系统可能都逃不过的一个坎. 主要关注路由权限、菜单权限、具体功能的权限.
我们如何管理这些权限? 
如何应对微前端模型?

### 多站点管理
`TODO`
1. 多个站点, 需要多套服务吗
2. 如何应对站点合并
3. 如何区分站点功能
4. 涉及站点时编码的基本原则
5. 多个入口还是一个入口

### 多入口
`TODO`
这也是不少团队遇到的问题, 对于多数应用一个 if 执行不同的 bootstrap 代码可能就够了.

但有时候事情偏偏就很复杂...

我需要提供一些独立的组件, 理想情况下, 一个 exports 也就可以了

但当情况不理想的时候...
你要用提供的组件及其所有依赖组件, 依赖了 router
还有它与多站点的化学反应, 事情开始更加复杂

### 应用双生
`TODO`
这是一个奇怪的概念, 我造的.

它描述了这样一个现象: 一个应用, 两种形态. 或者该叫: 多态?

一般不会出现

一般出现也是过渡态

但真正的困难, 往往都是过渡态

行云部署与持续交付, 就是行云的两个子应用, 有不同的入口进入.

问题是: 同一套代码, 如何正常工作在两种模式下? 尤其是里面的路由

### 接口异常
`TODO`
1. 从用户遇到问题, 反馈到研发看到异常, 日志已经融入了大海
2. 服务挂了, 异常提示在屏幕上争相显示, 那队伍, 比瓦罐汤的队伍还长

### 配置管理
`TODO`
我们有一个功能的配置, 它有800多行
我们有一套服务的配置, 这个简单一点, 加起来也就 300 行左右

如何开发不乱、上线不慌?

### 服务维护
`TODO`
这是一个简单的问题, 因为我不专业
我猜, 我可以在10行以内讲清楚.
但是, 现在不忙讲...

> 以上内容, 可能跟据后续写作情况增减

> 争取早日清理掉里面的 TODO 标签

[1] <span id="代码统计方法">统计范围为仓库内 jdos 项目相关的 js\ts\jsx\tsx\css\less 文件</span>