最近一直在思考一个档案系统该怎么设计。先梳理一下我们目前在实际中遇到的问题。
痛点问题
1. 用户系统割裂，在a系统的登录状态在b系统并不通用；
2. 重复开发问题，每个系统都得开发用户模块，日志模块等，在b端系统里用户权限往往是比较复杂的；
3. 系统越来越重，因为不断地迭代，不断地往里面加功能，如果某个功能不好用，客户也很难单独地对某个功能进行替换；
4. 体验不友好，因为各个系统都是独立开发的，通常没有太统一的设计。
架构设计目标
认清了痛点问题，我们希望整个架构应该是这样子的：
1. 各应用可以独立开发，又能很容易的整合在一起，也就是应用在整体系统上可插拨；
2. 基础模块统一：形成标准，避免重复开发，就是形成大中台；
3. 统一的使用体验：虽然各应用是各自开发，但是整合在一起的时候，应该有统一的体验；
4. 用户可以在各个应用间自由切换，而不会有登录认证问题；
基于这些思考，就有了设计中的这个架构。
基于大中台的可插拨轻应用架构设计
整体界面设计
整体框架大致如下：
1. 顶部左边是系统logo，点击可以回到首页，logo图像地址和首页地址，都是配置的；
2. 顶部中间是应用导航，可以在合个应用间进行切换，这也是通过接口配置的；
3. 右侧是登录用户头像，在这里可以退出登录等；
4. 主体的左侧是应用内的导航，每个应用可以有自己的导航体系，该导航可以收起来；
5. 主体的上方有统一的面包屑导航，显示用户当前在哪里。
这个界面框架，实现方式主要有两种：
一种是使用iframe，把应用菜单和主体部分装到一个iframe里面；
另一种实现是各个应用都实现一个一样的头部，当然这些logo和应用菜单项都是通过接口获取的。
iframe是一种比较古老的实现技术了，但是这个技术本身有很多问题，可以网上搜索，并不建议使用，所以我们还是选择第二种实现方式，在前端做成一个通用的header模块，其实还是可以接受的。
整体架构
整体架构分三层：
1. 应用层：各种业务应用，应用要做轻，一个应用把一件事做好，只需要使用业务逻辑，应该避免把很多东西堆在一个大应用里；
2. 中台层：中台要做大，通用的功能应该放到中台进行实现，这样应用层才能做轻，如用户功能，日志功能，配置功能等；
3. 基础层：底层的各类任务，基于开源的各类工具或者我们自建的工具等，这些要稳定，要保持统一，避免各自为政。
需要注意衡量的是，各个层之间的界限并不是泾渭分明的，有些应用也可能被其他应用所调用，是否就需要都实现到中台上呢，就就不一定了。
基础层和中台层也是一样，需要实际问题实际分析，所谓架构设计就是根据实际情况不断进行权衡妥协的过程。
可插拔实现
对于一个应用来说，主要分成三个阶段：
1. 开发阶段：独立把应用开发好，如果需要使用中台功能或者其他应用功能，可以进行调用，使用上可以说是无缝的；
2. 上线阶段：开发好之后，就可以上线到某个服务器上（如果上线多个服务器，则可以使用nginx进行分发）；
3. 接入阶段：接入非常简单，只需要在中台的应用配置中心配置应用菜单项即可，如果需要还可以为该应用配置更多的变量。
接入之后，正常来说就可以正常访问了。
架构关键词
总结一下这个架构的特点：
1. 大中台
2. 轻应用
3. 可插拔
20220828
