从方法到思惟：什么是应用逻辑架构的正确姿式？

Blog: https://blog.yilon.top

做者: 阿里技术

地址: https://zhuanlan.51cto.com/art/202004/613905.htm

本文分享阿里资深技术专家六铢的架构方法论，这套方法论中包含了详细的架构推导逻辑，但愿可以帮助你们在工做中从各个粒度、各个层次来作好架构工做。较长，同窗们可先收藏再看。

1、背景

1.1 架构中的问题识别

需求分析，架构实现，(新需求，架构改动)* n = 推倒重来。

这个过程是一个循环往复的过程，有的产品每一年都会推倒重来一次。

而这个过程是如何形成的呢?缘由之一是每次迭代过程当中都没有用正确的架构方法来进行迭代形成的，就像在歪楼上继续加盖楼层同样，最终仍是会倒塌(不过这个缘由并非惟一的缘由，其余缘由留到后续文章中阐述)。

这真是一个悲伤的故事，可是又是一个时常发生的故事。或者说咱们大多数人都经历过的场景。

要解决这个问题，那就须要在每次迭代中，都须要用正确的姿式对不对?要用对姿式其中有一个重要的缘由是架构。就像一幢大楼，架构设计得越有问题，这幢大楼被重造的可能性就越大。

这里正确的姿式究竟是什么姿式?接下来本文会阐述一整套架构方法论，该方法论中包含了详细的架构推导逻辑，帮助咱们在工做中在各个粒度，各个层次作好架构工做。

咱们后续的文章中将会着重阐述如何经过自底向上以及自顶向下的两种架构思考方式来解决这些问题，可是在那以前，咱们仍是先来聊聊什么叫“架构”。

1.2 什么是架构?

大概是在 11 年前左右，在土豆网作广告平台，同时也作视频 CDN 的相关事情，当时作一个服务，基础架构是 lighttpd + squid + tomcat，将静态资源分离到 httpd，get 请求使用 squid 缓存，智能路由使用 HTTP post 请求，并让 tomcat 提供服务，当时就以为这就是架构。再后来，作了视频 CDN 相关的基础建设的工做，就以为这就是作架构，关键那个时候也没有人告诉咱们什么架构，本身不知道本身不知道。

再后来慢慢成长，又去作了几年中间件(包括高性能 RPC 和 JSR-170)，而后就以为这也是作架构。当时也没有前辈跟我讲什么是架构，那个时候的我对架构是没有体系化认知的，都是凭着感受作的，是不知道本身不知道。

再后来，来到了阿里作应用研发和架构了，发现业务开发中也包含了各类方法论，而之前看过的建模相关的资料，在中间件等基础设施上也没有太大的感受，反而在业务技术领域发挥出了巨大的光芒。也发现越靠近用户的架构，随着企业的慢慢壮大会变得愈来愈重要。这个时候的我对架构认知是知道本身不知道了。

既然知道本身不知道了，那么就是要追寻它，曾经我和很多业务的研发同窗讨论过架构是什么，撇去基础设施架构和物理架构等视角不谈(这些视角聊起来也是篇幅很长的)，我挑应用逻辑架构并从几个角度来尝试描述一下：

1)从架构的总原则的角度：尽量简单(在当前场景下要尽量简单便于扩展和维护)，可是不能太简单(相对而言太过于简单可能在场景上有所遗漏).

2)从架构的目的角度来考虑：既要解决过去的问题，也要解决如今的问题，还能适度解决将来的问题，这些问题既包含技术问题，更包含业务问题。

3)从形态之 2 维的角度来考虑：架构就是横的问题，和竖的问题。横就是分层，竖就是分区，横竖都有抽象的事情要作。

4)从形态之 3 维的角度来考虑：架构是三维的，在 x 轴和 y 轴上有横竖的问题，在z轴上还有粒度的问题。

5)从时间轴的角度来考虑：架构不是一层不变的，是随着业务的发展在不断变化的。

