0


架构师杂谈

序言

    一路跌跌撞撞、摸爬滚打做软件架构已有七八载,从鸿蒙初开到明心见性,从罗汉渡己到菩萨渡人,一介凡尘终是轮转不息。当我们拿着Martin Fowler "*Patterns Of Enterprise Application Architecture" *时,*"Microservice Architecture Style" *成为云时代天选之子,当我们秉烛夜读 "Pattern-Oriented Software Architecture" 时,"Just Enough Software Architecture"成为架构师的中庸之道,终是不得道生一。但仍执着于一见无始道成空的架构设计,胜天半子的架构规划,独断万古的架构决策,至死不渝追求究竟。

    有些架构方面书籍喜欢脱离业务讲设计或者脱离抽象讲业务,会让读者觉的抽象难懂或者太浅,本文会给读者架构领域一个**全貌概念概览**和相互之间的关系作用,不会讲怎么去做软件架构设计,更多的是讲架构概念和架构思想,架构方法需要读者自己在工作中实践。希望本文对想转架构师的程序员或者初入架构师有一定的借鉴作用。江湖中不曾见过,但江湖中留过笔迹,仗剑山河人间!

架构思维

    人类四大思维:演译、归纳、溯因、类比

    架构思维:分治、分层、抽象、演进,溯因更多是在架构设计过程中用到。

    分治:复杂问题简单化思维,按类别拆分。需要注意拆分的标准,寻找到最适合组织、业务发展的**边界**进行拆分(可以按业务域边界进行拆分,可以按组织职能拆分。如果涉及组织需要考虑**康威定律**,组织对架构的影响,俗称干系人影响)。

    分层:与分治思维类似,分层是横向,分治是纵向。分层思维能很好的处理业务融合,破壁垒,形成新的价值链,每一层都界定了职责和角色。

    抽象:提炼组合的思维,OOP思想里面的继承或者接口就是一种抽象思维。

    演进:一个好的架构肯定是螺旋式上升发展的一个过程,一个熵减的过程。(一个企业的EA熵减做的很好,那么可以推断这个企业在快速有序发展,值得呆下去)

    分治、分层、抽象、演进是基本的架构思维,在工作当中经常用到,相互配合使用,才能设计出一个好的架构。参考架构用的是类比思维,架构治理用的是溯因思维,识别组件、组件之间关系及组件与环境之间的关系用的是抽象、分治、分层思维(归纳思维)

架构框架

    架构框架是一个**基础结构或结构集合**,可被用于开发更大范围的不同架构。架构框架应描述一种方法,用于基于一系列构建块来设计Enterprise的**目标状态**,并表明构建块如何适配地结合在一起。它应包含一系列工具,并提供一个常用词汇表,也应包括能够用于实现构建块的推荐标准和合规产品的列表。

TOGAF的框架能力:

                       (图片来源:01_structure.png (946×768) (opengroup.org)) 

TOGAF框架提供了架构开发方法、架构内容框架、架构能力框架等连续统一工具集,输入业务愿景和因素驱动后,使用TOGAF框架方法和工具集设计,可以达到预期业务能力。

架构模式

   《Pattern-Oriented Software Architecture》明确定义了架构模式:描绘基本的软件系统组织纲要,提供了一组**预定义的子系统**,指出了这些子系统职责,包含用于对子系统间关系进行组织的规则和指南。模式包含三部分:背景(Context)、问题(Problem)、解决方案(Solution),基于这个定义我们也可以把某个领域经验抽象、结构化后定义为架构模式,形成特定领域解决方案,再推广、复用、形成标杆。

    维基百科的定义:An architectural pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context.

架构模式是一个通用的、可重用的解决方案,用以解决特定上下文内的某个常见的架构问题

简单些说模式是对特定领域问题解决方案经验沉淀,直接套用就行了,从而提炼出一套行之有效的结构化的模板。比如:MVC模式、CQRS模式、Cache-Aside模式、Compensating Transaction 模式(常说的TCC编程)等,另外近些年流行的微服务相关的一些模式如:防损模式(Anti-corruption layer)、大使模式(Ambassador)等,这些模式都是工作中特定问题很好的解决方案。架构模式在工作种用的是最多的,架构师要多熟悉些架构模式。

架构风格

    架构风格目前没有统一定义,百度百科的定义是架构风格即架构模式。

An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style.(内容引自Chapter 1 Software Architecture 1.5 Styles:Untitled Document (uci.edu))

一种架构风格是一组协作的架构约束,这些约束限制了架构元素的角色和功能,以及在任何一个遵循该风格的架构中允许存在的元素之间的关系

Azure的定义:架构风格是一系列约束,六大架构风格分别为大计算、大数据、事件驱动架构、微服务(Martin Flower支持微服务是一种架构风格)、多层架构、Web-队列-辅助角色。

比如:选择了流式计算Spark框架,那就得接受Spark的微批处理约束,时效性达不到Flink真实实时流框架效果,但Flink的背压效果肯定是没有Spark的背压效果精准。

比如:CAP理论,选择CP或者AP,是两种不同的架构风格,选择了AP架构风格,就得接受数据不一致的问题。

