体系结构

体系结构

halo以“异构分布式，集群化环境“作为应用系统构建过程的假设场景，为应用系统能够在开发阶段，部署阶段，运营阶段下，适应不同参与者对具体业务功能的实现、管理和控制，做出合适的技术规划和设计。在此过程中，将能够实现上述目标的公共服务功能固化下来，形成技术构件。

为何要以“异构分布式，集群化环境“为前提来设计？

随着不同行业的业务形式和渠道的急速增长，对于以实现业务功能的系统软件需要更加精细化的管理已经在业内达成了共识。

虽然很多技术创新型公司已经在“SOA”，“microservices”，“serverless”等架构模式中找到了发展方向，不过传统企业在IT转型过程中，对于系统的“精细化管理”在系统生命周期各个阶段的解读方式上仍旧存在很多争议（运营OR研发，DevOps何去何从？这是一场混战。作者打算“独善其身”）。

因此，halo在设计初期就计划以“形而上”的方式对传统行业IT系统转型规划所面临的非技术类问题做隔离。不再强调“SOA”和“微服务”等具体典型设计模式在halo中的体现，而将设计重点回归到在行业公司的典型IT架构下，如何能够保持重要应用系统在生命周期各个阶段的健康演化上。所以，才会以“异构分布式，集群化环境“为前提来设计。

从系统静态设计角度，halo要求应用开发者采用maven来管理应用系统代码和组件包。这样能够充分利用maven的依赖管理和部署策略等特性。

从系统运营的监控管理上，halo提供和一些与业务无关的监控和管理功能（听说这玩意现在叫做Sidecar）。便于系统运营人员实现自动化的查看和监控。

工程规划

先说说开发者最关心的问题，系统工程规划问题。就像上面叙述的一样，halo为了隔离非技术问题对架构设计的干扰，很少存在must-be的设计内容。所以，对于系统工程的规划也仅是从每个maven工程的职能上做出一个推荐的划分。

如果应用系统设计或开发者对这种划分不满意，完全可以通过maven的 pom.xml重新组织自己的系统代码工程。

• 首先，建议为应用系统创建parent工程，便于在开发阶段对依赖包版本的统一管理和维护。

• 其次，建议将系统运行包划分为三个工程：web-app，service-app，batch-app。挂载到parent工程下。

• 最后，建议将业务模型对象（BO）和运行包和系统之间的调用接口契约隔离到models和service-api工程中。

再来说说halo本身的组件划分。halo采用core & support的思路来规划设计自身的包组织方式的。

• halo-core作为halo的内核，包含的多个公共技术构件能够被使用（参考组件清单）。

• core-supports作为halo-core的外围支持组件集合而独立存在。里面包含了多个可插拔的，能够更加充分发挥公共技术构件作用的插件。

  需要说明的是，core-supports的内容几乎与halo-core内公共构件的重要程度一致。只是从halo设计上，为了避免将带有副作用的功能或函数与公共构件耦合在一起，因此被拆开后形成了core-supports插件集合。

• business-supports作为halo-core的另一种类型的插件集合支持，其包含的插件与具体应用系统的业务领域结合的更紧密一些。例如某系统身份验证方式的实现，对既有服务的一些监控和AOP拦截等等。

  如上所述，business-supports更多的是以业务构件的形式为使用halo的应用系统提供公共功能的增强的。因此，在不同的应用系统实践中，business-supports包含的构件和内容也不尽相同。不过halo正在尝试提取一些带有业务特征的business-supports插件。

关于推荐的应用系统工程规划和halo的工程划分，参见下图：

设计蓝图

我们再从使用halo的应用系统规划蓝图的角度，“务虚”的“画一张“能够支持“异构分布式，集群化“应用系统的“大饼”。进一步细化对几个运行包作用的描述，以及周边中间件和资源容器的支持。

Web交互应用（web-app）

“现在最广泛的软件交互展现形式是什么？“”——WEB展现啊。“所以在web-app中，主要负责“人机交互”的实现。通过集成spring-mvc等web技术组件面向WEB客户端提供资源访问入口。

除此之外，这一层应用要在具备“横向扩展”和“纵向拆分”能力的前提下，实现会话保持和授权认证的功能（参考认证与授权）。而这些halo已经替你做到了，只需要结合应用系统的部署规划做一些配置和认证服务接入即可。

业务服务应用（service-app）

业务服务应用负责应用系统的领域模型表示和实现。一方面要对外提供业务数据的供给服务和操作服务；另一方面也要在应用内体现业务的隔离和拆分。

批作业应用（batch-app）

批作业应用上运行的任务特征应当是对时间敏感度低，数据规模大的业务处理任务。其设计重点应当是数据流规划和操作导致的数据一致性问题风险。

消息服务应用

包括消息队列应用和企业服务总线类软件产品。作为动作操作指令的传递者存在。

资源容器

一般指关系型数据库存储。不过也包含内容存储，数据集市等资源容器。

技术栈概况

halo框架的技术路线和组件选型原则是在“异构分布式，集群化环境“下，既提供业务应用构件开发阶段的全链路技术组件支持，同时也满足软件快速迭代发布。