基础知识

UML 关系

用例之间的关系：包扩泛：包含（必须使用）、扩展（可能使用）、泛华（父子/特例）
类之间的关系：关实泛依（关十反一） ： 依赖、泛华、关联、实现

SOA定义：

SOA是一个组件模型，它将应用程序拆分为不同的功能单元（称为服务）
通过这些服务之间定义良好的接口和契约联系起来。
接口采用中立方式定义，独立于实现服务的硬件平台、操作系统和编程语言。
使服务可以一种统一和通用方式进行交互。

SOA与微服务的区别

a、微服务相比于SOA更加精细，微服务更多的以独立的进程的方式存在，互相之间并无影响；
b、微服务提供的接口方式更加通用化，例如HTTP RESTful方式，各种终端都可以调用，无关语言、平台限制；
c、微服务更倾向于分布式去中心化的部署方式，在互联网业务场景下更适合；

ESB的作用和特点：

1、总线作用：ESB在面向服务架构中起到总线作用，将各种服务进行连接和整合；
2、元数据和注册作用：描述服务的元数据和服务注册管理；
3、数据传递和转换作用：在服务请求者和提供者之间传递数据，以及对这些数据进行转换的能力，并支持由实践中总结出来的一些模式，如同步模式、异步模式等；
4、服务发现、路由作用：发现、路由、匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求者和服务提供者。高级一些能力，包括对安全的支持、服务质量保证、可管理性和负载平衡等。

状态图和活动图区别：

1、状态图主要用于描述一个对象在其生存期间的动态行为，表现一个对象所经历的状态序列，引起状态转移的事件（event），以及因状态转移而伴随的动作（action）。
2、活动图可以用于描述系统的工作流程和并发行为。活动图其实可看作状态图的特殊形式，活动图中一个活动结束后将立即进入下一个活动（在状态图中状态的转移可能需要事件的触发）。
3、两者最大的区别是：状态图侧重于描述行为的结果，而活动图侧重描述行为的动作。其次活动图可描述并发行为，而状态图不能。

数据流图 与 系统流程图的区别：

a. 并行：数据流图中的处理过程可并行，系统流程图在某个时间点只能处于一个处理过程
b. 计时标准：数据流图展现全局的处理过程，过程之间遵循不同的计时标准，系统流程图中处理过程遵循致的计时标准。
c. 数据流：数据流图展现系统的数据流;系统流程图展现系统的控制流。

活动图与系统流程图的区别：

a. 活动图描述的是对象活动的顺序关系所遵循的规则，它着重表现系统的行为，而非处理过程，而流程图着重描述处理过程。
b. 活动图则可以支持并发进程，流程图一般都限于顺序进程
c. 活动图是面向对象的，而流程图是面向过程的。

面向对象与基于规则的风格的对比

a. 灵活性
面向对象：将用户规则、折扣规则封装为对象，在系统启动时加载
基于规则：在系统启动时加载，并支持运行中动态更新，灵活性更好
b. 可扩展
面向对象：规则修改时，需要通过修改程序、添加类的方式 ，通过系统重启、动态反射或动态加载，扩展性差
基于规则：规则增加时，只需要定义新的规则，解释规则即可进行扩展
c.性能
面向对象：规则以硬编码方式书写，编译后运行，性能好
基于规则：需要对规则进行实时解释，性能较差

仓库风格与 管道过滤器风格区别

a. 数据处理方便：
管道：数据驱动机制，处理流程事先确定，交互性差
仓库：数据统一保存在中央数据仓库，数据处理流程相对独立，支持交互式处理
b. 可扩展性
管道：管道-过滤器风格容易添加新的过滤器，可扩展性好。
仓库：数据与处理解耦合，可动态添加和删除处理组件
c. 处理性能
管道：优势: 支持过滤器并发调用，性能提高；劣势:需要数据格式转换，性能降低；
仓库：优势: 仓库风格容错性和健壮性好；劣势:仓库风格不支持并行，效率低。

采用标准数据访问机制的好处：

a. 标准的数据访问机制提供了不同标准间的数据访问机制，它屏蔽了不同通信协议之间的差异，为上层应用程序提供统一的访问接口，可以容易地实现应用程序对不同总线协议设备的互操作，使得开发人员从低层的开发中脱离出来。
b. 它独立于平台，确保来自多个厂商的设备之间的信息无缝传输，具有语言无关性代码重用性、易于集成性等优点。当硬件升级或修改时只需改动硬件接口部分即可，不会影响上层应用程序。例如，工业自动化领域常用 OPC。

