常见的架构风格
分层风格
这是最常见的架构风格，它将系统按照水平切分的方式分成多个层。一个系统由多层组成，每层由多个模块组成。每一层为上层提供服务，并使用下层提供的功能。最为人所知的分层架构应用是OSI七层模型和TCP/IP五层模型，在开发后端服务的时候得到了广泛的应用。如在采用Spring MVC开发的后端应用中，Controller层在接收后端请求时，将通过Service层向DAO（Data Access Object，数据访问对象）层请求数据，而不是直接向DAO层请求数据。
MVC架构
这种风格应用得相当广泛，它强调职责分离，将软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）。由视图和控制器一起完成用户界面的功能，并设计一套变更机制，来保证用户界面与模型的一致性。它是一种常见的架构风格，在涉及图形用户界面时，往往都有它的身影，如前端应用、移动端应用等。
发布-订阅风格
这种风格又可以称为基于事件的架构风格，它是一种一对多的关系，一个对象状态发生改变时，所有订阅它的对象都会得到通知。这种架构风格带来的最大好处是，代码上的解耦。发布者不关心事件的订阅者，只需要在适当的时候发布相应的事件即可；而订阅者则依赖于事件，而非事件的发布者。在前端的日常开发中，为了解耦不同的UI组件的依赖，会经常采用这种模式。
管理和过滤器
这是一种适合于处理数据流的架构模式，它将每个步骤都封装在一个过滤器组件中，数据通过相邻过滤器之间的管道传输。最典型的管道-过滤器架构是UNIX shell的设计。在类Unix系统中，使用“|”作为管理符号，当我们需要编写复杂的Shell脚本来处理内容时，便会使用这个符号。诸如ls-l|grep.jpg，便会先执行ls-l命令，再将结果交由grep程序，查找以．jpg结尾的文件名。
它也适用于相关的数据处理场景，如我们在采用Hadoop、Spark等编写数据处理相关的代码时，便会采用这种模式来编写。如前端框架的Angular，也直接内置了管理（Pipe）系统。
架构设计方法
RUP 4 +1 视图法
逻辑视图（Logical View）
在设计期的模块、接口划分、职责及协作方式等。
流程视图（Process View）
在运行期运行的数据同步，如在微前端中的数据流、控制流等。
开发视图（Development View）
在开发期的框架、库、技术选型及其对应的编译。
物理视图（Physical View）
又称为部署视图。在部署期与持续交付相关的技术决策
场景（scenarios）
又称为例视图，它使用一组用例或场景来说明架构
架构设计原则
不多也不少
不做多余的设计，也不缺少关键部分
演进式
不断地演进以使架构适应当前的环境
持续性
长期的架构改进比什么都重要
前端架构设计：层次设计
架构设计本身是分层级的，面向不同级别的人时所展示的内容也是不一样的，不同阶段构成架构的因素是不同的，基于这个思路，架构设计可以分为四个层级。
相应的层级解释如下：
◎ 系统级，即应用在整个系统内的关系，如与后台服务如何通信，与第三方系统如何集成。
◎ 应用级，即应用外部的整体架构，如多个应用之间如何共享组件、如何通信等。
◎ 模块级，即应用内部的模块架构，如代码的模块化、数据和状态的管理等。
◎ 代码级，即从基础设施来保障架构实施。
在设计的时候，既要用自上而下的方式来设计架构，又要用自下而上的方式来完善架构。从演进式设计的角度来看，我们需要在前期设计的时候，对所有系统级架构及部分应用级架构进行技术决策，而其余部分的架构则可以在实施的过程中考虑。
微前端的技术拆分方式
从技术实践上，微前端架构可以采用以下几种方式进行：
（1）路由分发式。
通过HTTP服务器的反向代理功能，将请求路由到对应的应用上。
在这个架构中，我们只需要关注应用间的数据传递方式。通常，我们只需要将当前的用户状态，从A应用传递到B应用即可。
（2）前端微服务化。
在不同的框架之上设计通信和加载机制，以在一个页面内加载对应的应用。
前端微服务化，是微服务架构在前端的实施，每个前端应用都是完全独立（技术栈、开发、部署、构建独立）、自主运行的，最后通过模块化的方式组合出完整的前端应用。
采用这种方式意味着，一个页面上同时存在两个及以上的前端应用在运行。而路由分发式方案则是，一个页面只有唯一一个应用。
同时，我们还需要保证应用间的第三方依赖不冲突。如应用A中使用了z插件，而应用B中也使用了z插件，如果一个页面多次引入z插件会发生冲突，那么我们应该尝试去解决这样的问题
（3）微应用。
通过软件工程的方式，在部署构建环境中，把多个独立的应用组合成一个单体应用。
微应用化是指，在开发时应用都是以单一、微小应用的形式存在的，而在运行时，则通过构建系统合并这些应用，并组合成一个新的应用。
微应用化与前端微服务化类似，在开发时都是独立应用的，在构建时又可以按照需求单独加载。如果以微前端的单独开发、单独部署、运行时聚合的基本思想来看，微应用化就是微前端的一种实践，只是使用微应用化意味着我们只能使用唯一的一种前端框架。
（4）微件化。
开发一个新的构建系统，将部分业务功能构建成一个独立的chunk代码，使用时只需要远程加载即可。
（5）前端容器化。
将iframe作为容器来容纳其他前端应用。
（6）应用组件化。
借助于WebComponents技术，来构建跨框架的前端应用。
实施的方式虽然多，但都是依据场景而采用的。在有些场景下，可能没有合适的方式；在有些场景下，则可以同时使用多种方案。
微前端的业务划分方式
与微服务类似，要划分不同的前端边界不是一件容易的事。就当前而言，以下几种方式是常见的划分微前端的方式：
◎ 按照业务拆分。
◎ 按照权限拆分。
◎ 按照变更的频率拆分。
◎ 按照组织结构拆分。
◎ 跟随后端微服务划分。
因为每个项目都有自己特殊的背景，所以切分微前端的方式就不一样。即使项目的类型相似，也存在一些细微的差异。
待续。。。
《前端架构：从入门到微前端》