能够看出，虽然我试图从以上几个视角对架构进行了描述，可是显然这些描述都是见仁见智的观点，是从某个角度来看架构。心里里我以为本身提炼的高度是不够的，实践中的总结必须和业界的知识结合起来，我必须学习前人已经总结的体系。因而在不断的搜集资料的过程当中，我发如今 ISO/IEC 42010:20072 中对架构有以下定义：

The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

这个最顶层抽象我我的以为很是到位，根据这个定义，显然，咱们在架构中须要：

• 职责明确的模块或者组件
• 组件直接的关联关系很是明确
• 须要有约束和指导原则

这个架构的定义很简练，很实在。小到一个玩具，大到一个国家的运做均可以隐含着这样的内容。

但这是一个广义上定义的架构，通过一些总结思考，我以为实际上具体到咱们平常的工做中，在不一样的层次，会有更加精细化的架构分类。

1.3 架构有哪些分类

在工做中我遇到不一样职位的人从不一样的角度来描述架构，可是咱们鲜有能达成共识的，刚开始我也不知道为啥讨论不到一块去，后来通过一段时间的纠结和深刻仔细的思考后，我发现不少时候你们描述的架构都不是同一个角度的东西，因而我尝试从以下几个角度划分架构的类别，以帮助咱们在不一样的场景和不一样的人聊天时你们能够聚焦，明确咱们究竟是在讨论哪一种架构，以提高沟通效率，并尽快达成共识，目前这个划分已经在咱们团队基本达成共识。

值得注意的是，无论下面哪一种分类的架构，都符合上一节总的架构的定义：模块(组件)+ 关系 + 约束 & 原则。

1. 产品功能架构

这个是产品经理最喜欢讲的架构，通常来讲，讲咱们有什么功能的时候，产品功能架构描述的是能作什么，受众群体通常是使用产品的同窗。若是咱们作软件设计时，不该该产出这玩意，而是应该产出应用逻辑架构和应用物理架 构。可是一旦咱们要对外宣讲咱们的产品，好比咱们的接口有啥用，应该怎么用，这个时候咱们讲的应该是产品功能架构。

• 目的：指导用户使用产品，因此模块的聚合是从用户视角出发的
• 受众：使用产品的人
• 包含的内容：阐述产品功能模块的能力：好比一辆汽车，方向盘有什么功能，方向盘的按钮上各区域的功能是什么，仪表盘分红哪些功能模块，每一个功能模块有什么做用，油门踏板有什么做用，刹车踏板有什么做用。可是也不排除有些高阶用户须要明确知道变速箱的齿比等信息，因此在产品功能架构图上也能够描绘出来。
• 命名：这里命名须要考虑如何取一个吸引人的名字(同时又能表达产品的能力)来吸引咱们的用户前来使用，好比说之前常常有产品套用“纳米”，又有产品套用“绿色”等等。

2. 业务能力架构

用来分析业务，业务概念架构是指拥有哪些业务模块，且各自的能力是什么，这张图有助于咱们分析和理解业务需求，也有利于产品经理分析业务。因此业务概念架构和业务概念模型都是用在分析阶段。

• 目的：研发人员和业务人员理解业务内在的概念和联系。
• 受众：研发人员和业务人员，主要是给规划业务的人使用。
• 包含的内容：业务能力，能力中的子能力。

3. 应用逻辑架构

软件设计自己，模块，粒度，职责，复用，等等，在讲解软件设计的时候，使用的是这个架构图，这个架构图是经过系统模型和业务概念架构推导而来。因此系统模型和应用逻辑架构都是用在软件设计阶段。

• 目的：指导软件的研发。
• 受众：研发人员，各层级架构师，各层级技术管理者。
• 包含的内容：阐述架构中各模块的职责：如系统模型，技术模块，技术模块的关系，技术模块的核心抽象，如何用设计模式来让架构符合软件设计原则，等等。若是拿汽车举例，那就是发动机模块中包含了哪些子模块(活塞，曲轴，连杆，缸体，缸盖，等等)发动机模块和变速箱模块之间的关联关系是什么，如何协同工做，和底盘的关联关系是什么，如何协同工做。发动机，底盘，变速箱，电子系统在整辆汽车中的职责，关系，约束是什么。这些都是用来指导汽车研发的。而不是指导用户如何使用这辆汽车的。
• 命名：这里的命名须要朴实无华，精准的描述出职责，华而不实反而让技术的同窗没法理解这究竟是什么玩意，致使实施的时候职责放错地方，挖下大坑让后人来填。