数据流图和数据字典在需求和设计阶段的作用

在需求分析阶段：数据流图过数据的输入、流向、处理过程、输出，可以清晰地反映出系线是完成的逻辑功能，从而可尽早发现是否有需要输入或输出的信息被遗漏，以及系统各部分的逻辑是否存在错误；数据字典是描述数据的信息集合，通过数据字典可使参与人员对模型中的元素有共同的理解。
在设计阶段，根据数据流图，通过变换分析和事务分析的方法，可设计出系统的模块结构(系统结构图)；根据数据字典中的数据存储描述可建立数据库存储设让

设计模式分为三类：创建型、结构型、行为型

a. 创建型，关注的是对象的创建，创建型模式将创建对象的过程进行了封装，作为客户程序仅仅需要去使用对象，而不再关心创建对象过程中的逻辑
b. 结构型，主要用于处理类或对象的组合，对类如何设计以形成更大的结构提供指南。
c. 行为型，行为型模式重点关注类或对象之间的相互作用，通过行为型模式，可以更加清晰地划分类与对象的职责，并研究系统在运行时实例对象之间的交互。

软件架构风格定义：软件架构风格是指描述特定软件系统组织方式的惯用模式。组织方式描述了系统的组成构件和这些构件的组织方式，惯用模式则反映众多系统共有的结构和语义。

架构建模的4+1视图

4+1视图模型从5个视角来描述软件架构，分别为：逻辑视图、物理视图、进程视图、开发视图和场景视图。逻辑视图主要描述系统的功能需求，将系统分解为一系列的功能抽象，可用对象模型来代表，用类图来描述；开发视图主要侧重于软件模块的组织和管理，考虑软件内部的需求；进程视图侧重于系统的运行特性，主要关注非功能需求，强调并发性、分布性、系统集成性和容错能力，以及逻辑视图中的功能抽象如何适应进程结构，定义了具体线程执行的操作；物理视图主要考虑软件向硬件的映射，解决系统的拓扑结构、安装和通信问题。场景视图可看做重要系统活动的抽象，使其他4个视图有机联系。
4+1 视图的基本思想是关注点分离原则，通过一个统一的场景，把四个视图有机的联系起来，帮助软件设计者架构构件和他们之间的关系。

基于架构的软件设计方法（ABSD）包括六个阶段：架构需求、架构设计、架构文档化、架构复审、架构实现和架构演化。

架构需求阶段，明确用户对系统在功能、行为、性能、设计约束等方面的期望，包括需求获取、标识构件和需求评审；
架构设计阶段，根据需求生成并调整架构决策，包括提出架构模型、映射构件、分析构件相互作用、产生架构和设计评审；设计评审之后可能还会重新对构件映射做出调整，所以其中的活动也存在重复多次的情形；
架构文档化阶段，对架构设计阶段的成果进行分析和整理后形成文档，产生架构规格说明书和质量设计说明书；
架构复审阶段，评价架构能否满足需求与实现质量属性、层次构件划分是否合理，标识潜在的风险，及早发现设计中的缺陷错误；
架构实现阶段，对架构进行实现，包括架构分析与设计、构件实现、组装和系统测试；
架构演化阶段，主要解决开发中用户需求变更问题，包括架构演化计划、构件变动、更新构件相互作用、构件组装测试与技术评审。

基于架构的软件设计方法ABSD，是架构驱动的，强调由商业，质量和功能需求的组合驱动软件架构设计。强调用视角与视图描述软件架构，用用例与质量场景描述需求。

架构评估的质量属性

架构评估是软件开发过程中的非常重要的一个环节，在软件架构评估中我们通常关注的质量属性包括性能、可用性、安全性、可修改性等。性能是指系统的响应能力，即要多长时间才能对某个事件做出响应或者在某段时间内系统所能处理的事件的个数；可用性是指系统正常运行的时间比例，经常用两次故障之间的时间长度或出现故障时系统能够恢复正常的速度来表示；安全性是指系统能够向合法用户提供服务的同时可以阻止非授权用户访问的企图或拒绝服务的能力；可修改性是指系统能够快速地以较高的性能价格比对系统进行变更的能力，通常以某些具体的变更为基准，通过评估这些变更的代价衡量可修改性。