架构风格和架构模式的关系:架构风格只强调约束,选择某个框架即会受到这个框架的约束,那本身就是一种架构风格。架构模式强调问题、上下文、解决方案(方案本身就带有约束),当一个架构风格应用到某个【问题域】和【上下文】,那么这个架构风格在这个【问题域】和【上下文】的应用就是架构模式。

梳理下架构框架、架构风格、架构模式的关系:

企业架构(Enterprise Architecture)

** 架构:**ISO/IEC 42010:2007明确定义,"The fundamental organization of a system, embodied in its components, their relation-ships to each other and the environment, and the principles governing its design and evolution."

"一个系统的基础结构(organization 翻译为结构更易懂),体现在系统组件、组件之间及组件与环境之间相互关系,以及对系统设计演进进行治理的原则中"

这个定义是很全面的:引入了环境、设计、演进、治理的概念,很多对架构的定义停留在识别组件、组件之间关系上面。

Enterprise Architecture本质就是战略、业务与技术的综合。(解决领导一句话需求即:目标和愿景)定好方向(战略),用一套业务流程实现战略,IT支撑业务发展。TOGAF提出了ADM架构开发方法,整个流程由架构愿景、业务架构、信息系统架构、技术架构、机会和解决方案、迁移规则、实施治理、架构变更管理组成,形成解决方案连续统一体工具集。每个阶段都均指向需求管理,一切以需求需要做为出发点,并反向驱动需求。架构工作需指向企业愿景、目标及战略从而更好的解决业务需求,任何活动都围绕业务展开。比如:引入Redis带来了什么业务价值,通常需要从技术价值去反向推导出业务价值。

                            ​​​​​​​        

TOGAF ADM由架构愿景、业务架构、信息系统架构、技术架构、机会和解决方案、迁移规则、实施治理、架构变更管理组成,形成一套统一连续的Enterprise Architecture 工具集。有些书箱会把业务架构合并到信息系统架构中,业务架构上承企业战略,下启信息系统架构,同时需要确保业务架构和IT落地保持一致,业务架构独立更能起到应有的作用。 这张图的核心是企业一切活动、设计均指向需求管理,一切都需要服务好业务,业务第一原则。

TOGAF内容元模型各SOA实体关系:

                    (图片来源:34_contentfwk8.png (940×768) (opengroup.org)) 

信息系统架构提供业务服务来支撑业务架构,业务架构支撑企业战略,企业战略实现企业目标和愿景。我们在做技术架构设计、应用架构设计、业务架构设计时均要反思我们的设计是完全指向了企业战略,如果方向错了需要及时调整。(这里不考虑战略是错的情况)

                              (图片来源:企业级业务架构设计:方法论与实践)

                             (图片来源:企业级业务架构设计:方法论与实践)

上述两张图更清晰的表达出企业愿景、目标、战略、业务架构、信息系统架构的关系。近年比较流行破壁垒的说法,架构层面说法是破烟囱。这个问题是一个管理问题,组织+业务经营单元层面需要切分出一个合理的边界,业务架构层面梳理出横向的业务价值链进行融合,信息系统架构层面做好应用、数据的融合(数据中台、大中台),Devops层面采用用户价值流为导向破除项目的阻塞点。企业架构的内容很多,架构原则、架构治理、架构能力框架等,这些内容比较好理解,关联性并不强,重点是业务架构、信息系统架构(云时代简化了信息系统架构所包含运维层面工作部署)、技术架构,可以选择参考架构做类比,不论怎么做都要指向业务价值。组件识别、组件之间七种低藕合和七种高内聚关系选择、架构的质量需求等是一个长期积累的过程。

最后祝大家虎年快乐、大吉大利、阖家幸福、财源滚滚、步步高升。

注:

1、架构师不能接触到Enterprise Architecture,可以围绕某个业务域去作展开分析,切换Architecture Context。

2、引入Redis是技术对业务的支撑,引起业务活动、业务流程及业务价值链变化而调整业务架构甚至战略,可称为技术驱动业务。

3、TOGAF中明确说明Enterprise并不是指企业,而是泛指复杂的组织,比如企业、政府,但文中Enterprise皆指企业

4、更多的模式可以参考代表模式 - Cloud Design Patterns | Microsoft Docs

5、组织原型:职能型、矩阵型、市场型,需要结合企业市场特点、数字化程度来决定采用某种组织原型

参考文章与书籍

《TOGAF 标准9.1版本》

《恰如其分的软件架构》

《四种核心架构思维》(123条消息) 四种核心架构思维_架构师波波的专栏-CSDN博客_架构思维

《真正的高手,都是对抗"熵增"的底层思维》真正的高手,都有对抗“熵增”的底层思维 (qq.com)

《产品经理底层内核之--熵减思维》产品经理底层内核之——熵减思维 (baidu.com)

《康威定律》(124条消息) 康威定律_javaDB_EAD的专栏-CSDN博客_康威定律

《Cloud Design Patterns》Cloud Design Patterns: Prescriptive Architecture Guidance for Cloud Applications | Microsoft Docs

《DevOps实践指南》

《企业级业务架构设计方法论与实践》

《完美世界》

《遮天》

标签: 企业架构

本文转载自: https://blog.csdn.net/asd491310/article/details/122731279
版权归原作者 IWBS 所有, 如有侵权,请联系我们删除。

“架构师杂谈”的评论:

还没有评论