简单应用框架 VSEF 的架构

本文介绍了一些简洁架构VSEF的一些框架结构理解，并且抛出了一些演化的主题，这些主题的不同思考会让系统发展成不同的风格，实际也是应用定位的必然结果。

总体

VSEF 架构理念  =   基本结构  + 演化

1. 基本结构 = 入口 + 内核 + 依赖
   内核 = 简单逻辑 + 复杂流程
   简单逻辑 = 业务脚本 + 能力执行
   复杂流程 = 流程编排 + 节点衔接 + 能力（任务）执行
2. 演化 =  主题讨论 + 组件选取（市场组件优先）
   

VSEF 总体结构

核心架构

架构 = 组成要素 + 关系 + 设计/演化原则

▐  入口

VSEF 观点：入口要清晰明确

就像 “要理清乱了的线团，就要找到线头一样”，将入口放在一个完整的目录，或者模块中的好处是：可以快速地功能总览，了解“提供哪些服务”、“接收那些消息”、“实现哪些任务”。

这里的目录类型有：

1. 服务 service : 对外提供的 rpc 服务， 如HSF。这个一般会搭配一个服务 client 可调用者使用。

2. 消息 message：可以再区分 metaq 和 notify 目录。
   

3. 调度 scheduler：一些调度任务。
   

业务入口

▐  内核

业务逻辑进入之后，常见的结构是 Service + Component + Mapper。但随着操作链路的增多，会逐渐交织耦合，变得复杂。所以，需要一些设计，包括：纵向的分层、横向的目录划分、并定义复用的区域，缓解代码安放问题造成的复杂度。

VSEF 观点：内核 = 简单逻辑 + 复杂流程

内核结构

复杂流程，主要是写入服务，或者是带页面表达的详情服务，采用流程分类框架（Process Classification Framework，PCF）。进入到应用的时候，主要分为3层：

1. 流程 l3.process：进行业务活动编排，理解整个请求要完成什么事情。
2. 活动 l4.activity：提供每个执行步骤的能力，代表了事情的关键节点。
3. 能力（任务） l5.ability：节点执行时要做的一些具体任务，期望包装为能力，具备一定的复用性。

流程分类框架 PCF 层次

简单流程，主要是只读服务，如查询数据等，可以直接进入服务脚本 service。简单服务直接使用 l5能力（任务）。当逻辑逐渐复杂的时候，可以重构为复杂流程。



VSEF 观点：完成任务需要使用的资源都是依赖，依赖皆服务。服务都通过 l5能力 进行使用。

l5 能力在进行具体操作的时候，需要从数据、扩展、外调、中间件等渠道获取需要加工的数据，形成自己的理解。这个过程中，依赖的东西被称为“依赖”，通过“服务”的方式进行集成。

▐  依赖

可以放进依赖的类型：

1. 存储实现 repository : 数据库的读写操作。

2. 中间件使用 middleware：包括缓存（tair）、发送消息（metaq、notify）、配置（diamond、switch）等。

3. 网关实现 gateway：外部系统的调用，比如订单服务、退款服务等。
   

4. 扩展实现 extension：业务差异性设计的扩展能力，需要业务提供扩展插件，或者平台代写。
   

依赖内容

VSEF 观点：基础设施是否易变，可自行判断，稳定时可以直接依赖。

这里值得讨论的是：如果基于六边形架构，这些基础设施被视为具体实现，应该通过抽象接口，依赖倒置的策略，实现解耦。但是实际在大家的系统中，可以判断其易变性，如果长期保持稳定的话，可以减少依赖抽象这一层，直接依赖基础设施，减少抽象成本，在思考层面做到 less is more。

主题演化

VSEF 的目录只是一个初始化、相对简单的系统结构。如果随着业务的发展，各个组成部分会逐渐臃肿，系统风格可能也会变化。所以需要引入一些主题的讨论，结合业务情况进行一些设计，并选取相关组件，进行集成，形成有具体组织特征的、新特性的应用结构。

VSEF 观点：演化后的系统结构，结合了功能特性，才是各个组织的合适的系统结构。

这样的系统结构可能会彼此差异很大，会成为不同的类型，就像七个葫芦娃一样，核心本领各不一样：

1. 注重平台服务的：关注平台逻辑和扩展机制。

2. 注重组件表达的：与用户有交互，需要关注组件化协议。

3. 注重领域协作的：需要关注协调者的模型和设计、应用内的领域划分逻辑。

4. 注重数据服务的：关注数据能力性能、功能范围、数据模型映射。

VSEF 主题

下面，会基于VSEF的主题，简单谈一下思考，有了这一部分，才会知道如何去选择组件，而不是“被组件的厚重所绑架”，避免为了用而用，实际并不合适。

▐  组件协议

如果系统是平台型的，并且带界面表达，那么需要解决的就是各个端、各个页面、各个业务不一样的扩展能力。在内部模型和视图模型之间增加一层ViewModel, 然后基于这个进行各种转换，是不错的思路，比较典型的组件有：奥创、Astore等。

Model-View-ViewModel（MVVM） 模式

这里细化开来，关于 ViewModel 能够有多定制，有2个不同的走向：

1. 转换主要在组件框架中：在核心逻辑之外，进行各种框架植入，如奥创、Astore, 在数据出口侧进行转换，转换的手段一般是基于规则表达式，利用相关反射能力进行数据组装。

2. 转换主要在业务扩展中：不想在组件框架中承载过多代码，想和业务普通扩展逻辑走的近一些，在系统执行过程中的扩展逻辑中，植入视图的扩展，可以较好匹配前台组件。
   

奥创&DinamicX 方案运行原理

▐  活动编排

流程编排是对一个业务操作执行过程进行进一步的划分，常见的编排组件有：Tbbpm、SmartEngine 等。但在实际开发过程中，常常会有这样的疑惑：为什么是这几个节点？为什么是这样的顺序？

• 为什么是这些节点？

这和我们看到一段非常长的代码，把它切分成几个方法是类似的。关键是切分的依据是什么？常用的一些划分点有：

1. 是不是调用了一个服务？那么准备服务参数，调用，返回结果判断可以包装为一个节点。
2. 是不是都在操作一个对象？那么这些操作可以归类为：初始化，修改，转换等内聚的方法。
3. 是不是一些通用的处理？比如安全校验、日志监控、数据统计等。
4. 是不是存在业务扩展性？可以单独独立出来，作为抽象方法，或者使用组合，提供相关接口定义。

切分的背后是理解

• 为什么是这样的顺序

基于这些切分原则，可以对一个执行过程的核心要点进行切分，切分完后排序的依据是什么？为什么一定要是这样的顺序？这个问题本质是需要了解各个部分的依赖关系，这些依赖关系可能是：

1. 上下文数据依赖
2. 本身地位：需要对最终结果进行收口，需要最后执行。
3. 系统框架要求必须进行初始化先执行
4. 其它等等

那么我们可以去梳理这些依赖关系，形成一个有向无环图，最后变成寻找了拓扑排序这样的问题：

1. 每个顶点出现且只出现一次

2. 上一篇： 腾讯游戏内部正在使用该产品进行运维。

   下一篇： 架构就是未来：为可扩展组织配备人员（S2）