4. 应用物理(部署)架构

软件部署时的架构，这张图推导自应用逻辑架构，推导时重点逻辑架构如何落地，好比使用何种微服务容器，逻辑架构的模块落地时应该是 package，仍是应用，也有多是一组应用，是否是要跨机房部署，甚至跨国部署等等。还须要考虑稳定性，性能，成本等话题。

5. 基础设施架构

选择什么样的中间件，存储，监控，报警，等等。

6. 等等

1.4 能力和职责的区别

在平常的架构讨论中，有的同窗常常谈架构的能力，有的同窗常常谈架构的职责，那么能力和职责有什么区别?跟产品的同窗打交道多了以后，发现产品同窗不少都是讲能力，后来技术的同窗也开始讲能力，而一般咱们架构的同窗原来说的都是职责，二者有什么区别呢，我说说本身的理解：

1. 能力(产品功能模块的能力)

是指一个产品能作什么，好比中台自己是一个产品，对使用中台的同窗来讲，咱们应该讲中台的能力(实际上是在讲中台这个产品的能力)。因此讲能力是讲给架构的使用者或者其余想了解的人来听的。

2. 职责(逻辑架构中各模块的职责)

是指架构内模块的职责，用来指导开发，好比中台研发的同窗，应该讲架构的职责，依赖，约束。因此讲职责是讲给研发的同窗，讲给域内的架构师，讲给域内的管理者来听的，总的来讲就是讲给架构的实现者来讲的。

简单来讲就是：能力是指产品的能力，职责是指架构内部的职责。若是架构自己也是一个产品需对外输出(如中台，或者其余技术框架做为产品输出)，则对外输出时，咱们应该讲这个技术产品的能力(这个时候技术的同窗也就开始讲能力了)。因此当咱们讨论问题的时候，若是有的人在谈产品能力，有人在谈架构内部职责，那么显然已经不是在讨论同一个话题了，请你们务必注意区分这种状况，差之毫厘，谬以千里，鸡同鸭讲啊。

好比说两个模块 A 和 B，职责不同，可是依赖了相同的二方库。那咱们不能说某个职责在这个二方库里。这个二方库做为某个独立的技术小产品，提供了某些能力。可是履行职责的仍是 A 模块或者 B 模块。

1.5 应用逻辑架构的地位

正如前面咱们描述的架构分类所描述，有些架构和具体业务是无关的，有些架构是和具体业务息息相关的，好比说应用逻辑架构就是和业务息息相关，它来源于业务的抽象，甚至咱们能够说：它是业务线技术架构设计中第一份产出。

既然他是首要的产出，咱们就必需要考虑应用逻辑架构中应该包含的三类主题：

• 模块

• 依赖

• 约束

绝大部分的架构问题均可以概括成这三类主题，这些主题包含哪些内容呢?这就是本文接下来要介绍的内容，应用逻辑架构的设计不须要拍脑壳，是经过科学的方法体系推导出来的。

2、架构的两种推导思路

架构的产出总的来讲有两种方式，一种是自顶向下的方式来推导架构，一种是自底向上的推导方式，并且两种方式每每是相互结合来产出最合适的结果。而在业务线的同窗，可能接触最多的是自底向上的推导的方式，自底向上的推导的方式也是本文中要重点讲解的架构推导方式。

2.1 自顶向下的架构推导

自顶向下的推导的关键问题在问题定义，若是问题没有被准确的定义，那么自顶向下就没法推导出正确的结果。假设问题被准确的定义了，如何自顶向下推导呢?

2.2 自底向上的架构推导

咱们在业务线作开发的同窗，天天确定跟不少需求打交道，这些需求哪里来的?基本上有这三种产出：

