美文网首页
High-Level Solution Design & Arc

High-Level Solution Design & Arc

作者: 67fbeff17243 | 来源:发表于2018-06-11 16:20 被阅读0次

    Isolation & Monolithic

            SOA讲究的是闭包,Block状的自主服务存在;Microservices更关心的是隔离和单体系统。但是其关键是“隔离”,保障其每一部分都是一个独立自主且存在生态的部件。则架构设计则需要在全面理解业务需求及非功能诉求的前提下,梳理数据、信息、业务、操作等等的流程和关键资源协同情况,将一个End-to-End业务或操作流程,转化为一个体系及连贯的架构实现。然后将合理的资源,按照适时的计划,针对性的投放到详细设计及实现中。

            对比如下两个Diagram,一份来自于SkyTeam的官网流程,Retro二期。一份是针对其的架构FMC设计。官网的流程描述的若干实体之间的分工,但是如何在某个实体内部,提供哪些服务、部件、逻辑组成,则需要专业人员端到端的梳理及设计。否则详细设计阶段发生的不仅仅是业务全局理解的问题,更可能出现后续对接的混乱。但是一个完整的架构设计,更需要考虑不同部件或模块之间的差异性,允许适当的不同技术或实现体系,其只需要定义明确的接口规范即可保证后续的交互的一致性及上下游流转的顺畅性,也能确定End-to-End的交付成果。

    官方流程图 架构设计FMC图

    Interface

            隔离或单体的构建,最终还是要协同的编排实现一个完整的End-to-End的流程,所以合理的架构设计也需要定义规范性且适当通用的上下游交互的接口规范。接口的含义可以是广义的各类对接形式的俗称,也可以是以Web服务类为主的具体网络接口。但是其都是扮演着上下游对接的具体形式、规格、频度、扩展性等等。其最关键的环节是设计并约束规范上下游的数据契约,并将其与具体业务模型,和不同对接点的数据契约进行规范化统一化处理。

            如果是传统企业数据架构或治理中的,主数据管理,其实其最有效的使用场景就是用于定义上下游交互的数据契约。其能够充分描述某个业务数据模型的全部必须特征及规范性的元数据使用。

            但是对于现在企业级或任何项目及系统,数据契约是关键,更需要在架构设计中明确交互方式等其他指标,例如频度、推或拉、技术平台、事务、异步系统同步及完整性,等等一系列问题。同时在实际场景,往往需要设计通用或前瞻的数据契约,保障后续数据结构、数据量等等的变化。


    Extensibility

            好的架构不仅仅需要关心Scalability,更需要考虑后续变化的应对,从模块化等角度和手段,全面提升系统的可扩展性。不能总盲目关注当前需求和诉求,以及对应的资源。适当应该以前瞻性的思维考虑和设计方案,方案中每个环节都可以完全独立的被替换或被重构,而不影响关键的业务流程及既有功能。

            例如现有公司产品,低价预测权益类的产品。其中对于科学计算模型的使用,就会根据不同OD市场、时间、场景、数据等等,变换不同的数据模型来计算及运行。这一系列的模型选择逻辑和动作,就需要架构设计的时候将其定义为比较灵活和方便且即使响应的工具。

            考虑如下场景,不同的OD市场,为了模型的准确性,则需要不同OD市场或航线对应不同的科学计算模型来协同返回结果,设置不同的时间周期、淡旺季等等,都需要特殊的模型对应。或者由于输入的参数不同,需要针对性的进行模型运算。但是过多的针对性支持,则就需要不同的模型来对应,造成过多model文件,难于管理等。则需要引入模型调用配置化进行扩展和支持,同时对于模型调用的特性进行封装。

    a) 通过ModelId唯一识别某特定模型处理范围。

    b) 通过Version指定模型的处理能力。

    c) 通过ScenarioId告知模型的处理场景和分支逻辑。

    d) 通过ModelLocator实际关联模型具体位置等信息。

    e) 通过ModelWrapper封装具体模型与调用之间的实现。

    f) 通过Parameterset和Resultset自动化配置及封装各类参数转换。


    Toolset

            扩展能力的考虑及前瞻性的深入思索,将带来的是工具化的可复用能力的提升。同时随着业务的深入、变化的发生、资源的重复利用等等,工具化的程度将更高,最终变为通用工具,横跨若干系统、应用、以及企业内部资源。

            就好比之前老东家的Message Engine,单纯从一个字符串消息转化的角度,硬生生做成一个PaaS平台,并可以单独打包销售的产品。其终结因素是一定要在架构设计的角度充分考虑技术服务于业务的场景,并针对性的前瞻考虑可扩展能力和期望值。用高效的架构设计及技术设计,寻求全新的业务需求。



    Platformization

            但是最终一个好的架构及企业内部架构发展,终将会将各个Toolset融合为平台化的引擎能力。就好比电商中后台近期所提倡的服务中后台、数据中后台、监控中后台等等。其原来都是在业务诉求之外,更非NFR诉求之内的组件。由于业务的深入和使用的频度,更关键是与业务诉求的融会贯通,使其能够工具化,再继续平台化,变为一个技术为主导的业务功能群组。

            好的架构设计不一定能够预见其设计的部件会成为平台,但是其设计必须能够在未来被转换为平台。其关键的评定因素是上述的模块化、可插拔、隔离等等。

    To be continued...

    相关文章

      网友评论

          本文标题:High-Level Solution Design & Arc

          本文链接:https://www.haomeiwen.com/subject/vvgceftx.html