精华内容
下载资源
问答
  • 2021-01-21 22:42:05

    要点

    1. 设计软件架构图并非一件轻而易举的事情,即使是很简单的一个架构图也可能会出错。有意义且具备一致性的架构图有助于为不同的利益相关者澄清事实,并达成共识。
    2. 在大多数情况下,问题的根源并不在于是否使用了一门有效的架构描述语言(比如UML),而在于低估了架构图的重要性,转而依赖不恰当或不具备一致性的指导性原则,或者缺乏架构思维。
    3. 在创建架构图的过程中,试着混合使用自动生成的图元和手动创建的图元,这样可以减少工作量,并且可以表达出各方面的关注点,覆盖到系统的各个层面。
    4. 系统不断地发生演化,要维护更新架构图需要花费额外的精力。我们需要知道如何有效地应对这种情况,同时能够保持架构图的一致性和健壮性。
      现代的软件架构带来了更多的复杂性,这些都反映在了架构图上。

    曾几何时,我们的每一个软件项目都需要一个架构图。不管我们是否遵循正式的架构模型(比如Kruchten 4+1、Rozanski & Woods等),都有必要通过图表来对应用程序的某些部分进行文档化。在软件架构里,这些图表一般都是按照某些视图进行设计的,这些视图本身就是模型的一部分,不过在这篇文章里,我倾向于使用架构图这个术语,因为它看起来不是那么正式,至于其他方面的内容并不会在这篇文章里涉及到。

    作为一个软件架构师和技术培训师,从我的经验来看,不同项目之间以及同一个团队的不同开发人员之间创建架构图的方式也是很不一样的。我看到过很多问题,比如一致性问题、碎片化问题、信息粒度大小的问题,以及图表的外观问题。相比架构模型的正式和标准化,架构图倒是不必要那么正式或者遵循什么标准。

    相关厂商内容

    解读百度PB级数据仓库Palo开源架构 Snapchat大规模个性化推荐引擎解密 微信社交广告核心架构与图计算存储 摩拜单车:如何通过机器学习等技术提高单车运营效率 获取面向人工智能、机器学习和深度学习的最新工具、框架
    相关赞助商

    不过,架构图必须是自描述的,并且要具备一致性和足够的准确性,能够与代码相呼应。这也就是为什么架构师或软件工程师在创建架构图时需要依赖各种指导性原则,因为它们是理解应用架构(比如结构、元素、关系、属性、原则)的基石,同时也是具有不同技术背景和关注点的利益相关者的沟通基础。

    当前架构图的不足之处

    在深入展开说明之前,我想引用一句英语谚语:“一张图片胜过千言万语”。Wiki上解释说,“这句谚语的意思是,一个复杂的想法可以通过一张静态的图片表达出来,或者图片可以表达一个主题的意思,又或者图片比文字描述来得更加直接有效”。对于架构图来说也是一样的:如果它所导致的疑问比它能解释的问题还要多,那么它就不是一张好的架构图。一张好的架构图不需要多余的文字解释!


    图片:一张不是很好的架构图一般会存在如下几个问题。

    现在让我们来过一下不好的架构图都有哪些问题,这些问题会阻碍我们创建好的架构图。

    方框或其他形状表示什么意思?

    随意使用方框或其他形状可能会引起误解。这些形状有可能表示数据、代码或者流程。一个简单的方框可能会引起多种猜想,所以很有必要显式地给这些形状添加有意义的说明。

    形状的边线表示什么意思?

    在一个糟糕的架构图里,形状的边线(虚线、点线,等等)可能会引起误解。边线是否表示某种组件类型(比如虚线表示容器、微服务、层,等等),或者只是因为设计者想让架构图的观感看起来更加丰富一些?所以,在使用多种边线或非标准边线时,要在图例里提供准确的说明。

    线条或箭头表示什么意思?

    线条或箭头可以被理解为数据流(比如从系统A到系统B的数据流)或元素间的关系(比如组件A依赖组件B)。在大多数情况下,箭头所表示的关系或数据流并不会总是汇聚到同一个方向上,所以很有必要在图例里说明清楚。

    线条或箭头表示哪一种类型的交互或关联?

    尽管线条可以表示数据流或组件间的关系,但用于表示交互类型(对于数据流而言)或关联类型(对于关系而言)的线条或箭头仍然需要详细说明。例如,如果使用线条表示数据流,那么交互类型可以是同步或异步的,但如果线条表示的是关系,那么关联类型有可能是指依赖、继承、实现,等等。这些细节必须在图例里说明。

    颜色代表什么意思?

    一个使用了多种颜色的架构图却没有适当的文档说明很容易引起误解(比如为什么有些方框是绿色的,而其他是红色的?为什么有些线条是黑色的,而有些是蓝色的?)。颜色在架构图里的作用不是非常大,添加太多的颜色并不会给架构图带来更多有价值的信息。一个仅仅使用了黑白两色的架构图也应该是不言自明的,除非非常有必要使用特定的颜色来强调图中的某些部分。在任何情况下都要保持颜色的简单性,如果一定要用多种颜色,不要忘了添加说明。

    单独的元素或实体

    如果架构图中出现了单独的元素或实体,说明架构图有可能是不完整的。不管是从结构还是从行为角度来看,每一个元素或实体都应该依赖系统的其他部分,或者与它们之间存在某些联系。
    费解的缩略语或含糊不清的名词

    在为架构图中的元素添加标签时,切忌使用费解的缩略语,这样容易引起困惑。如果没有恰当的说明,字母的堆叠(比如TFH、RBPM,等等)就毫无意义,最好在图例里进行说明(比如TFH表示ticket feed handler,RBPM表示rates business process manager)。
    在给元素命名时,另一个常见的问题是使用了含糊不清的名词(比如业务逻辑、集成逻辑),这些名词并不能做到自解释。代码里可能也会存在这样的问题,我们建议遵循清晰的代码原则,使用自解释的名字。

    在架构图中详述技术、框架、编程语言、IDE或开发方法论

    架构图并非以技术、框架、编程语言、IDE或开发方法论为基础,它们只是用来实现架构的工具,而不是中心关注点。它们不应该被包含在架构图里,不过可以在架构描述里简述使用它们的理由。
    在同一个架构图里混杂运行时元素和静态元素

    运行时元素(比如线程、进程、虚拟机、容器、服务、防火墙、数据仓库,等等)不会出现在编译阶段,而且不应该与静态元素(比如组件、包、类)同时出现在同一个架构图里。针对运行时元素有专门的类型图(比如并发图、部署图),一定要注意区别这两种元素,尽可能避免把它们混杂在一起。
    “稍后详述”或“稍后解释”

    不包含在架构图里的任何信息都有可能丢失,而架构图里并没有额外的地方可以容纳口头说明。所有的口头说明都会丢失,当其他利益相关者(比如开发人员、架构师)查看架构图时,他们并不知道原来还有所谓的口头说明。试着把所有必要的信息都包含在架构图里,而不是事后加以说明。
    层级冲突或混合抽象

    在同一个架构图里添加不同层级的抽象可能会导致冲突的出现,因为它们是从不同的角度描述问题的。例如,把组件添加到上下文架构图里,或者把类加到部署图里,这些都会偏离架构图原先的目的。在创建架构图时,试着保持相同的抽象层级。
    使用混乱或含糊不清的架构图表达过量的信息或无效的细节

    爱因斯坦曾经说过,“凡事应该尽可能简单,简单到极致”。对于架构图来说也是一样的,我们需要谨慎地选择信息的层级和粒度,这并不是一件容易的事情,它取决于所使用的架构模型、架构师的经验和系统的复杂度。
    在创建架构图时可参考的指南

    除了上面列出的问题清单,还可以参考如下的一些指南来创建更好的架构图。

    选择最优的架构图数量

    Philippe Kruchten说过,“架构是一项复杂的工作,只使用单个图表来表示架构很容易造成莫名其妙的语义混乱”。要对系统进行良好的文档化,我们不能只使用一种图表。不过在创建架构图的时候,我们也难以确定该使用哪些类型的架构图以及应该创建多少个。在做出决定之前,我们需要考虑多方面的因素。例如,架构的属性和复杂度、架构师的技能和经验、可用的时间、维护成本,以及利益相关者的关注点。网络工程师可能想看到包含了主机、通信端口和协议的网络模型,数据库管理员更关心如何系统是如何操作、管理和分布数据的。所以,我们要选择最优的架构图数量,不管这个数字是多少。
    糟糕的架构图(比如缺乏文档)可能会缺失一些信息,反过来说,如果架构图太多(比如过度文档化),那么用于保持架构图一致性和更新架构图的工作量也会相应增加。

    保持架构图的结构一致性和语义一致性

    架构图之间应该在方框、形状、边框、线条、颜色等方面保持一致。架构图的结构外观应该是一样的,团队不同成员创建的架构图不应该给任何一个利益相关者造成理解上的障碍。理想情况下,可以在所有项目里使用相同的建模工具。
    从语义角度来看,所有的架构图与最新的代码变更之间以及架构图与架构图之间都应该定期保持同步,因为一个架构图的变更可能会影响到其他架构图。同步可以通过手动进行,也可以通过建模工具自动触发。通过建模工具自动触发会更好一些,不过这也取决于具体的项目。最终的目的是要保持架构图和代码之间的一致性,至于使用什么样的方法或工具可以自行决定。Simon Brown说,“如果架构图与代码失去了联系,那么就无法用来改进架构”。他的话其实是在强调保持语义一致性的重要性。
    避免架构图碎片化

    架构图越多就越难以理解,而且维护起来也很费劲。最直接的后果就是有可能出现碎片化(比如,通过两到三个架构图来描述同样的质量属性——性能、伸缩性,等等——但每一个架构图都无法完整地描述它们)。在这种情况下,建议移除不能反映相关质量属性的架构图,或者把它们合并起来。

    保持架构图的可追踪性

    保留架构图的变更记录、比较不同版本架构图之间的不同点,以及可以很容易地进行回退,这些都是很重要的。如果建模工具不支持这几点,那么对我们来说可能会是个问题。最近业界倾向于使用简单而直接的文本语言来生成架构图,这样似乎可以解决可追踪性问题。这样做的另一个好处是可以保持架构图之间的结构一致性。
    在架构图旁边加上图例

    如果你没有使用标准的架构描述语言(比如UML、ArchiMate),那么就要在图例里注明每个架构图元素的用意(比如方框、形状、边框、线条、颜色、缩略语,等等)。
    如果使用了标准的架构描述语言,只要在图例里添加关键性的架构描述,不需要太多额外的信息,因为看图的人都知道如何按照标准的描述语言规范来理解你的架构图。
    使用架构描述语言(比如UML、ArchiMate等)会有不一样的效果吗?

    关于如何在项目里使用正确的架构描述语言有很多不同的看法。有些人认为UML太过死板,用来做架构设计缺乏灵活性,在某种程度上我认同这个看法。有时候,在不依赖UML的profile和stereotype特性的情况下也能很好地完成架构图设计。至于说到其他的架构描述语言,我认为ArchiMate更加强大,相比UML,它更适合用来为企业系统建模。还有BPMN,它更专注业务流程的建模。对这些工具进行深入比较已经超出这篇文章的范围,所以不再累述。

    在选择架构描述语言时,综合性和灵活性是首要考虑的因素。但据我所知,完全不使用架构文档的情况也很常见。有些人觉得创建架构文档是一件很无聊的事情,而且觉得它们没有什么意义。这样的项目应该不在少数。人们因为没有使用合适的架构描述语言,所以创建不出很好的架构图,相反,如果他们使用了更好的工具,结果可能会大不一样。但事实并非如此,实际上他们跟本不想去创建什么架构文档(包括架构图),更糟糕的是,他们可能不知道该如何创建架构图。这是我们首要解决的问题——了解文档的重要性以及如何创建它们(给软件工程师做培训),然后选择合适的工具。

    在系统和架构发生变化时如何更新架构图?

    更新架构图有几种方式,我将会介绍其中的三种。第一种,也是最简单的一种,就是直接从代码生成架构图。这样可以保证架构图与代码是一致的。不过目前的工具还不能完全支持这种方式,在没有人工介入的情况下,工具还无法基于代码生成精确且有意义的架构图。Len Bass说,“在最理想的开发环境里,只需要一个按钮就能得到我们想要的文档”。他指的就是自动生成架构图,但我们还远远没有达到那种程度。

    第二种,先用建模工具创建架构图,然后生成代码骨架(比如组件或包、API),随后开发人员可以在骨架上添加代码。每次架构图发生变更,需要从架构图端重新生成代码骨架。

    第三种,在每次加入新特性时手动更新架构图。为了保证代码与架构图的一致性,建议把更新架构图作为开发流程的一部分。不过我们不推荐这种方式,因为这样很容易造成架构图过时或出现不一致(比如开发人员总是忘记或者不想更新架构图)。

    我的建议是混合使用现有的工具,结合手动和自动的方式来创建架构图。例如,尝试自动生成架构图,使用工具基于代码渲染出符合基本要求的架构图,不包含混乱无用的信息。架构图可以高度可变(比如可以适应频繁的开发变更,这类架构图一般具有较低层次的抽象),也可以是静态的。这类图表可以是上下文架构图、参考架构图、包图、类图、实体图,等等。不过有时候仅仅基于代码无法生成满足需求的架构图,所以在这种情况下,自动创建架构图不是理想的方式。这个时候需要手动建模作为补充,这类架构图包括时序图、状态图、并发图、部署图、运营图,等等。

    现代架构(如微服务)对架构图有什么影响?

    微服务或其他任何一个现代架构风格(如无服务器、事件驱动)只会影响到系统的结构、组件间的交互方式(比如组件间的关系)和原则。在我看来,我不认为架构风格会改变架构图原先的含义。不过,相比传统的系统(比如单体),我们所说的现代系统架构具有更高层次的复杂性,它们对架构描述和架构图确实会有一些影响,这些是我们需要注意的。我们需要考虑分布式组件(比如分布式微服务)、每种组件的类型、组件间的交互方式(比如边界、API、消息)、他们的生命周期以及从属关系。

    综上所述,我们需要在架构图中体现系统的分解、开发、部署和运维。假设有一个包含了大量微服务的系统,它就会有很多的架构图,因为每个微服务都可能有自己的架构图。一致性(例如,改变一个服务的API会影响到其他服务,所有相关的架构图都需要做出修改)、碎片化(例如,一个架构图无法反映分布式服务的高可用性和性能)和横断面(例如,是谁在负责处理系统的监控或安全问题)问题会让人手忙脚乱。我们首要面对的挑战是如何进行良好的团队协作,不仅仅是开发,也包括后续的维护。

    总而言之,现代系统的复杂性会带来额外的问题,它们会在架构图层面造成一定程度的影响。

    出处: http://www.infoq.com/cn/articles/crafting-architectural-diagrams
    
    更多相关内容
  • 软件架构图的艺术

    2021-08-16 01:01:14
    公众号回复'架构'获取架构师电子书及视频课程要点设计软件架构图并非一件轻而易举的事情,即使是很简单的一个架构图也可能会出错。有意义且具备一致性的架构图有助于为不同的利益相关...


    公众号回复'架构'获取架构师电子书及视频课程

    要点

    1. 设计软件架构图并非一件轻而易举的事情,即使是很简单的一个架构图也可能会出错。有意义且具备一致性的架构图有助于为不同的利益相关者澄清事实,并达成共识。

    2.在大多数情况下,问题的根源并不在于是否使用了一门有效的架构描述语言(比如UML),而在于低估了架构图的重要性,转而依赖不恰当或不具备一致性的指导性原则,或者缺乏架构思维。

    3.在创建架构图的过程中,试着混合使用自动生成的图元和手动创建的图元,这样可以减少工作量,并且可以表达出各方面的关注点,覆盖到系统的各个层面。

    4.系统不断地发生演化,要维护更新架构图需要花费额外的精力。我们需要知道如何有效地应对这种情况,同时能够保持架构图的一致性和健壮性。

    5.现代的软件架构带来了更多的复杂性,这些都反映在了架构图上。

    曾几何时,我们的每一个软件项目都需要一个架构图。不管我们是否遵循正式的架构模型(比如Kruchten 4+1、Rozanski & Woods等),都有必要通过图表来对应用程序的某些部分进行文档化。在软件架构里,这些图表一般都是按照某些视图进行设计的,这些视图本身就是模型的一部分,不过在这篇文章里,我倾向于使用架构图这个术语,因为它看起来不是那么正式,至于其他方面的内容并不会在这篇文章里涉及到。

    作为一个软件架构师和技术培训师,从我的经验来看,不同项目之间以及同一个团队的不同开发人员之间创建架构图的方式也是很不一样的。我看到过很多问题,比如一致性问题、碎片化问题、信息粒度大小的问题,以及图表的外观问题。相比架构模型的正式和标准化,架构图倒是不必要那么正式或者遵循什么标准。

    与100+国内外技术专家探索2017前瞻热点技术

    不过,架构图必须是自描述的,并且要具备一致性和足够的准确性,能够与代码相呼应。这也就是为什么架构师或软件工程师在创建架构图时需要依赖各种指导性原则,因为它们是理解应用架构(比如结构、元素、关系、属性、原则)的基石,同时也是具有不同技术背景和关注点的利益相关者的沟通基础。

    当前架构图的不足之处

    在深入展开说明之前,我想引用一句英语谚语:“一张图片胜过千言万语”。Wiki上解释说,“这句谚语的意思是,一个复杂的想法可以通过一张静态的图片表达出来,或者图片可以表达一个主题的意思,又或者图片比文字描述来得更加直接有效”。对于架构图来说也是一样的:如果它所导致的疑问比它能解释的问题还要多,那么它就不是一张好的架构图。一张好的架构图不需要多余的文字解释!

    图片:一张不是很好的架构图一般会存在如下几个问题。

    现在让我们来过一下不好的架构图都有哪些问题,这些问题会阻碍我们创建好的架构图。

    方框或其他形状表示什么意思?

    随意使用方框或其他形状可能会引起误解。这些形状有可能表示数据、代码或者流程。一个简单的方框可能会引起多种猜想,所以很有必要显式地给这些形状添加有意义的说明。

    形状的边线表示什么意思?

    在一个糟糕的架构图里,形状的边线(虚线、点线,等等)可能会引起误解。边线是否表示某种组件类型(比如虚线表示容器、微服务、层,等等),或者只是因为设计者想让架构图的观感看起来更加丰富一些?所以,在使用多种边线或非标准边线时,要在图例里提供准确的说明。

    线条或箭头表示什么意思?

    线条或箭头可以被理解为数据流(比如从系统A到系统B的数据流)或元素间的关系(比如组件A依赖组件B)。在大多数情况下,箭头所表示的关系或数据流并不会总是汇聚到同一个方向上,所以很有必要在图例里说明清楚。

    线条或箭头表示哪一种类型的交互或关联?

    尽管线条可以表示数据流或组件间的关系,但用于表示交互类型(对于数据流而言)或关联类型(对于关系而言)的线条或箭头仍然需要详细说明。例如,如果使用线条表示数据流,那么交互类型可以是同步或异步的,但如果线条表示的是关系,那么关联类型有可能是指依赖、继承、实现,等等。这些细节必须在图例里说明。

    颜色代表什么意思?

    一个使用了多种颜色的架构图却没有适当的文档说明很容易引起误解(比如为什么有些方框是绿色的,而其他是红色的?为什么有些线条是黑色的,而有些是蓝色的?)。颜色在架构图里的作用不是非常大,添加太多的颜色并不会给架构图带来更多有价值的信息。一个仅仅使用了黑白两色的架构图也应该是不言自明的,除非非常有必要使用特定的颜色来强调图中的某些部分。在任何情况下都要保持颜色的简单性,如果一定要用多种颜色,不要忘了添加说明。

    单独的元素或实体

    如果架构图中出现了单独的元素或实体,说明架构图有可能是不完整的。不管是从结构还是从行为角度来看,每一个元素或实体都应该依赖系统的其他部分,或者与它们之间存在某些联系。

    费解的缩略语或含糊不清的名词

    在为架构图中的元素添加标签时,切忌使用费解的缩略语,这样容易引起困惑。如果没有恰当的说明,字母的堆叠(比如TFH、RBPM,等等)就毫无意义,最好在图例里进行说明(比如TFH表示ticket feed handler,RBPM表示rates business process manager)。

    在给元素命名时,另一个常见的问题是使用了含糊不清的名词(比如业务逻辑、集成逻辑),这些名词并不能做到自解释。代码里可能也会存在这样的问题,我们建议遵循清晰的代码原则,使用自解释的名字。

    在架构图中详述技术、框架、编程语言、IDE或开发方法论

    架构图并非以技术、框架、编程语言、IDE或开发方法论为基础,它们只是用来实现架构的工具,而不是中心关注点。它们不应该被包含在架构图里,不过可以在架构描述里简述使用它们的理由。

    在同一个架构图里混杂运行时元素和静态元素

    运行时元素(比如线程、进程、虚拟机、容器、服务、防火墙、数据仓库,等等)不会出现在编译阶段,而且不应该与静态元素(比如组件、包、类)同时出现在同一个架构图里。针对运行时元素有专门的类型图(比如并发图、部署图),一定要注意区别这两种元素,尽可能避免把它们混杂在一起。

    稍后详述”或“稍后解释”

    不包含在架构图里的任何信息都有可能丢失,而架构图里并没有额外的地方可以容纳口头说明。所有的口头说明都会丢失,当其他利益相关者(比如开发人员、架构师)查看架构图时,他们并不知道原来还有所谓的口头说明。试着把所有必要的信息都包含在架构图里,而不是事后加以说明。

    层级冲突或混合抽象

    在同一个架构图里添加不同层级的抽象可能会导致冲突的出现,因为它们是从不同的角度描述问题的。例如,把组件添加到上下文架构图里,或者把类加到部署图里,这些都会偏离架构图原先的目的。在创建架构图时,试着保持相同的抽象层级。

    使用混乱或含糊不清的架构图表达过量的信息或无效的细节

    爱因斯坦曾经说过,“凡事应该尽可能简单,简单到极致”。对于架构图来说也是一样的,我们需要谨慎地选择信息的层级和粒度,这并不是一件容易的事情,它取决于所使用的架构模型、架构师的经验和系统的复杂度。

    在创建架构图时可参考的指南

    除了上面列出的问题清单,还可以参考如下的一些指南来创建更好的架构图。

    选择最优的架构图数量

    Philippe Kruchten说过,“架构是一项复杂的工作,只使用单个图表来表示架构很容易造成莫名其妙的语义混乱”。要对系统进行良好的文档化,我们不能只使用一种图表。不过在创建架构图的时候,我们也难以确定该使用哪些类型的架构图以及应该创建多少个。在做出决定之前,我们需要考虑多方面的因素。例如,架构的属性和复杂度、架构师的技能和经验、可用的时间、维护成本,以及利益相关者的关注点。网络工程师可能想看到包含了主机、通信端口和协议的网络模型,数据库管理员更关心如何系统是如何操作、管理和分布数据的。所以,我们要选择最优的架构图数量,不管这个数字是多少。

    糟糕的架构图(比如缺乏文档)可能会缺失一些信息,反过来说,如果架构图太多(比如过度文档化),那么用于保持架构图一致性和更新架构图的工作量也会相应增加。

    保持架构图的结构一致性和语义一致性

    架构图之间应该在方框、形状、边框、线条、颜色等方面保持一致。架构图的结构外观应该是一样的,团队不同成员创建的架构图不应该给任何一个利益相关者造成理解上的障碍。理想情况下,可以在所有项目里使用相同的建模工具。

    从语义角度来看,所有的架构图与最新的代码变更之间以及架构图与架构图之间都应该定期保持同步,因为一个架构图的变更可能会影响到其他架构图。同步可以通过手动进行,也可以通过建模工具自动触发。通过建模工具自动触发会更好一些,不过这也取决于具体的项目。最终的目的是要保持架构图和代码之间的一致性,至于使用什么样的方法或工具可以自行决定。Simon Brown说,“如果架构图与代码失去了联系,那么就无法用来改进架构”。他的话其实是在强调保持语义一致性的重要性。

    避免架构图碎片化

    架构图越多就越难以理解,而且维护起来也很费劲。最直接的后果就是有可能出现碎片化(比如,通过两到三个架构图来描述同样的质量属性——性能、伸缩性,等等——但每一个架构图都无法完整地描述它们)。在这种情况下,建议移除不能反映相关质量属性的架构图,或者把它们合并起来。

    保持架构图的可追踪性

    保留架构图的变更记录、比较不同版本架构图之间的不同点,以及可以很容易地进行回退,这些都是很重要的。如果建模工具不支持这几点,那么对我们来说可能会是个问题。最近业界倾向于使用简单而直接的文本语言来生成架构图,这样似乎可以解决可追踪性问题。这样做的另一个好处是可以保持架构图之间的结构一致性。

    在架构图旁边加上图例

    如果你没有使用标准的架构描述语言(比如UML、ArchiMate),那么就要在图例里注明每个架构图元素的用意(比如方框、形状、边框、线条、颜色、缩略语,等等)。

    如果使用了标准的架构描述语言,只要在图例里添加关键性的架构描述,不需要太多额外的信息,因为看图的人都知道如何按照标准的描述语言规

    范来理解你的架构图。

    使用架构描述语言(比如UML、ArchiMate等)会有不一样的效果吗?

    关于如何在项目里使用正确的架构描述语言有很多不同的看法。有些人认为UML太过死板,用来做架构设计缺乏灵活性,在某种程度上我认同这个看法。有时候,在不依赖UML的profile和stereotype特性的情况下也能很好地完成架构图设计。至于说到其他的架构描述语言,我认为ArchiMate更加强大,相比UML,它更适合用来为企业系统建模。还有BPMN,它更专注业务流程的建模。对这些工具进行深入比较已经超出这篇文章的范围,所以不再累述。

    在选择架构描述语言时,综合性和灵活性是首要考虑的因素。但据我所知,完全不使用架构文档的情况也很常见。有些人觉得创建架构文档是一件很无聊的事情,而且觉得它们没有什么意义。这样的项目应该不在少数。人们因为没有使用合适的架构描述语言,所以创建不出很好的架构图,相反,如果他们使用了更好的工具,结果可能会大不一样。但事实并非如此,实际上他们跟本不想去创建什么架构文档(包括架构图),更糟糕的是,他们可能不知道该如何创建架构图。这是我们首要解决的问题——了解文档的重要性以及如何创建它们给软件工程师做培训),然后选择合适的工具。

    在系统和架构发生变化时如何更新架构图?

    更新架构图有几种方式,我将会介绍其中的三种。第一种,也是最简单的一种,就是直接从代码生成架构图。这样可以保证架构图与代码是一致的。不过目前的工具还不能完全支持这种方式,在没有人工介入的情况下,工具还无法基于代码生成精确且有意义的架构图。Len Bass说,“在最理想的开发环境里,只需要一个按钮就能得到我们想要的文档”。他指的就是自动生成架构图,但我们还远远没有达到那种程度。

    第二种,先用建模工具创建架构图,然后生成代码骨架(比如组件或包、API),随后开发人员可以在骨架上添加代码。每次架构图发生变更,需要从架构图端重新生成代码骨架。

    第三种,在每次加入新特性时手动更新架构图。为了保证代码与架构图的一致性,建议把更新架构图作为开发流程的一部分。不过我们不推荐这种方式,因为这样很容易造成架构图过时或出现不一致(比如开发人员总是忘记或者不想更新架构图)。

    我的建议是混合使用现有的工具,结合手动和自动的方式来创建架构图。例如,尝试自动生成架构图,使用工具基于代码渲染出符合基本要求的架构图,不包含混乱无用的信息。架构图可以高度可变(比如可以适应频繁的开发变更,这类架构图一般具有较低层次的抽象),也可以是静态的。这类图表可以是上下文架构图、参考架构图、包图、类图、实体图,等等。不过有时候仅仅基于代码无法生成满足需求的架构图,所以在这种情况下,自动创建架构图不是理想的方式。这个时候需要手动建模作为补充,这类架构图包括时序图、状态图、并发图、部署图、运营图,等等。

    现代架构(如微服务)对架构图有什么影响?

    微服务或其他任何一个现代架构风格(如无服务器、事件驱动)只会影响到系统的结构、组件间的交互方式(比如组件间的关系)和原则。在我看来,我不认为架构风格会改变架构图原先的含义。不过,相比传统的系统(比如单体),我们所说的现代系统架构具有更高层次的复杂性,它们对架构描述和架构图确实会有一些影响,这些是我们需要注意的。我们需要考虑分布式组件(比如分布式微服务)、每种组件的类型、组件间的交互方式(比如边界、API、消息)、他们的生命周期以及从属关系。

    综上所述,我们需要在架构图中体现系统的分解、开发、部署和运维。假设有一个包含了大量微服务的系统,它就会有很多的架构图,因为每个微服务都可能有自己的架构图。一致性(例如,改变一个服务的API会影响到其他服务,所有相关的架构图都需要做出修改)、碎片化(例如,一个架构图无法反映分布式服务的高可用性和性能)和横断面(例如,是谁在负责处理系统的监控或安全问题)问题会让人手忙脚乱。我们首要面对的挑战是如何进行良好的团队协作,不仅仅是开发,也包括后续的维护。

    总而言之,现代系统的复杂性会带来额外的问题,它们会在架构图层面造成一定程度的影响。

    更多推荐

    为什么说数据仓库、数据库是每个IT架构师都要精通的技能?

    亿级流量架构之服务限流思路与方法

    图解:消息传输的架构模式

    阿里技术专家告诉你,如何画出优秀的架构图?

    构建⼤型演进式系统架构

           

    免责声明:

    本公众号部分分享的资料来自网络收集和整理,所有文字和图片版权归属于原作者所有,且仅代表作者个人观点,与本公众号无关,文章仅供读者学习交流使用,并请自行核实相关内容,如文章内容涉及侵权,请联系后台管理员删除。

    戳“阅读原文”海量文档免费阅读下载

    展开全文
  • 架构功能

    千次阅读 2020-09-17 22:10:02
    支付系统功能架构图 支付业务的基础系统的复杂性和稳定性是支付业务是否能够及时安全处理的根本,该支付系统功能架构图收集了支付宝的系统架构。完整的支付系统整体架构! 从产品分类、模块功能和业务流程,了解支付...

    支付系统功能架构图

    支付业务的基础系统的复杂性和稳定性是支付业务是否能够及时安全处理的根本,该支付系统功能架构图收集了支付宝的系统架构。完整的支付系统整体架构! 从产品分类、模块功能和业务流程,了解支付产品服务的设计。支付系统要兼并合规性、易用性、安全性为一体,在前期设计时一定要综合考虑。支付系统架构图为通用支付... 

     

     

    平台数据架构流程图

    标准大数据平台架构,标准大数据平台架构,大数据平台架构,数据仓库,数据集市,大数据平台层级结构,数据挖掘,举报,包含该模版的分享。数据架构设计(数据架构组) 概述 总体描述 相对于业务架构和应用架构,数据架构在总体架构中处于基础和核心地位。首先应根据业务架构分析来定义数据架构,然后将数据架构结... 

     

     

    系统流程图

    系统流程图(又称业务流程图)进行可行性分析时,通常用系统流程图来描述所要开发的系统。用于 描述项目的处理流程、范围、功能等。系统流程图是概括的描绘系统物理模型的传统工具。它的基本思想是用图形符号以黑盒子形式描绘系统里面的每个具体部件(程序、文件、数据库、表格、人工过程等),表达数据在系统各个部... 

     

     

    Spring Cloud 微服务总体架构图

    Spring cloud作为当下主流的微服务框架,让我们实现微服务架构简单快捷,Spring cloud中各个组件在微服务架构中扮演的角色如图所示。spring-cloud-aws:用于简化整合 Amazon Web Service 的组件spring-cloud-bus:事件、消息总线,用于... 

     

     

    财务管理系统业务流程图

    这是一个财务管理系统业务流程图,模板主要包含了2大部分:角色和业务执行流程.其中角色就包含了系统管理员,出纳/会计,财务主管,CEO.整个财务管理操作流程清晰明确。ERP中销售流程及财务管理流程,ERP管理系统是非常复杂的的系统,涉及到多个模块。仓库管理业务流程图, ERP业务流程图的画法, ... 

     

     

    系统业务流程图

    商业流程图,又叫做业务流程图,是一种描述系统内部各人员与各单位的业务关系、管理信息以及作业顺序。系统流程图是概括的描绘系统物理模型的传统工具。它的基本思想是用图形符号形式描绘系统里面的每个具体部件,表达数据在系统各个部件之间流动的情况。系统分析员在工作中往往需要绘制各种各样的流程图

     

     

     

    组织架构流程图

    组织架构是企业的流程运转、部门设置及职能规划等最基本的结构依据,常见的组织架构形式包括中央集权制、分权制、直线式以及矩阵式等。组织架构关系图有总经理、副总经理、研发部、采购部、财务部、销售部、生产部。完善组织体系架构,员工体系,薪酬体系,绩效体系,岗位体系,建设队伍,创造激励机制!

     

     

     

    电商物流仓储流程图

    在电商仓储内部中,其作业流程主要包括订单处理、采购作业、入库上架、在库管理、拣选包装、出库作业、配送作业、退货作业以及财务会计作业等。电子商务的快速发展,其配套设施服务也需跟上,而其中最重要的非仓储、配送等物流服务莫属。电子商务间的竞争,最终转变为后端物流之争。

     

     

     

    精益质量管理流程图

    精益质量管理流程图,该流程图以精益质量管理为中心,从五个小点逐步扩散,改善了工作的效率。精益管理有七大任务,分别是:安全、质量、生产、设备、成本、人事和环境!质量管理部进料、生产过程、出货、新产品研发、不合格品控制等工作流程图。建立和实施质量管理体系工作流程: 第一阶段:策划与准备 一、体系策...

     

    展开全文
  • 现在,数据的新名词层出不穷,顶层的有数字城市、智慧地球、智慧城市、城市大脑…企业层面的有数字化转型、互联网经济,数字经济、数字平台… 平台层面的有物联网,...(13张架构图在文末,自取) 中台也好,数据中台也

    现在,数据的新名词层出不穷,顶层的有数字城市、智慧地球、智慧城市、城市大脑…企业层面的有数字化转型、互联网经济,数字经济、数字平台… 平台层面的有物联网,云计算,大数据,5G,人工智能,机器智能,深度学习,知识图谱…技术层面的有数据仓库、数据集市、大数据平台、数据湖、数据中台、业务中台、技术中台等等,总之是你方唱罢他登场,各种概念满天飞…

    今天结合“数据中台”,以作者从事数仓行业多年的实战经验来看,数仓—大数据平台—数据中台的区别和本质联系,希望能拨云见雾!(13张架构图在文末,自取)

    中台也好,数据中台也好,一直缺乏一个标准的定义,仅从字面上理解,数据中台是解决如何用好数据的问题,既然是概念,数据中台也被赋予了很多扩大的外延,也上升到了数据的采集、计算、存储、加工和数据治理等方面,这就和传统的大数据平台在功能和作用上产生了很大的重叠;而大数据平台又是从数据仓库发展起来的。那到底这三者的关系是怎么样的呢?

    按照传统的定义,数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合,用于支持管理决策。从数据角度,数据仓库更适合传统的数据库,离线采集,数据一般为结构化的,每天处理数据量不易超过TB集,数据仓库一般在数十T到几百T以内,数据仓库一般为满足内生的应用,满足内部决策支持分析需求,当然随着数据仓库数据采集的要求越来越高,数据仓库本身也在不断的改进,从单机的ETL到集群的ETL,从传统的小机+DB,向PC服务器+分布式DB拓展,数据治理也逐渐增强,从元数据管理到数据质量管理,再到数据运维管控和数据安全管控,但其实数据仓库给企业留下的最大财富是企业数据模型,这些模型随着前端业务系统的发展变化,不断变革,不断追加,不断丰富和完善,即使系统不再了,也可以在短期内快速重建起来,这也是大数据平台能够快速建设起来的一个重要原因。

    大数据平台则是指以处理海量数据存储、计算及流数据实时计算等场景为主的一套基础设施,包括了统一的数据采集中心、数据计算和存储中心、数据治理中心、运维管控中心、开放共享中心和应用中心。大数据平台之所以能够建设起来,不外乎内因和外因,外因是棱镜门事件带来的去IOE要求、外部硬件的变革和分布式开源技术的涌现;内因是非结构化、实时数据和海量数据的计算和存储压力,企业也寄希望从大数据平台除了满足对内需求,也能够实现一定的对外收益。

    大数据平台的建设出发点是节约投资降低成本,但实际上无论从硬件投资还是从软件开发上都远远超过数据仓库的建设,大量的硬件和各种开源技术的组合,增加了研发的难度、调测部署的周期、运维的复杂度,人力上的投入已是最初的几倍;还有很多技术上的困难也非一朝一夕能够突破,但无论如何大数据平台还是建设起来了,人员能力也在不断成长。大数据平台解决了海量数据、实时数据的计算和存储,也基于原来的企业数据模型实现了重构,但也面临着一系列的问题。

    首先是数据的应用问题,无论是数据仓库还是大数据平台,里面包含了接口层数据、存储层数据、轻度汇总层、重度汇总层、模型层数据、报表层数据等等,各种各样的表有成千上万,这些表有的是中间处理过程,有些是一次性的报表,不同表之间的数据一致性和口径也会不同,而且不同的表不同的字段对数据安全要求级别也不同,此外还要考虑多租户的资源安全管理,如何让内部开发者快速获取所需的数据资产目录,如何阅读相关数据的来龙去脉,如何快速的实现开发,这些在大数据平台建设初期没有考虑周全;另外一个问题是对外应用,随着大数据平台的应用建设,每一个对外应用都采用单一的数据库加单一应用建设模式,独立考虑网络安全、数据安全、共享安全,逐渐又走向了烟囱似的开发道路。

    数据仓库实现了企业数据模型的构建,大数据平台解决了海量、实时数据的计算和存储问题,数据中台要解决什么呢?数据是如何安全的、快速的、最小权限的、且能够溯源地被探测和快速应用的问题。

    数据中台不应该被过度的承载平台的计算、存储、加工任务,而是应该放在解决企业逻辑模型的搭建和存储、数据标准的建立、数据目录的梳理、数据安全的界定、数据资产的开放,知识图谱的构建,通过一系列工具、组织、流程、规范,实现数据前台和后台的连接,突破数据局限,为企业提供更灵活、高效、低成本的数据分析挖掘服务,避免企业为满足具体某部门某种数据分析需求而投放大量高成本、重复性的数据开发成本。

    厚平台,大中台,小前台,没有基础厚实笨重的大数据平台,是不可能构建数据能力强大、功能强大的数据中台的。没有大数据中台,要迅速搭建小快灵的小前台也只是理想化的。

    我想这才是数据中台的初衷。

    后文是对数据仓库、大数据平台、数据中台的一些总结性的架构材料,也是对自己这些年来的一些汇总和思考吧,看懂了前面的文字,后面的各种架构图也就无需赘述了。

    1、数据仓库硬件架构

    从数据仓库到大数据平台再到数据中台(内附13张架构图)

    2、数据仓库功能架构

    从数据仓库到大数据平台再到数据中台(内附13张架构图)

    3、数据仓库技术架构

    从数据仓库到大数据平台再到数据中台(内附13张架构图)

    4、第一个Hadoop平台硬件架构

    主要是为了解决海量离线数据的计算和存储,在Hadoop集群中实现明细数据、汇总数据存储,在mysql中实现报表数据存储。

    从数据仓库到大数据平台再到数据中台(内附13张架构图)

    5、第一个流式处理平台硬件架构

    主要是为了解决海量实时数据的流式采集和计算,在Hadoop集群中实现明细数据、汇总数据存储,在mysql中实现报表数据存储;并通过实时事件处理集群实现流式事件的匹配。

    从数据仓库到大数据平台再到数据中台(内附13张架构图)

    6、大数据平台系统规划

    对于大数据平台各种软硬件各种组件的规划

    从数据仓库到大数据平台再到数据中台(内附13张架构图)

    7、大数据平台系统定位

    从数据仓库到大数据平台再到数据中台(内附13张架构图)

    8、大数据平台逻辑部署架构

    从数据仓库到大数据平台再到数据中台(内附13张架构图)

    9、大数据平台功能视图

    从数据仓库到大数据平台再到数据中台(内附13张架构图)

    10、大数据平台数据流向

    从数据仓库到大数据平台再到数据中台(内附13张架构图)

    11、大数据平台对内硬件架构

    从数据仓库到大数据平台再到数据中台(内附13张架构图)

    12、大数据平台整体硬件架构

    从数据仓库到大数据平台再到数据中台(内附13张架构图)

    13、数据中台整体架构

    从数据仓库到大数据平台再到数据中台(内附13张架构图)

    源: python与大数据分析

    专注企业数据分析应用和数字化转型。关注公众号“商业智能研究”,回复“资料”,整理了6G的数仓、数据中台、数据治理、企业数据化管理案例,供免费领!

    展开全文
  • 各种系统架构图与详细说明

    万次阅读 多人点赞 2018-09-15 17:49:59
    如上图所示为本次共享资源平台逻辑架构图,上图整体展现说明包括以下几个方面: 1 应用系统建设 本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发,从而建立行业的全面的应用系统架构群。...
  • 数据仓库架构(内含PPT)

    千次阅读 多人点赞 2020-11-18 07:00:00
    大数据篇:一文读懂@数据仓库1 网络词汇总结1.1 数据中台数据中台是聚合和治理跨域数据,将数据抽象封装成服务,提供给前台以业务价值的逻辑概念。数据中台是一套可持续“让企业的数据用起来”...
  • 由此,大数据平台、数据中台等新鲜的概念就真的落地了,其实数据类的概念都是相同的:报表、BI、数据仓库...少了一个都玩不转,只有每一个都做到极致,企业的数据价值才能得到提高。 先来说说背景吧,搭建大数据...
  • 1.设计软件架构图并非一件轻而易举的事情,即使是很简单的一个架构图也可能会出错。有意义且具备一致性的架构图有助于为不同的利益相关者澄清事实,并达成共识。 2.在大多数情况下,问题的根源并不在于是否使用了...
  • 实际场景架构图实例及详细说明

    千次阅读 2019-08-31 13:08:51
    系统设计中,离不开各种各样的架构图。下面列举各场景下,不同架构图描述的具体解决方案,抛砖引玉,加深对架构图的思考,为实战中怎么运用起一些参考。 一、共享平台逻辑架构设计 如上图所示为本次共享资源平台...
  • 架构流程

    2020-08-24 20:42:21
    前台登录注册流程 1.页面字段,手机号,输入框;...标准大数据平台架构,标准大数据平台架构,大数据平台架构,数据仓库,数据集市,大数据平台层级结构,数据挖掘,举报,包含该模版的分享。数据架构设计(数据架构组) .
  • 来源 |谈数据开局一张图:这是某公司使用的大数据平台架构图,大部分公司应该都差不多。从这张大数据的整体架构图上看来,大数据的核心层应该是:数据采集层、数据存储与分析层、数据共享层、数据应...
  • 在数据库开发和优化、数据仓库、系统架构、大中型项目管理、数据治理、数据分析、大数据方 面有一定研究。 参与移动集团经营分析系统5.0、企业级大数据平台1.0相关规范的编写和审计,中移动集团大数据专家。 全文...
  • 以上就是我们整个微服务架构图的解释 3:电商项目微服务划分图详解 项目微服务划分图就反应了我们项目中一些相关的微服务和技术组合, 这个项目是基于前后端分离的开发,前端项目分为admin-vue(面向工作人员使用的...
  • 大数据篇:一文读懂@数据仓库1 网络词汇总结人工智能层的:智慧地球、智慧城市、智慧社会企业层面的:数字互联网,数字经济、数字平台、数字城市、数字政府;平台层面的:物联网,云计算,大数据,...
  • 9月28日,在上海举办的“云智技术论坛”智能大数据专场,百度智能云带来了云智一体的大数据产品架构全景,为企业提供从构建新型数据基础设施、深度挖掘数据价值,到保障数据安全的全流程大数据解决方案。...
  • 数据中台,能够提供面向企业业务场景的一站式大数据分析平台,采用大数据、移动互联网、人工智能等先进技术,支撑企业业务...整体架构:应用架构:大规模数据管理的能力:分析云拥有PB级大规模数据管理能力,支持穿...
  • 数据仓库(三)之架构

    万次阅读 多人点赞 2018-09-13 21:54:18
    架构是数据仓库建设的总体规划,从整体视角描述了解决方案的高层模型,描述了各个子系统的功能以及关系,描述了数据从源系统到决策系统的数据流程。业务需求回答了要做什么,架构就是回答怎么做的问题。 架构的...
  • 期中架构篇 一、名词介绍 1.项目:针对游戏公司,每一个游戏就是一个项目;针对互联网行业,一个公司就是一个项目 2.架构:维护一个项目的所有组件组成的一个...三、架构图 1.酒店架构图 2.运维架构图 3.架构中的服
  • Hadoop + Hive 数据仓库原理与架构

    千次阅读 2021-11-19 12:09:55
    通过类 SQL 指令轻松访问数据的工具,从而实现数据仓库任务,例如:提取/转换/加载(ETL),报告和数据分析。 一种将结构强加于各种数据格式的机制。 直接访问存储在 HDFS 或其他数据存储系统(例如:HBase...
  • 数据架构设计 数据架构组 介绍 (Introduction) Within a company using data to derive business value, although you may not be appreciated with your data science skills all the time, you always are when ...
  • 数据仓库之整体架构

    2021-07-27 00:32:10
    概述架构是数据仓库建设的总体规划,从整体视角描述了解决方案的高层模型,描述了各个子系统的功能以及关系,描述了数据从源系统到决策系统的数据流程。业务需求回答了要做什么,架构就是回答怎么做的...
  • 数据仓库架构与设计

    万次阅读 多人点赞 2017-04-01 17:52:19
    公司之前的数据都是直接传到Hdfs上进行操作,没有一个...1. 什么是数据仓库1.1 数据仓库的概念官方定义数据仓库是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合,用于对管理决策过程的支持。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 51,842
精华内容 20,736
热门标签
关键字:

仓库人员架构图

友情链接: Cashier.zip