1. 有些是来自产品方一拍脑壳产生的灵感
2. 有些是对数据进行了详细的分析产出的产品策略
3. 有些是当前产品中暴露的一个个问题

产品方的这些详细的需求来了以后，咱们是如何应对的呢?咱们首先和产品方一块儿讨论产品方案的合理性，在产品方案合理的基础上，咱们来开始识别用例，开始了一系列软件工程领域方面的措施。其总体过程以下图所示：

自底向上推导逻辑架构就是最右边表明的那条曲线。

这里基本上就是本文接下来要重点阐述的：如何自底向上推导应用逻辑架构，这个过程就是一个抽象和架构的过程。

那么咱们从总体方法论的介绍开始，采用总分总的结构，下面这张图就是应用逻辑架构自底向上的推导路径，这个推导路径是有序的，每一个步骤都包含了大量的操做技巧，前一步作好，后一步才有可能得出正确的结果。

这张图中有几个重点：

1)软件研发分红了两个阶段：

• 分析阶段，也是咱们常说的问题空间领域建模，关键的一步是业务概念模型的输出，而业务概念模型输出的前置条件是从需求中分解出合理的用例集合。
• 设计阶段，也是咱们常说的解决方案空间建模，以及应用逻辑架构。

2)图中存在了箭头这个东西，说明了咱们作架构推导的主要的思惟路径，也说明作架构不须要拍脑壳，都是根据严密的逻辑推导出来的。

这个严密逻辑基本是一个自底向上的推导过程，底层的模型是经过建模方法演绎出来，逻辑架构中的各个模块是经过概括的方法推导出来。那么：

• 什么地方应该用演绎，什么地方应该用概括呢?
• 使用演绎的时候应该使用何种具体方法呢?
• 使用概括的时候应该使用何种具体方法呢?

咱们再留一个悬念，后面再讲。

无论是演绎仍是概括，都是抽象工做的一部分，并且都须要素材，这里的素材就是咱们对需求，对业务的理解，以及对技术的深度广度的把握。没有素材，方法论掌握再好也得不出结果。

素材哪里来呢?

业务素材的来源大部分是你须要解决问题所在的领域，好比咱们在电商领域，那么咱们就要多搜集电商领域的业务知识。若是咱们在数据领域，天然要多搜集数据业务的相关知识，以及咱们前文中讲到的技术类的相关知识。

而技术素材是要求咱们在技术领域不断的钻研，不断的扩展边界，深度不断增长，广度也不断增长。因此对于架构师来讲计算机科学与技术是绝对要不断精进的。

2.3 两个方法的区别

自顶向下推导的一个前置条件就是你须要知道猪长什么样，在架构上就是你须要知道这个架构的原来是是什么样子的，解决什么问题的。若是都不知道猪长什么样，那么就无从判断猪是否是适合当宠物了。此处须要有必定的业务领域理解力和领域经验(包含：客户的问题和痛点是什么，怎么分析出来的，当前的架构方案是什么，当前的架构方案是如何解决这个问题的，将来的架构方案如何更好的解决这个问题)。

而自底向上推导则没有这个问题，由于是看着猪来作推导的，知道猪的细节，这个细节的特色如何演绎，如何概括，最后得出结论。

因此当咱们不熟悉一个大的业务的时候，咱们自顶向下推导架构的难度是极大的，几乎不能完成。不了解业务或技术状况时定义出来的问题也未必是一个被正肯定义的问题，容易给人形成一个印象：瞎指挥。

这个时候如何在没有知识背景的状况下快速落地就得自底向上的来推导架构。在自底向上的过程当中慢慢熟悉业务。

可是若是工做中往往都是纯粹的自底向上的推导架构，是没法帮助咱们来作技术的前瞻性布局的，此时架构师的成长就遇到的瓶颈，因此此时又要使用自顶向下的架构推导方式。

综上所述，无论是自底向上，仍是自顶向下，都是架构师须要掌握的技能。

3、自底向上的架构方法：业务概念架构推导