敏感点、权衡点、风险点的定义

敏感点，是一个或多个构件 (和/或构件之间的关系) 的特性。
权衡点，是影响多个质量属性的特性，是多个质量属性的敏感点。
风险点，是指架构设计中潜在的、存在问题的架构决策所带来的隐患。

大型网站架构演化实例

第一阶段：单体架构
第二阶段：垂直架构（应用、数据分离）
第三阶段：缓存改善网站性能
第四阶段：使用服务集群改善网站并发处理能力
第五阶段：数据库读写分离
第六阶段：使用反向代理和CDN加速网站响应
第七阶段：使用分布式文件系统和分布式数据库系统
第八阶段：使用NoSQL和搜索引擎
第九阶段：业务拆分
第十阶段：分布式服务

数据流图设计时应考虑的三个原则：

(1) 复杂性最小化原则。DFD分层结构就是把信息划分为小的且相对独立的一大批子集例子，这样就可以单独考查每一个DFD。如果要了解某个过程更加详细的信息，可以跳转到该过程的下一层；如果要知道一个DFD如何与其他DFD相关联，可以跳转到上一层的DFD进行考査。
(2) 接口最小化原则。接口最小化是复杂性最小化的一种具体规则，在设计模型时，应使得模型中各个元素之间的接口数或连接数最小化。
(3) 数据流一致性原则。一个过程和它的过程分解在数据流内容中是否有差别？是否存在有数据流出但没有相应的数据流入的加工？是否存在有数据流入但没有相应的数据流出的加工?

数据设计过程

数据库概念结构设计，包括：
a. 抽象数据
b. 设计局部ER模型
c. 合并局部模型，消除冲突
d. 重构优化，消除冗余

数据库逻辑结构设计，包括：
a. 转化为数据模型
b. 关系范式化
c. 模式优化
d. 设计用户子模式

反规范化设计中，解决数据不一致性问题的三种常见方法：批处理维护、应用逻辑、触发器。

（1）批处理维护：指对复制列或派生列的修改积累一定的时间后，运行一批处理作业或存储过程对复制或派生列进行修改，这只能在对实时性要求不高的情况下使用。
（2）应用逻辑：要求必须在同一事务中对所有设计的表进行增、删、改操作。用应用逻辑来实现数据的完整性风险较大，因为同一逻辑必须在所有的应用中使用和维护，容易遗漏，特别是在需求变化时，不易于维护。
（3）触发器：对数据的任何修改立即触发对复制列或派生列的相应修改。触发器是实时的，而且相应的处理逻辑只在同一地方出现，易于维护。一般来说，是解决这类问题比较好的办法。

11、五大软件架构风格
在做软件架构设计的时候，为了提高系统的复用性和提升开发效率，我们通常会采用一些架构风格。我们经常采用的架构风格主要有：数据流风格、调用返回风格、独立构件风格、虚拟机风格、仓库风格。数据流风格将前一步处理的结果作为后一步的输入内容，主要包含批处理序列与管道-过滤器两种风格，批处理序列强调的是大量整体的数据一起处理，而管道过滤器强调的是流式数据的处理；调用返回风格主要包含主程序/子程序、面向对象风格、层次结构三种风格，主程序/子程序是面向过程的调用，面向对象风格主要是对象方法的调用，层次结构则是层与层的方法调用；独立构件风格强调的是构件之间不直接交互从而降低系统的耦合性，主要包含进程通信与事件驱动两种风格；虚拟机风格的特点是可以灵活的自定义场景，主要包含解释器风格与规则系统，而规则系统其实是在解释器的基础之上增加了经验规则；仓库风格强调的是以数据为中心，主要包含数据库系统、黑板系统、超文本系统三种风格。

12、云原生架构原则
1、服务化原则
服务化设计原则是指通过服务化架构拆分不同生命周期的业务单元，实现业务单元的独立迭代，从而加快整体的迭代速度，保证迭代的稳定性

2、弹性原则
弹性原则是指系统部署规模可以随着业务量变化自动调整大小，而无须根据事先的容量规划准备固定的硬件和软件资源

3、可观测原则
可观测性更强调主动性，在云计算这样的分布式系统中，主动通过日志、链路跟踪和度量等手段，让一次App点击所产生的多次服务调用耗时、返回值和参数都清晰可见，。运维、开发和业务人员通过这样的观测能力可以实时掌握软件的运行情况，并获得前所未有的关联分析能力，以便不断优化业务的健康度和用户体验

