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

Blog: https://blog.yilon.top

作者: 阿里技术

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

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

一、背景

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.

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QioMrOeP-1586353450968)(img/从方法到思维：什么是应用逻辑架构的正确姿势？ .assets/30a89a2dadc322ab13207c5d853fdab1-20200408104453569.jpg)]

这个最顶层抽象我个人觉得非常到位，根据这个定义，显然，我们在架构中需要：

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

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

但这是一个广义上定义的架构，经过一些总结思考，我觉得实际上具体到我们日常的工作中，在不同的层次，会有更加精细化的架构分类。

1.3 架构有哪些分类

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

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

1. 产品功能架构

这个是产品经理最喜欢讲的架构，一般来说，讲我们有什么功能的时候，产品功能架构描述的是能做什么，受众群体一般是使用产品的同学。如果我们做软件设计时，不应该产出这玩意，而是应该产出应用逻辑架构和应用物理架 构。但是一旦我们要对外宣讲我们的产品，比如我们的接口有啥用，应该怎么用，这个时候我们讲的应该是产品功能架构。

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