这部份内容，我在 ICBU，村淘，一达通，菜鸟，AE 现场分享过。尤为是在 AE，一达通和菜鸟，相关的同窗都拿出了当时的纠结你们好久的难题，咱们一块儿使用了这样的方法很快就分析出了业务概念模型，而且对模块进行了简要的划分，造成概要的业务概念架构。通过大量的实战，效果是很是明显的。

3.1 模型的 3 个层次

在这里，我把一些常见的概念集中起来，便于你们统一律念：

1. 业务概念模型，问题空间领域模型，信息模型是一样的意思，这个层次上的实体咱们称之为概念实体，这部份内容是用在需求和业务分析上的，讨论业务概念模型时彻底不须要考虑软件的实现，这个过程是一个分析过程，即便不作软件研发，作其余的研发，相似的分析过程也应该是有的。

2. 系统模型，解决方案空间领域模型，逻辑模型是一样的意思，这个层次上的实体，咱们称之为系统实体，或者逻辑实体，就是各类类，这个是用在软件设计和软件研发上的。

3. 存储模型，数据模型，物理模型，在这里也是一样的意思，这个层次上的实体，咱们称之为数据实体，或者物理实体，也是用在软件设计上。

这 3 个层次实际上是从 3 个角度在看待问题，他们之间是自上而下的转换的关系，这里尤为要注意的两个词是：逻辑的，顺序的推导。

这些不一样层次的模型是应用逻辑架构的基础!!!

3.2 模型的推导

3.2.1 用例集合推导概念模型

1. 根据用例集合推导业务概念模型
2. 根据用例中的动词和量词推导业务概念模型的关联关系
3. 在特定的边界内根据模型的职责概括子域

重要!重要!重要!这里业务概念模型若是没有分析正确，那么下面要搞清楚是不容易的，这个分析部分是软件逻辑架构设计的基础。

这个环节须要咱们理解业务，更须要咱们掌握问题空间建模这一严谨的方法论，这样咱们才能推导出合理的模型，整个过程是很是严谨的，很是符合逻辑的。

我在各 BU 分享现场作的屡次实战演练之因此能成功的快速帮助同窗们梳理出前面花一两个月都没有理出的模型，彻底是由于于现场的同窗对业务的理解(由于讨论以前我彻底没有了解过对方的业务)和这套方法论(隐含在个人提问方式中)。因此说对业务的理解和方法论，二者缺一不可。

3.2.2 对业务概念模型进行概括

在模型产出以后，咱们要对模型进行概括。

什么叫概括?

概括的意思是将全部的结果和想法合并，变成一种思惟概念。或者让某个模型归属于某个已经存在的思惟概念。且这些模型或者模块的职责不能超越这个高层次思惟概念的边界。

为何要概括?

实际上是为了保证相近的职责模型聚拢在一块儿从而保证职责的高内聚，同时明确出来的两个子域的边界，保证模块和模块之间的低耦合。

对业务概念模型的概括有助于作业务需求分析时判断高内聚和低耦合，并且在系统模型上，对系统模型进行分类也有助于作应用逻辑架构中模块的高内聚和低耦合，可是应用逻辑架构的不止高内聚和低耦合，还有其余让职责单一的方法，这些后面的章节会作介绍。

3.2.3 按职责来进行概括

接下来咱们来说讲业务概念模型到业务概念架构判断方法：

1)经过名词定义来进行概括思惟概念

若是多个模型都在围绕某个名词，那么咱们倾向将这个名词提炼出来。产品在设计时，基本上咱们已经可以得一个粗略的业务模块划分，可是这个粗略的划分是不必定是合理：

• 一是有可能咱们的理解是不到位的，致使用错了名词，这个咱们前面的文章中也提到过了。
• 二是这个结果也只是一个粗略的结果，须要进一步精化。

2)经过内聚的度量公式来进行概括

业务模型图中，模型和模型连线(连线就是模型和模型链接线)数量除以模型的梳理获得的值比较大的，那么咱们能够看作是内聚，这些连线比较紧密咱们趋向将其放到一个模块中，连线不是那么密切的，咱们趋向于将它们放置在不一样的模块中。而后咱们再观察 连线数 / 模型数 观察内聚度量是高了仍是低了，经过这样的方式概括完成以后，咱们再来经过度量公式来度量各模块的内聚和耦合程度。

