关于架构的理解

2.1 什么是架构：

架构，简单说是对系统的描述。

维基百科的定义是：软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

系统的三大特征表现在架构上就是：横向可并列，纵向可推导，整体可演进。

物理学的熵增定律表明孤立系统总是趋向于熵增的方向发展。在软件系统里同样适用，只不过是以复杂度的增加表现的。

互联网软件系统总是朝着复杂度增加的方向发展。所以架构的第一目的是控制复杂，是系统朝着可控的方向发展。

2.2 什么是好的架构图

简洁抽象：好的架构图一定是简洁的，表现上简洁有力，能够一眼看上去就经纬分明。有一定的抽象度的，如果一个架构图存在各种飞线环线，那一定是抽象的不够。抽象才有意义，架构里如果存在各种细节，那就是堆砌。

可解释：好的架构图一定能够用来解释当前系统的现状和行为。

指导行动：好的架构图一定是可以指导行为的，指导行动才是架构图的最大价值。能够预测未来，指导行动。对于某个领域架构图，根据架构图都不知道把某个模块放哪里，那就是失败的。好的架构图应该是对于一个没有经验的人，都能根据架构来做模块划分。

可进化：对应于系统的动态性，架构也会随着时间而进化的。不能进化的架构就像花瓶，看着很美，一碰就碎。

2.3  架构图的表达

"把桌子放在房间里看，把房间放在院子里看，把院子放在城市规划里看。"

对架构的呈现业界已经存在不同的框架。有4+1视图、C4模型、TOGAF提出的企业架构模型等。不管哪种模型，其核心思想都是从不同的维度对软件架构进行描述。下面着重从这几个方面来简述。

2.3.1 4+1模式

4+1视图由 Philippe Kruchten 提出的对软件工程逻辑架构的描述，目前已经成为事实上软件结构标准，分别终端使用者、开发者、系统工程师、软件经理等不同的视角对软件进行描述。如下图所示：

逻辑视图（Logic View）：终端使用者的视角，从功能角度来描述不同功能组件的层次关系。

开发视图（Development View）：开发者视角下，从实现层面描述不同代码的包、类、库的构成关系。

过程视图（Process View）：不同组件之间的行为关系，通常以时序图的形式来表示，有一定的时序延展性。

物理视图（Physical View）：系统所依托的物理视图，例如部署视图。

场景视图（Scenarios）：系统所涉及的不同对象之间的关系。通常以用例图的形式来呈现。

基于这5个视角，可以衍生出5中架构模型。场景、功能、实现、过程、部署，一层层的抽象。

4+1架构视图，构建了一个观察了解系统框架。它告诉我们可以从逻辑视图、开发视图、过程视图、物理视图、场景视图这几个层面来对系统进行描述、观察、理解。对于一个系统，这5个视角已经是很完备了。值得注意的是4+1更大的价值是提供了一套分析系统的框架，实际上怎么呈现不同的团队可能有不同的形式。对于一个系统从不同的视角看会得到不同的理解，横看成岭侧成峰。

2.3.2 C4模型

C4模型C4模型是由Simon Brown在2006年至2011年之间创建，以4+1模型的基础上建立（ https://c4model.com/ ），实际上就是以下4个单词的缩写：

上下文Context：描述的系统与周边系统、人的关系。重点是该系统与外界的关系。这里的外界包含人、以及其他的系统。 

容器Containers：容器是一个功能的单位，是从技术层面来描述，可以是一个服务，也可以是一个技术组件或者一个功能模块。例如一个基金系统会包含交易服务、订单服务、商品服务等。

组件Components：组件是容器的的组成，组件是对容器的放大，例如商品服务里包含sku管理、行情数据、衍生指标等。

代码Code：这一层次是代码级别，包含接口、类、对象的继承、组合、包含等。

该模型是对一个系统从宏观到微观逐级展开来描述，犹如拿着放大镜从太空看地球一样。

第一层看到的是地球与其星球的环绕、第二层是看到地球上的山川海河，第三层看到的是不同的国家城市，第四层看到的是不同的房子家庭。

C4模型基于4+1模型，但是也有些差异。

如果说4+1重点是横看成岭侧成峰。那C4模型则是一窥到底的放大镜。

C4模型告诉我们，不同抽象层次的关注点、挑战点、问题域都是是不同的，站在不同的层次就要思考对应的事情。

关注点一旦与该层次不匹配就会出现逻辑错乱问题。 

能分清楚问题域在何种层次其实已经把问题解决一大半了。

有时候，在低层次很难解的问题，上升一个层次就迎刃而解了。 

有时候，在高层次看不清的问题， 降低一个层次就一目了然了。

高层次是低一层的抽象，低层次是高一层的具化。

高手应该是能够识别不同的抽象层次，并且可以游刃有余地在不同抽象层次之间穿梭。

处于高层次时不应该被低层次的具体牵绊，处于低层次的时候也不应该好高骛远。

2.3.3 TOGAF-4A架构

TOGAF 即 The Open Group Architecture Framework （开放组体系结构框架），是由致力于技术标准制定和推广的非盈利组织 The Open Group 制定的用于开发企业架构（Enterprise Architecture）的一套方法和工具。TOGAF提出了如下的架构模型：

业务架构：业务战略，治理，组织和关键业务流程。突出的重点是价值、信息、与协作。是从整个企业的视角来看，涉及跨部门、跨业务的整体视图。

应用架构：要部署的各个应用程序的蓝图，其交互以及与组织核心业务流程的关系。

数据架构：一个组织的逻辑和物理数据资产和数据管理资源的结构。

