一文道尽软件架构及前端架构演进

人人都在说软件架构，但人们并不能给出一个准确的定义，就像Martin Folwer在《Making Architecture Matter》上分享说的， Architecture is about the important stuff. Whatever that is 。

软件界的人们长期以来一直在争论架构的定义。对于某些人来说，这就像是系统的基本结构，或者是将最高级别的组件连接在一起的方式。但Martin认为没有客观的方法来定义基本的或高级的组件， 软件架构的更多是专家开发人员对于系统的设计的共同理解 。

架构的第二种常见定义是，它是“需要在项目早期就做出的设计决策”，但是Martin觉得更像是在项目开发过程中你期望能够早日做出的正确决策。

因此，软件架构是关于软件开发中重要的事情。思考软件架构其实就是思考哪些是最重要的事情，并且要保持这些部分始终运行在良好的状态下。

软件架构通常涵盖三个部分：

• 架构模型：定义了系统组件是如何组织和拼装的，明确系统的组件模块，划分各自边界以及如何组合在一起。

• 通信接口：定义了系统组件之间是如何进行通信的，通常指的是组件/模块之间的通信方式、接口定义、API。

• 质量要求：定义了非功能性的系统要求，例如扩展性、稳定性、高可用性、高并发、高性能、安全等等。

不同阶段构成架构的因素是不同的，基于这个思路，架构设计可以分为四个层级：

• 系统级，即应用在整个系统内的关系，如与后台服务如何通信，与第三方系统如何集成。

• 应用级，即应用外部的整体架构，如多个应用之间如何共享组件、如何通信等。

• 模块级，即应用内部的模块架构，如代码的模块化、数据和状态的管理等。

• 代码级，即从基础设施来保障架构实施。

02

为什么软件架构很重要？

软件架构代表了软件内部是组织运作的方式，这个往往并不会被用户所感知，因此，软件架构在某些时候会被忽略。

对于用户而言，良好的用户界面和系统运行错误是能够被感知的，而内部的模块化设计并不会被感知，于是，良好的架构设计是很难被衡量的。

架构的根本价值在于能够降低未来功能开发的成本。

如上图所示，对于架构糟糕的系统而言，其初始的开发速度是比较快的，但是随着时间的推移，要在其上面添加新功能变的越来越困难。开发人员需要花更多的时间理解原有的代码，需要更多的时间进行测试，并且很容易出现问题需要修复。

对于架构良好的系统而言，虽然其初始的开发速度不快，但随着时间的推移，其研发效率将会变得很快，并且易于扩展。

可悲的是，软件开发人员通常不能很好地解释这种情况。管理者不想让开发人员编写高质量的代码，因为它花费的时间太长。我们习惯于在生活中进行大多数决定的成本与质量之间的通常取舍，对软件的内部质量没有意义。由于成本与内部质量之间的关系是不寻常且违反直觉的关系，因此，良好的软件架构在长期而言是非常重要的。

03

有哪些架构设计模型？

对于软件架构设计模型，我们可以从两个层面来看。第一个层面对应的是系统的情况，所有功能在一个单一巨石系统(Monolithic)、基于服务的系统(Service-based)和分布式系统(Dsitributed)。

分层架构

对于巨石系统而言，通常的软件架构方式是基于分层设计。

通过分层设计可以将系统进行解耦拆分，每一层都会专注于自己的功能，并且提供对外暴露的接口以供上层调用。

微服务架构

对于基于服务的系统而言，通常的软件架构方式是微服务架构。

通过将一个巨大的系统拆分成一个个独立的、单独部署的服务(Service)，可以让系统变成松耦合的状态。服务之间通过API进行通信，并且所有的服务通过特定的组织方式整合在一起共同工作。

每个小服务都在自己的进程中运行并与轻量级通信机制（通常是HTTP API）进行通信。这些服务围绕业务功能构建，并且可以由全自动部署机制独立部署。这些服务几乎没有集中管理，它可以用不同的编程语言编写并使用不同的数据存储技术。尽管微服务的优势使它们在最近几年变得非常时尚，但它们却带来了分销增加，一致性降低的缺点，并且要求运维管理成熟。

