关于门户的架构思考

我负责 UED 门户项目整体的架构设计及服务端研发工作，
在确定项目需求后，我使用「分层架构」设计了项目整体的架构实现方式，设计系统自上而下分为应用层、业务层、服务层、数据层；
在面临多种的认证方式时，选用「适配器模式」解决认证方式差异的问题；
在解决 UED 门户需要获取应用操作记录的问题上，使用「观察者模式」，将通过向应用获取转变为应用上送以优化操作记录获取的方式，解耦功能；
并且从部署视角的角色选型「虚拟化技术」以保证部署的效率和稳定；

题外话

项目第一阶段已告一段，UED 门户项目，是我写 Node.js 开始第一次正式的、完整的参与到研发过程中的项目。

从技术选型、架构设计逐一入手，是一次较为全面完整的项目体验。

后续其他部门需要门户网站时，此项目即替换 Web 界面即可交付其他部门，已实现大体复用。

背景

UED 部门需要建立自己的门户网站，网站需要将现有的 UED 模块服务（原型设计稿、前端组件、设计资源、文档等）集成为一体，以提供一个统一设计资源规范、资源共建、学习成长为一体的门户网站。

项目要求

用户的认证方式需要支持公司认证和独立认证，并且认证的用户角色分为用户和应用即「服务模块」
门户需要收集接入应用中指定的操作记录或其他消息信息
门户计划在多套环境下进行独立部署

架构设计

架构设计采用「分层架构」，将门户分别为应用层、业务层、服务层、数据层。

应用层包含 UED 门户自身对用户的 Web 界面以及需要集成进来的应用如：原型设计平台、组件平台、资源平台和文档平台等
业务层包含 UED 门户提供的业务模块，包含：服务模块管理模块、用户角色权限管理模块、意见反馈模块和文章模块
服务层包含认证服务、日志服务、订阅服务和资源服务
数据层包含 PostgreSQL 、 Redis 、 MinIO

认证服务设计

认证方式在设计之初存在两种，分别是接入公司的认证中心和实现自己独立的认证中心。可以见得，认证方式是在项目部署时就决定的内容，并且只存在认证服务内部的实现逻辑差异，所以需要保证认证服务对外一致即可。

所以在设计时，选择以自己独立的认证中心为接口标准进行设计，设计认证标准抽象，让两种方式可以按照抽象进行实现。

设计模式上，这里选择适配器（Adapter）设计模式，此模式的优点是：

单一职责原则你可以将接口或数据转换代码从程序主要业务逻辑中分离。

以保证每一种接入的认证方式都和程序主要业务逻辑无关，保证认证服务对外提供的接口和行为一致。

开闭原则。只要客户端代码通过客户端接口与适配器进行交互，你就能在不修改现有客户端代码的情况下在程序中添加新类型的适配器。

新增认证方式或则切换认证方式，都无需修改其他服务。

缺点是：

代码整体复杂度增加，因为你需要新增一系列接口和类。有时直接更改服务类使其与其他代码兼容会更简单。

所以在认证模式开发的阶段，使用适配器设计模式会使得代码较无设计模式的情况下，更为复杂一些。但是在程序运行阶段对认证方式切换则无需更新程序即可完成，同时新增认证方式也不会修改到程序的其他业务逻辑。

从程序质量属性的角度，保证了程序的可修改性。

订阅服务设计

如果按照传统的方式去一一对接各个应用中的操作记录或者消息信息，会使得 UED 门户的程序代码与接入的应用功能强耦合，为了解决这个问题。

UED 门户提供订阅服务，采用观察者模式（Observer）来对接实现各个应用中的操作记录或者消息信息记录。

通过向应用获取转变为应用上送以优化操作记录获取的方式，约定 UED 门户所需的消息主题，各个应用将需要上送的消息按照对应的主题上送至 UED 门户，由 UED 门户向用户进行展示。

观察者模式的优点是：

开闭原则。你无需修改发布者代码就能引入新的订阅者类

即如果有新应用接入 UED 门户，保持同主题的推送消息，门户在无需进行修改的情况下，用户即可以获得新应用的消息内容。

缺点是：

订阅者的通知顺序是随机的

目前从需求来看，通知的顺序并没有很重要，但如果要实现顺序可以在通知内容中添加时间戳，以应用上送的时间戳为基准，以此来解决消息顺序的问题。

部署视角

从部署视角来看，项目需要在多套环境下进行部署，为了避免环境不一致引起的额外部署工作，所以选用虚拟化技术来完成项目部署。

目前公司存在办公网和内网环境，两套环境分别需要部署正式和测试环境，在技术选型上，我对 Docker 和 Kubernetes 进行了对比。

Docker 和 Kubernetes 都是虚拟化容器技术，以解决在任何计算机上部署你的项目，但是相比较而言。

Docker 属于容器运行时技术，更适合单机运行或对资源要求较小的应用，而 Kubernetes 则属于一种容器编排工具，更适合集群运行或更大规模的应用。

所以从部署视角来看，项目目前使用的用户对内，并且大部分都是研发侧的同学，同时在使用性能上并没有较高的并发需求，即最终选用 Docker 来完成部署工作更合适不过。