指标（Metric）、链路跟踪（Tracing）和日志（Logging）这三类数据是构建一个完整的可观测性系统的“三大支柱”。而系统的可观测性就是需要完整地采集、分析和展示这三类数据

4、韧性原则
韧性是指当软件所依赖的软硬件组件出现异常时，软件所表现出来的抵御能力
韧性原则的实践与常见架构主要包括服务异步化能力、重试/限流/降级/熔断/反压、主从模式、集群模式、跨区域（Region）容灾、异地多活容灾等

5、过程自动化原则
通过大量自动化交付工具在CI/CD（持续集成/持续交付）流水线中的实践，企业可以标准化企业内部的软件交付过程，也可以在标准化的基础上实现自动化，即通过配置数据自描述和面向终态的交付过程，实现整个软件交付和运维的自动化
6、零信任原则
基于边界模型的传统安全架构设计，是在可信和不可信的资源之间架设一道墙
零信任模型假设防火墙边界已经被攻破，且每个请求都来自于不可信网络，因此每个请求都需要经过验证，简单说就是：永不信任，永远验证。在零信任模型下，每个请求都要经过强认证，并基于安全策略得到验证授权

7、架构持续演进原则
技术与业务的发展速度都非常快，在工程实践中很少有从一开始就能够被明确定义并适用于整个软件生命周期的架构模式，而是需要在一定范围内不断重构，以适应变化的技术和业务需求
云原生架构本身也应该且必须具备持续演进的能力，而不是一个封闭式的、被设计后一成不变的架构。
因此在设计时除了要考虑增量迭代、合理化目标选取等因素之外，更应该重点考虑如何保证架构演进与业务发展之间的平衡

论文

论文1：论基于架构的评估方法

本文以该平台为例，主要论述了ATAM架构评估方法在该平台的具体应用，
首先，通过该平台的业务人员和领域专家，收集需求与场景；
其次，结合收集的需求及场景，通过评估小组会议，描述架构视图与场景实现；
最后，通过评估小组会议确定系统的质量属性，对属性模型进行构造分析，并对其中的一些权衡点做折中

架构评估是软件开发过程中的非常重要的一个环节，在软件架构评估中我们通常关注的质量属性，包括性能、可用性、安全性、可修改性等。
性能，是指系统的响应能力，即要多长时间才能对某个事件做出响应或者在某段时间内系统所能处理的事件的个数；
可用性，是指系统正常运行的时间比例，经常用两次故障之间的时间长度或出现故障时系统能够恢复正常的速度来表示；
安全性，是指系统能够向合法用户提供服务的同时可以阻止非授权用户访问的企图或拒绝服务的能力；
可修改性，是指系统能够快速地以较高的性能价格比对系统进行变更的能力，通常以某些具体的变更为基准，通过评估这些变更的代价衡量可修改性。

第一阶段，场景和需求收集。
针对功能场景与需求的收集，描述收集方式，如调查问卷，访谈，联合需求分析会议，现场观摩等
针对质量属性的场景与需求收集，描述几个性能、安全、可用性等质量属性

第二阶段，架构视图与场景实现。
组成了架构评估小组
首先，对ATAM的评估方法介绍
其次，架构师，对我们的架构视图做了详细的描述，如某个服务实现什么功能，某个技术解决了性能、可用性。

第三阶段，属性模型的构造分析与折中。
我们对单一的质量场景做了分析，具体说说各个质量属性：
冲突场景的分析，如权限控制对安全和性能的影响
输出了质量属性效用树，并对质量场景做了优先级排序，

论文2：论软件系统架构风格

本文将以该平台为例，论述架构风格在项目中的具体应用。
首先，通过采用面向对象的架构风格，抽象出了很多的对象和行为如营销人员、合同、到访单、首访证据、人证的核验、合同的创建与撤销等；
其次，采用了事件驱动，保证了二次到访提醒能及时通知到相关营销人员；
最后，采用了解释器风格，让系统通过舞弊决策结果、不同类型、不同级别的外部渠道，计算佣金。