插件式架构(Service Oriented Architecture)

插件式的架构体系，通常由一个核心系统(Kernal系统)和一系列插件组成。核心系统提供了最小可用的功能，通过插件来不断扩展系统能力。浏览器、文本编辑器、IDE等系统就都是采用插件式架构体系。

04

前端架构演进

前端过去十年发展经历了巨大的变化，从PC时代进入了移动时代再到智能时代，前端架构也从无到有，逐步演进变得百花齐发。

前后端分离架构

随着前后端分工划分越来越明确， 前后端系统也逐步分离 。前端系统变成了静态前端资源，部署HTML、JS、CSS文件，后端服务提供API（通常是REST API），前后端通过API进行通信。

前后端分离解决了前后端分工的问题，但是随着移动互联网到来，前端变成多端状态（PC、iOS、Android），因此后端服务需要针对不同端提供定制化服务，前后端协同沟通成本开始变大。

于是， Node BFF 应运而生。通过Node层，前端的研发人员就可以来编写后端服务的适配层，用于接口的整合编排、字段裁剪，甚至服务端渲染直出提升首屏性能。

Node服务虽然可以进一步提升前后端协同的效率，但是Node服务器的运维、部署、发布、监控等等成本也让前端研发同学苦不堪言。 Serverless 的诞生可以帮助解决这个问题，可以将服务器的运维功能都交给Serverless平台进行管理，研发人员只需要专注于实现函数即可完成功能开发。

在前后端分离BFF，除了采用Node层技术以外还可以采用 GraphQL 技术，通过GraphQL技术可以很容易使用Schema来定义需要获取的数据结构，灵活的对现有数据源进行聚合和字段裁剪。

组件化架构

组件化架构是前端一个最为显著的架构方式，通过组件的封装和组合，可以快速的进行页面UI的搭建。

组件化也经历了不同阶段的演进：

• 组件库：以Ant Design、Element为代表，提供一系列统一设计语言的原子组件。

• 模板库：以Ant Design Pro为代表，提供一系列的组件模板/页面模板，例如用户详情页、登录页等等，方便快速搭建功能页面。

• 配置化：以Fusion Design、飞冰、云凤蝶为代表，通过可视化拖拽来自由拼装页面，进一步提升前端研发效率。

分层架构

不论是 MVC（Model-View-Controller） 还是 MPV（Model-Presenter-View） 模式，都是将数据、界面、控制分离的方式。通过代码职责的拆分可以有效的将系统进行解耦，从而让各自部分能够很好的分工并且协同。

随着页面逻辑复杂度提升，又演化出 Redux 、 Mobx 等数据流控制的框架，进一步将数据控制部分拆分成Store、Action、Dispatcher，避免了数据更改的混乱，将数据管理进行了统一，规范了数据修改的方式。

Clean Architecture是分层架构的一种形态，分为Entities、User Case、Controllers、UI四层，外部层级是依赖内部层级，内部层级会对外暴露接口，但是避免暴露内部实现，所以越是上层的功能可以屏蔽掉内部的变化，降低层级之间的耦合度。

微前端架构

微前端架构是一种将微服务理念应用到浏览器，将多个小型前端应用聚合为一的应用。微前端架构可以允许各自小型应用独立部署、独立的技术栈，因此，特别适合遗留老旧系统的整合。

不必花费大量人力对老旧系统进行技术栈升级，通过微前端架构即可将其整合到新应用中。在新应用中可以使用新技术栈，老应用技术栈保持原状，两者功能上又可以进行通信和整合。

05

写在最后

软件架构也“没有银弹”，不存在某个普世好用的架构。软件架构总是伴随着业务功能的发展、系统稳定性、并发性不断发展而不断演进的。结合业务发展的规模，人员的能力，找到最适合你的架构才是最好的架构设计。

最后，推荐几本关于软件架构的经典著作，如果有推荐的书籍欢迎留言交流。

- End -