0
回答
哈,从系统的周期性与反馈类事务谈系统设计
利用AWS快速构建适用于生产的无服务器应用程序,免费试用12个月>>>   

这里水一下我对系统运行机理和架构设计的一些个人观点。哈。年少无知时,对系统架构的理解就是各种架构图。看上去很高大上,有层级,有框框。不否认这类图或这类对系统的表述是有价值的。但从系统分析设计的角度,这仅仅是设计过程中的一个局部工作成果而已。至少这类图,体现不了系统中,周期性和反馈类事务。
系统设计,经常有两个词,“自顶向下”,“自底向上”。最近越发觉得,如果单纯从这两个之一来构建设计一个系统,肯定会掉坑里去。原因也是如我标题所言,存在两类事务你无法表述。
周期性事务,对于电子自控系统几乎是必然存在的。计算机死机,不是停止计算而是掉到死循环里,这算是一种周期性事务的极端,哈。而在很多系统的顶层代码中,经常有个用于描述和执行状态机的死循环。这也是种极端。而具体功能中,如定期检测键盘信息,定期采集传感器信息,定期检测cache是否有更新数据,这些都是周期性事务。
反馈类事务就比较直观了,典型的如PID控制,其实软件设计时,遇到回调函数,通常也是因为有反馈类事务而如此设计。广义的说,具备因果关联的周期性事务就是反馈类事务。
或许你会说,我是程序员,我负责写程序,和这些系统问题无关。好吧,如果你只是如用c语言在一个main里面写个printf("hello world!\n");然后退出。那就当我啥也没说。哈。
当然也许你会说,我只负责界面设计,其他与我无关。但我觉得ui美工和前端程序员的差异应该在于,后者需要考虑例如界面回退时原有数据是保留不变还是要刷新等数据在一致性、实时性、有效性等相关问题。这里实际也包含了周期性和反馈类事务。
系统从需求者角度,看到的是一个个具体的需求,可以细分、归类,无论是用“自顶向下”还是“自底向上”,来列出列表或类树状图。但从设计角度,我们构建的系统是有限状态的。各个需求功能总能对应到系统中由多个有机关联模块的组合事务,在某个状态下的运行表现。
这里有两个很悲催的客观事实。
第一,不同需求所需要的功能,通常总存在一些共性的内容-子功能,此时你自底向上的设计,将各个基础执行模块进行关联堆叠对应各个需求功能,会发现上层很难归集。例如,你有按键检测模块,你有两个需求,1)按下特定按键,系统进行模式切换(睡眠模式与工作模式的相互切换);2)按下按键则将按键信息发送给xx。如果你的系统按照三层分类,底层是执行/感知层,中间是逻辑层,顶上是模式或决策层,那么把这个图做出来,很难说是个树状图。
第二,需求列的越清楚,越会割裂需求点之间的关联,而事实上多个需求之间,总存在一些时序上的因果关联。此时你自顶向下设计时,大系统下面是大模块,大模块里面是小模块,结果设计出来的规划图压根和具体开发内容没有直接联系。于是,某个需求的局部调整,设计是从前端界面到后端数据的各种改。其实每次改动就是那么一点点(从需求者角度来说),而几次改动之后,具体的设计就是一地鸡毛(这也是开发与业务需求人员存在阶级仇恨的根源)。
上述问题不单单针对程序设计,如我现在忙的自控系统设计也存在这个问题。而以前研究智慧城市,各种“顶层设计”,各种框架图、层级图也存在这种问题。
出现这种悲催的问题,其原因就是,需求表述与系统运行机理是两回事。具体需求,是通过系统内各个模块的有机组合,协同运行来实现的。此时,你用需求及其分析成果来对应构建系统设计,不是在挖坑就是在挖地道,反正是暗无天日的工作。
那么正常的设计路径应该是,先自底向上,以系统可实现的具体原子功能,堆砌出一个个组合功能。这些组合功能要么是逻辑堆叠,要么是时序关联。而这些组合功能对应需求中所要求的具体内容。
随后是基于事务的周期性分析,将不同的组合功能,进行合并归集。形成系统大状态下的各类小状态。此时在归集后的设计,是个自顶向下的过程。
所谓事务周期性分析,就是针对一个具体功能要求,从开始到结束的单一周期内,对各个阶段状态进行表述。简单说,就是我要干啥(这是需求要的功能),那么我就一步步的实现(这是运行机理的表述)。开始和结束这个容易分析,而中间如何划分阶段状态则有难度。从我个人的经验来看,一个功能执行周期内的阶段划分,依据两方面。第一,执行中所依赖的模块差异,第二,执行中对数据的需求差异。
第一点容易理解,第二点通常会被忽略。如上面按键的例子。采集的信号,需要进行数据处理形成内部规范的按键状态信息,而这种状态信息会被两个需求的实现功能所利用。那么你定期采集的数据(这和是查询方式还是中断方式无关,这两种方式仅仅是触发采集动作的方式)应该统一处理,作为一个单独的阶段。
我们不同的需求,其实内在包含了不少相同的中间数据。提需求的人,永远不关心你怎么实现,但你不区分差异需求中对数据的共性要求,则在后期需求出现对某个环节的数据处理变动时,要么改了这个功能,导致那个功能失效,要么更新了这个功能,而那个功能还要重复修正设计。
回到系统设计上,这种基于执行模块和数据依赖进行事务周期内阶段划分的目的,其实是为了对事务进行归并关联。如果两个需求对应的两个执行事务周期存在相同阶段,则这两个阶段对应的结点需要合并,由此形成两个具体功能对应事务的关联。这样可以化简目标系统内模块的状态(系统状态-是指某个阶段处理工作时的系统表现)。
需要说明,事务的周期和周期性的事务,是两回事。标题说的是周期性事务,就是随时间轴,因各类触发,导致系统或系统局部进入了相同的处理工作状态。
如果非要问我,一个系统里是否存在非周期性事务?我的个人观点是有的,而且还是两个,一个是启动系统,一个系统退出/关机。哈。即便是系统软重启时各个模块的初始化,都肯定属于一个大周期内的事务,而有可能被周期性调用(看触发条件了)。
上面提到了“大周期”,其实还有个概念是,“局部周期事务”。典型的如反馈类的事务。当我们触发了一个“局部周期事务”,则在系统的大状态不变下,它会“自动”运转。这种局部周期事务内在可能是固定的执行步骤,也可能包含一个状态机,在时序上存在差异的处理工作阶段,但总体而言,它属于某个更“大”周期的事务。而在这个更"大"的事务中,包含了优先级、触发等等决策判断工作。
到此,似乎我们都在“自底向上”的分析和设计系统,曾经我认为确实这样就足够了。但我发现这样解决不了一个问题,系统架构设计的问题。简单说,你无法构建初始系统原型(仅包含部分被弱化的需求所对应的功能,而能涵盖住一些底层模块的基本内容)。说人话就是,你让各路工人各自忙各自的,却没有一个统一的图纸来约束各自的工作,结果可想而知,你做的越多,等系统连调时,bug越多,甚至无法构建一个运行起来的“系统”。
出现这样的问题,我个人的观点是,系统不是简单的模块堆砌。而是子模块在有机的关联下,按照系统层级的方式有序运行。模块之间因事务形成的关联是执行层面,而系统层级是组织层面。例如,一个团队,各有分工,围绕项目需求,大伙凑凑一起开展工作,这是自底向上的设计就可以完成的。但针对团队本身,怎么构建好一个组织,能更有效的完成各种项目,甚至某些人同时参与两个及以上项目,这得自顶向下的设计,公司的hr是服务于大家的嘛,而不是专属于某个项目-需求所对应的事务,哈。
系统的组织问题,这个要谈,可以另外水个帖子,此处不多说。但有一点,组织层面和执行层面不是完全对应的。说个晦涩的例子,例如某个公司要裁人,按理说,应该从执行层面考虑,那些性价比不高的人应该裁掉-拿钱多,但执行成绩少的,要先砍掉。但是某些“天才”和“专家”,虽然不干活,拿着高薪,一旦出走,要么自立门户,要么协助竞争对手,此时就不该裁,而是高薪的把他养废掉。 这个例子很直接,是很多大公司惯用的手段,组织人力往往不是简单的从执行能力来看的,包括养了个官二代。哈。
回到系统的组织层面,则应该根据已经分析得到的各个抽象事务中的共性,来进行组织。此时,是个“自顶向下”,逐步具体化的过程。这个“自顶向下”,通常与具体需求无关,而是和不同抽象级别下事务的类别有关。
例如,最顶层,通常是采集、处理、执行这个大周期性事务。你会发现,这个和任何具体执行事务没有对等的关联,但又不可或缺。如果你采集的信息会针对两个执行事务,无论哪个事务先启动采集处理工作都是不太妥当的。而对于自控系统,很多模块都是独自异步运行通过数据同步来实现关联的,但主控系统也是需要定期检测各个模块的工作状态,从而来决策系统的运行状态,例如某个模块是否掉链子了,无论是不通信了还是报警要罢工了,从系统主控角度都要有相应的策略和应对机制。
其次是主控决策层的状态机设计,再次是最大分层模块的状态机的设计,随后,是依次按照系统模块归属,细分下去。
好吧,我说了一个系统分析方法,其实到现在也挖了个坑,因为我没解释“自底向上”,按照事务周期内阶段进行归集的分析工作,与“自顶向下”按照事务抽象类别及模块划分的分析工作之间的对应关系。
一个系统,分几个大模块,大模块下又有隶属的子模块。这是模块划分。这个问题的解决,实际是通过“模块定义”来完成。不同层级的模块怎么定义?我个人的经验是,通过对需求的再分析得来。将需求分析所对应的事务进行类别划分,进行归集,形成大模块,随后再细化。简单举例是,我们要对一个团队进行组织建设,比如业务部,开发部,行政部。而从做一个公司角度,需求是啥,不就是做各种业务嘛。但是不同业务类别,有不同的处理步骤,这对应了大的事务的各个处理步骤中所存在的分工。这些分工则是小事务。我们把小事务进行归类,对应人员则是不同部门。这些部门也就是系统的模块组成。

你会说,这不还是自底向下嘛。好吧,你去问问你同事中的老员工,在公司发展过程中,是先出现了诸如,系统设计部,算法部,开发部,测试部这些具体部门;还是当初仅有一个“开发部”,随着业务的发展而逐步细分出各个子部门?

通常部门细分不会是简单的因为新增业务导致,而是因为业务的发展,数量和复杂度的提升,需要工序工种的细分来明晰责权,提高效率。说这些,或许你能理解,系统的模块划分是个自顶向下的工作。
最后,我稍微填一下上面的坑,关于事务周期的分析与系统模块划分的关系。一句话,在关联时他们不是一一对应关系,而是覆盖包含关系。因为系统组织问题和系统执行的事务周期是两个维度的内容。当一个系统的组织,能合理的对应各个事务周期的阶段,则这个系统设计是有效的。回到上面的例子,当一个企业的部门组织,能有效的促进对外业务和对内管理工作的开展,那么这个企业的组织是有效的。哈。不知道这个例子是否能帮助还没有系统设计能力的朋友们思考系统设计的问题。

<无标签>
举报
中山野鬼
发帖于10个月前 0回/83阅
顶部