在做软件架构设计的时候，为了提高系统的复用性和提升开发效率，我们通常会采用一些架构风格。我们经常采用的架构风格主要有：数据流风格、调用返回风格、独立构件风格、虚拟机风格、仓库风格。
数据流风格，将前一步处理的结果作为后一步的输入内容，主要包含批处理序列与管道-过滤器两种风格，批处理序列强调的是大量整体的数据一起处理，而管道过滤器强调的是流式数据的处理；
调用返回风格，主要包含主程序/子程序、面向对象风格、层次结构三种风格，主程序/子程序是面向过程的调用，面向对象风格主要是对象方法的调用，层次结构则是层与层的方法调用；
独立构件风格，强调的是构件之间不直接交互从而降低系统的耦合性，主要包含进程通信与事件驱动两种风格；
虚拟机风格，特点是可以灵活的自定义场景，主要包含解释器风格与规则系统，而规则系统其实是在解释器的基础之上增加了经验规则；
仓库风格，强调的是以数据为中心，主要包含数据库系统、黑板系统、超文本系统三种风格。

论文3：论基于架构的软件开发方法（ABSD）及其应用

本文将以该系统为例，论述基于架构的软件开发方法在项目中的应用。
首先，在架构需求阶段，通过用户访谈、问卷调查、现场观摩、构造原型的方式全面获取了需求；
其次，在架构复审阶段，采用基于场景的评估方法保障了项目的质量；
最后，在架构演化阶段，灵活运用jira来管理与控制需求的变动

论点

在做系统架构设计时，我们经常会使用基于架构的软件设计方法（ABSD）。ABSD是架构驱动的，强调由商业，质量和功能需求的组合驱动软件架构设计。强调用视角与视图描述软件架构，用用例与质量场景描述需求。
基于架构的软件设计方法（ABSD）包括架构需求、架构设计、架构文档化、架构复审、架构实现和架构演化六个阶段。

• 架构需求阶段 明确用户对系统在功能、行为、性能、设计约束等方面的期望，包括需求获取、标识构件和需求评审；
• 架构设计阶段 根据需求生成并调整架构决策，包括提出架构模型、映射构件、分析构件相互作用、产生架构和设计评审；设计评审之后可能还会重新对构件映射做出调整，所以其中的活动也存在重复多次的情形；
• 架构文档化阶段 对架构设计阶段的成果进行分析和整理后形成文档，产生架构规格说明书和质量设计说明书；
• 架构复审阶段 评价架构能否满足需求与实现质量属性、层次构件划分是否合理，标识潜在的风险，及早发现设计中的缺陷错误；
• 架构实现阶段 对架构进行实现，包括架构分析与设计、构件实现、组装和系统测试；
• 架构演化阶段 主要解决开发中用户需求变更问题，包括架构演化计划、构件变动、更新构件相互作用、构件组装测试与技术评审。

结合实际

架构需求阶段，前期、中期、后期，如何获取需求，结合原型方法，让用户也参与其中，为以后项目通过验收提供了有力支持。
架构复审阶段，采用基于场景的评估方法保障了项目的质量。场景和需求收集、架构视图与场景实现、属性模型的构造分析与折中。最终输出了质量效用树，也分析出了其中的风险点、敏感点、权衡点等。
架构演化阶段，需求的变动可能影响的多个构建，要做好记录跟踪，否则需求变得不可控制。我们使用JIRA平台，维护项目的需求池。每2周进行一次迭代，每个迭代就是一个架构演化计划，

论文4：论负载均衡技术在web系统中的应用

负载均衡（Load Balance），它在网络现有结构之上可以提供一种廉价、有效、透明的方法来扩展网络设备和服务器的带宽，并可以在一定程度上增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性等。用官网的话说，它充当着网络流中“交通指挥官”的角色，“站在”服务器前处理所有服务器端和客户端之间的请求，从而最大程度地提高响应速率和容量利用率，同时确保任何服务器都没有超负荷工作。如果单个服务器出现故障，负载均衡的方法会将流量重定向到其余的集群服务器，以保证服务的稳定性。当新的服务器添加到服务器组后，也可通过负载均衡的方法使其开始自动处理客户端发来的请求

1、轮询法会将收到的请求循环分配到服务器集群中的每台机器，即有效服务器上。如果使用这种方式，所有的标记进入分发的服务器应该有相近的资源容量以及负载形同的应用程序。如果所有的服务器有相同或者相近的性能那么选择这种方式会使服务器负载相对均衡。基于这个前提，轮循调度是一个简单而有效的分配请求的方式。然而对于服务器不同的情况，选择这种方式就意味着能力比较弱的服务器也会在下一轮循环中接受轮循，即使这个服务器已经不能再处理当前这个请求了。这可能导致能力较弱的服务器超载。