3)其余概括方式

若是咱们划分出了基本模块，发现还有一些模型不肯定应该放到哪些模块中，咱们还可使用建立者原则和信息专家原则来判断应该将该模型概括如哪一个模块。

好比说，对存储系统进行系统建模，表和字段的关系在业务概念模型中是1对n的关系(在系统模型中是组合关系，强生命周期依赖，可是这里咱们尚未到讨论应用逻辑架构的时候，只是在推导业务概念架构)，此时将字段放到另一个模块显然不合适，缘由是根据建立者原则。

当咱们不清楚把字段模型放到哪一个模块的时候，咱们能够看看字段这个模型是由谁建立的。

根据这条原则显然这里是表建立了字段，没有表对象，就没有字段对象，因此根据这条原则，咱们就倾向于把字段模型放到表所在的模块中。

重点：失去了最底层合理且正确的演绎，上层的概括掌握的再好，也很可贵出合理的结果。

咱们来看看概括以后的效果示意图：

图中的 A1，A2，A3，A4 之类是示意图，表示 A 模块内部还存在子模块，固然咱们实际上是先推导出子模块，而后对子模块再次进行高级别概括，造成父模块。

父模块层级再进行概括，就造成了祖父模块，或者再向上造成曾祖父模块等等。粒度越大的模块，通常都对应更大的组织，越存在跨团队沟通，因此划清边界的要求就越高。

3.3 业务流程

除了业务模型以外，业务流程也是咱们须要总结并明确的地方，这个地方主要明确的就是边界和异常分支等等，尤为是异常分支很是重要，不少业务方案的设计中对异常分支的考量是不重复的，这须要工程师对业务方案提出挑战，以明确业务方案中的各类流程的异常分支。

3.4 业务概念架构总结

咱们工做中常见的推导有两种方式，一种是自顶向下推导，一种是自底向上推导，显然，两种推导使用的方法是不同的。细心的读者会发现，其实咱们刚刚说的问题空间领域模型和边界分析这套方法就是自底向上的演绎和概括方法。

4、基础逻辑架构推导(软件设计阶段)

前面咱们讲到了业务分析阶段，也是问题空间建模和问题空间业务概念架构梳理，业务分析阶段和软件没有任何关系。但本文中它是软件设计的前置条件，没有 get 到点的同窗，请务必再把前一章仔细阅读。

接下来咱们来说讲软件设计阶段咱们须要产出的应用逻辑架构。

4.1 再谈逻辑架构特性

文章开头讲到了逻辑架构的相关特色，咱们回顾一下：

• 应用逻辑架构的做用：咱们把前面那个例子再搬过来：若是拿汽车举例，那就是发动机模块中包含了哪些子模块(活塞，曲轴，连杆，缸体，缸盖，等等)发动机模块和变速箱模块之间的关联关系是什么，和底盘的关联关系是什么，发动机，底盘，变速箱，电子系统在整辆汽车中的职责，关系，约束是什么。这些都是用来指导汽车研发的。而不是指导用户如何使用这辆汽车的。
• 目的：因此系统模型和应用逻辑架构都是用在软件设计阶段，其目的是用来指导软件的研发。
• 受众：逻辑架构的受众有哪些呢?通常是这些人：研发人员，各层级架构师，各层级技术管理者，总的来讲他们都是架构的设计者和实现者。

这里仍是请你们务必要跟产品功能架构区分开来，它们的受众和目标是不同的。

4.2 基础逻辑架构的推导概要

在文章开头的图中，咱们讲到应用逻辑架构来源于系统模型，数据模型，业务概念架构，还有流程，以下图所示。

接下来，咱们分别从三个角度来阐述逻辑架构的生成：

1. 业务概念架构
2. 模型(系统模型和数据模型)
3. 流程(系统调用流和数据流)

