架构师杂谈

序言

一路跌跌撞撞、摸爬滚打做软件架构已有七八载，从鸿蒙初开到明心见性，从罗汉渡己到菩萨渡人，一介凡尘终是轮转不息。当我们拿着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、组织原型：职能型、矩阵型、市场型，需要结合企业市场特点、数字化程度来决定采用某种组织原型

）