2、加权轮询算法解决了简单轮循调度算法的缺点：传入的请求按顺序被分配到集群中服务器，但是会考虑提前为每台服务器分配的权重。配置人员只是简单的通过服务器的处理能力来定义各台服务器的权重。例如，性能最强的服务器A给的权重是100，同时性能最低的服务器给的权重是50。这意味着在服务器B接收到第一个请求之前前，服务器A会连续的接受到2个请求，以此类推。

3、最小连接数算法，上述两种方法都没有考虑的是系统不能识别在给定的时间里保持了多少连接。因此可能发生，服务器B服务器收到的连接比服务器A少但是它已经超载，因为服务器B上的用户打开连接持续的时间更长。这就是说连接数即服务器的负载是累加的。这种潜在的问题可以通过"最少连接数"算法来避免：传入的请求是根据每台服务器当前所打开的连接数来分配的。即活跃连接数最少的服务器会自动接收下一个传入的请求。基本上和简单轮询的原则相同：所有拥有虚拟服务的服务器资源容量应该相近。值得注意的是，在流量较低的配置环境中，各服务器的流量并不是相同的，会优先考虑第一台服务器。

论文背景

2021年8月，我有幸参与了某地产集团智慧营销平台项目的研发，该平台主要采用端、边、云的技术架构，以实现人员到访管理、人脸识别、同行人分析、首访管理，认购签约、人证核验、飞单判断、飞单管理、到访推送等功能。我在该项目中担任系统架构师角色，主要负责系统架构设计的相关工作。本文以该平台为例，主要论述了ATAM架构评估方法在该平台的具体应用，首先通过该平台的业务人员和领域专家收集需要与场景；其次，结合收集的需求及场景，通过评估小组会议，描述架构视图与场景实现；最后，通过评估小组会议确定系统的质量属性，对属性模型进行构造分析，并对其中的一些权衡点做折中。通过以上架构评估的实施过程，对后续项目的顺利实施提供了有力的支持，最终项目顺利上线，受到集团领导及用户的一致好评。

近年来，随着国家“住房不炒” 政策写入政府工作报告，叠加疫情影响，国民收入逐渐下降，整个国民经济增速也进入了下降趋势。作为国民经济三架马车之一的房地产行业，也开始进入了下行通道。我所在的某地产集团，2021年上半年，居住房地产业务同比下降30%以上，在这种情况下，佣金支付的成本占比却在不断增高，高达上亿元。而这其中，渠道舞弊导致的佣金支付，是一直以来困扰集团的难题。所谓渠道舞弊，是指自然到访的客户，在职业顾问、外部渠道员工等人的暗箱操作下，使其变成外部渠道的客户。外部渠道的客户在进行购房签约后，集团需要对外部渠道支付一定比例的佣金。也正是基于这样的背景下，2021年9月，集团以数字化为契机，利用图像识别技术，打造整个集团的智慧营销平台，彻底解决渠道舞弊现象，并为营销业务降本增效。本系统在营销门店部署边缘服务器，并采用最新的视频流抽帧及图片特征值不可逆加密技术，不需要存储原始图像信息，从而符合国家个人信息保护法对隐私合规的要求。
该平台采用SpringCloud作为技术基础架构，Nacos作为服务注册中心和配置中心；Redis Cluster作为缓存和分布式锁，Kafka作为到访明细的消息队列，用来接收所有边缘服务器上报的到访明细，削峰填谷；Elasticsearch作为到访记录及用户到访备案，支持全文检索。该平台通过部署在全国各个营销门店的边缘服务器，利用图形识别、同行人分析技术，识别到访人及同行人，形成到访信息，上报至云端Kafka，生成首访信息及到访记录；客户在购买签约时，生成签约信息，并利用小程序或营销门店的人证一体机，完成签约人的人证核验；系统会自动对已核验的签约信息进行飞单逻辑处理，校验当前签约是否属于渠道舞弊，并根据校验结果来作为佣金支付的依据。我以系统架构师的角色全程参与了此平台的建设，智慧营销平台由BP、产品组、研发组、测试组、人工智能组等共32位人组成的团队，耗时9个月完成。项目于2022年5月开始在多个城市试运行上线，实际运行效果远超期望，获得了集团领导的一致好评。