看到不少同窗画的图没有区分出调用流和数据流，常常形成误解，形成沟通效率降低，甚至不可以准确的说明问题。因此在画图的时候，必定要注意区分调用流和数据流。

接下来就根据业务概念架构和系统模型及流程来推导一下应用架构(逻辑架构)。咱们来看一下一个简单的逻辑架构构成的 gif 示意图：

从这张图中，咱们能够看出应用逻辑架构是如何一步步被构成的，整个过程存在如下关键点：

1)在业务概念架构的基础上推演应用逻辑架构。

2)根据流程和系统模型来完善应用逻辑架构。

3)横向提炼模块的问题：要实现业务模块，须要什么非业务模块的支撑，好比监控，报警，配置等等，而这部份内容每每仍是可复用的。在上述动画中，能够理解成移动到最右侧的部分，固然能够移动到左侧，只是动画中没有体现出来。

4)纵向提炼模块问题：有相似职责的模块在技术实现上是否能够提炼成可复用内容，提炼的结果多是：

• 独立的服务复用，在上述动画中，能够理解成最下方。
• 或者二方库复用，在上述动画中，能够理解成最左或者最右侧。
• 等

5)还有一些模块是为了支撑性能或者稳定性的，并不是是从业务概念模型提炼而来，如图中深蓝色的模块。

最终，出现的逻辑架构是分层的和分片的逻辑架构，下面咱们来一步步阐述这个过程。

4.3 根据业务概念架构推演

业务概念架构图产出以后，基本上，咱们逻辑架构的初步模型就具有了。因此咱们能够理解成，第一步就是把业务概念架构直接先搬到应用逻辑架构中来，此处就不用多阐述了。

啰嗦两句：尤为是较为顶层的粗粒度业务架构，一个是自顶向下分解得来，一个是自底向上演绎和概括得来。而自顶向下分解尤为考验人对业务的理解能力，若是对业务理解不透彻，那很难产出合理的粗粒度业务概念架构。

4.4 根据系统流程进行推演模块

当业务概念架构产出以后，逻辑架构的骨架初成，接下来就是在这个框架上去填充内容。第一步就是根据流程来进行模块划分。

总结一下，这里的方法就是，先根据业务流程，分解出系统时序图，根据时序图开始对模块进行概括，从而获得粒度更大的模块。

这是粒度比较细的根据流程划分模块的案例，在粒度更大的流程，此方法一样适用，看你们是工做在何种粒度上。

经过流程来进行推导是咱们平常工做必不可少的一部分，尤为当不少场景的流程具备业务共同点时，那么能够考虑提炼出这些业务共同点，以提高研发的效率。

4.5 非业务线系统根据流程推导模块案例

除了对流程进行概括以外，咱们还能够对系统模型进行概括。咱们知道，业务概念模型通常能够直接转换为系统模型，可是系统模型并不仅是业务领域相关的模型，好比查询模型是一个常常出现的，这在 OLTP 的场景十分常见，而在 OLAP 的场景简直就是顶梁柱。很是常见的就是 SQL parser 模块，下图是 spark 体系中 SQL SQL 的主要流程和对应的模型，根据这个模型咱们基本上也能够梳理出模块：

根据这个流程，咱们发现了什么?咱们发现了 spark 中是这样分模块的(这里面的模块已经落地成 package 了)：

因此说按照业务流程转换成的系统流程来推导模块是很是重要的手段。

除此以外须要还须要强调的是，流程和模块同样，也是有粒度的，相同粒度的流程节点放在一块儿才更加容易推导出合理的架构模块。至于什么叫相同粒度，请参考一下《金字塔原理》。

流程的粒度很重要，粒度粒度粒度，请重视流程的粒度。

4.6 根据性能 & 稳定性 & 成本等进行提炼模块

前面讲的都是从业务的角度来阐述架构的推导，接下来咱们从计算机科学与技术的角度来阐述一下这些非功能性模块的推导，这里拿性能来举个例子吧。

数据分析的报表场景下降 RT 的方案