技术架构：支持部署业务，数据和应用程序服务所需的逻辑软件和硬件功能。这包括IT基础设施，中间件，网络，通信，处理和标准。

详见：https://togaf.gitbook.io/project/main/what_does_togaf_deal_with

togaf 认为架构的目的是为了帮助企业实现如下能力：

异构到同构（塑造同构IT）

事后到事先（塑造规划IT）

离散到统一（塑造统一IT）

无序到有序（塑造有序IT）

2.3.4 实际模型-互联网模型

实际上,相对于传统的软件系统，互联网行业发展比较快，互联网业务存活周期比较短，就形成了互联网行业特定的架构描述方式。

更多是以功能架构、技术架构、部署架构三种形式呈现。

 业务架构：从业务角度描述系统承载的功能集合、领域边界、各组成部分的逻辑关系。区别于技术架构，业务架构图里避免出现技术类的术语，如DB、mysql、cmq、同步、异步、并发等。 

技术架构：从技术角度描述系统各组成部件之间的交互关系，技术架构体现的要具有技术特色，例如同步、异步、消息等。

部署架构：从物理角度描述系统的部署分布。

2.4  架构的设计模式

软件架构归根结底无非两种模式：从技术层面和业务功能层面来设计。在理解这两个之前想区分一下技术语言和业务语言：

技术语言：是实现层面的。如DB、mysql、查询、超时、读写分离、快慢分离、逻辑层、缓存、创建订单、同步、异步、多线程、多进程

业务语言：是功能层面的。如买入、取出、基金信息、行情、基金详情、资产、产品列表、持仓列表、申购列表、赎回列表。

技术人员要做的是摆脱技术语言体系，走进业务体系，不能被技术语言限制住。从本质上来说技术是为了业务服务的，所以理解业务第一，技术第二。对业务有了深刻的理解，再转过来去用技术来实现业务。最好的是实践就是在业务代码中看不到技术词汇，只有业务。

技术层面的架构更多是从实现层面来划分。例如以往的MVC模式、ao、dao等模式。

微服务架构：

微服务的最早提出者的定义是这样说的：

简单地说，微服务架构风格就是一种将单个应用拆分成一组小服务开发的方法，每一个小服务运行在它自己的进程中并且使用轻量的协议通信，通常是一个HTTP资源API。这些服务围绕业务能力构建并且由自动化部署机器部署。这些服务有着最小化的中央管理，这个中央管理可以使用不同语言编写并使用不同的数据存储技术。

———— James Lewis and Martin Fowler

我的理解是，微服务不在于微，微服务是一种理念，其表达的是用一个服务来表达一个实体相关的所有行为，某个实体与外部的所有联系均通过该服务来发生。区别于以往按照技术功能划分的服务，ao做逻辑层，dao做存储层，vo做展示层。一个实体的行为要通过vo、ao、dao三个服务的关联才能表达出来。而微服务则只需要一个服务，对外的表示只有一个。类似于一个国家，虽然小，但是有自己的法律、武装、税收等。微服务拥有自己的逻辑、存储、领域等。微服务核心思想：服务即实体，我即是全部。服务是实体概念的载体。其出发点是从业务领域或者功能层面就进行彻底的解耦。微服务之间完全异构，微服务之间甚至都无技术层面的共通性。

例如代表保单的微服务，所有跟保单的相关行为都是该服务提供的，该服务内部实现保单的存储和查询，外界无需关心，创建保单、查询保单、理赔保单均是通过该保单微服务实现的。

但是在实操中，限于硬件水平和当前的技术能力，单个微服务又难以承接实体相关的所有行为。例如保单的查询对性能要求比较高，保单的写入对一致性要求比较高，这种情况下，如果放在一个服务里就会带来实现上的困难。这时可能又会回到了传统技术功能划分服务上来，考虑读写分离，分出一个查询和读的保单微服务。有时候也是无奈的妥协，但是一般的原则是先坚持原则再妥协。先按照微服务领域的不可分割性来设计，遇到技术性的挑战再做调整与妥协。

2.5 架构设计的一些原则

https://learn.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/architectural-principles

https://pubs.opengroup.org/architecture/togaf8-doc/arch/toc.html

SOLD原则

关于原则，看了很多次，是否真的理解了这些原则？

是否将这些原则应用到实际业务中。

2.5.1 关注点分离：

上帝的归上帝，凯撒的归凯撒。 教权若与皇权不分离，只会陷入无休止的混乱。

顾名思义：识别关注点，做分离。道理都懂。问题是如何识别关注点，又如何做分离。

关注点分离贯穿于软件系统的整个生命周期。类似于数据分析中的聚类分析，类间异构化，类内同质化。

既有又要还要，那你到底要啥？ 

关注点是什么？理论上在软件系统中提炼出来的任何概念都可以作为关注点，包括显示的和隐式的概念。

怎么分离？分离的方法无外乎水平分离和垂直分离。上帝与凯撒是水平分离，上帝与耶稣就是垂直分离了。STL中算法与数据分离式水平分离；常见的数据库读写模式是水平分离；

前端展示中的模版与引擎是水平分离。MVC设计模式中显示、控制、数据的分离是垂直分离。TCP七层协议模型是垂直分离。

2.5.2 封装

2.5.3 依赖倒置

2.5.3 显示依赖

2.6 架构的特征

架构的特征是指一个系统的非功能性的需求，虽然是非功能的但是又关系到系统的生死。

可部署性、弹性、演化性、容错、模块化、总体成本、性能

可靠性、可伸缩性、简单性、可测试性

实际上只有三个  高可用、高性能、一致性。由此而衍生出三种类型的架构

高可用架构、高性能架构、一致性架构