在一些数据分析产品中，绩效监控及报表展现是一个很是重要的场景，这个场景下的数据量是比较大的，为了下降 RT，咱们不得不经过 ETL 对数据进行预计算，将原有的大表清洗成聚合以后的小表，以加快查询的速度。这样作的缺点是每次进行报表的修改，就要进行相关的ETL逻辑，高时间和人力成本，高性能。

为了把高时间和人力成本 & 高性能转换成低成本&高性能，咱们须要把人工操做转换成自动操做，把 ETL 的过程去除。

第一个选择是将一个大表的数据存储到另一个支持大数据下高性能的查询引擎，这样就极大的减小了 ETL 的操做，可是这样就带来一个问题，就是大数据量下把数据从 ODPS 导入到某个 ROLAP 的查询引擎中是比较耗时的，并且每次查询须要进行在海量数据中进行大量的 scan，但实际上获取的数据量并不大。这样的查询的 RT 依然须要亚秒级。

第二个选择是根据报表的定义，自动的将判断出用户须要查询什么结果，将查询结果提早计算出来，而后只把这些少许的预计算后的结果导入到 ROLAP 引擎中(具体请参考 apache 开源项目 Kylin)。而后在报表的场景下，查询的 RT 降低到了百毫秒级。

显然咱们要实现第二种方式，这个时候在业务功能没有增长的状况下，咱们必需要增长一个模块，在咱们的产品中，咱们称之为 intelligent cube，由于咱们这里引入了机器学习算法对 cube 的构建进行了预测，无需或者只需很是少许的人为参与。

最后致使逻辑架构中有部分是来自业务概念架构推导而来，有部分是系统流程推导而来，有部分是由于性能 & 成本的须要产生的设计。

注意：理论上来说，逻辑架构上须要指出模块之间的依赖关系，只是若是这样，不是特别美观，因此就根据上下和左右的位置来大概描述模块之间的关系了。

这两个案例基本能够说明，根据性能 & 成本 & 稳定性推导出来的模块也是逻辑架构组成的重要部分。

可是这个还只是一个场景一个场景来解决 RT 问题，虽然 icube 本身内部是有个体系的，可是经过这样的方式来解决 RT 问题对于整个架构来讲也是自底向上构建的一个环节。在下一篇文章中，咱们将会阐述相同的案例，可是思路是自顶向下来构建性能领域的体系化架构。一样一个事情，用不一样的思路来作，对总目标的帮助是不同的，并且两个方法是互补的，谁都少不了。

这样的模块是如何得来的呢?

看上去咱们都已经知道了系统中有很多相似的纯技术相关的模块，可是这些模块内部是如何设计出来的呢?

通常来讲有以下方法帮助咱们作这些模块的内部设计：

1)调查业界的开源技术类产品中是否有相似功能的，好比预计算在业界有 kylin，而星环等专业大数据公司也都有本身的 cube 预计算产品。

2)查阅业界相关的论文，好比说在预计算领域就已经研究了几十年，计算机发展的不一样阶段有不一样的论文，网上一搜一大堆，不断研究，必对工做有帮助。

3)多关注业界的牛人，看看他们在想什么，说什么，参加参加相关的会议。

4)本身经过逻辑和数据结构 & 算法推导出来。

若是每次都只经过本身的逻辑和本身已经掌握的知识来进行方案的推导是不够的，一个是咱们的技能有时候和事情是不匹配的，可是咱们每每不知道这样的事实的存在，因此此时必定要虚心学习，请教他人，扩展本身的知识边界，才能作出更好的方案和技术决策。

4.7 应用逻辑架构推导小结

根据上文所述，基本上应用逻辑架构的推导有 4 个子路径，他们分别是：

1. 业务概念架构：业务概念架构来自于业务概念模型和业务流程
2. 系统模型：来自于业务概念模型
3. 系统流程：来自业务流程
4. 非功能性的系统支撑：来自对性能，稳定性，成本的须要

每一个子路径中都存在相关的具体方法。

若是真的要想学习东西，并且想学的更快更深刻，就要关注本身如何集中注意力，要思考本身的思考方式，研究本身的研究方式。

Blog: https://blog.yilon.top