软件架构定义
软件架构是一个隐喻，类似于建筑物的架构，建筑学研究建筑的规划、设计和实施，而软件架构则是研究软件的规划、设计和实施。
软件架构贯穿系统实现的整个过程，软件架构就是软件的基本结构，是软件系统实现的主要参考，是软件系统实现的蓝图。
为什么要学习软件架构
软件架构的设计显得尤其重要，系统架构设计通过以下方式来解决上面的软件难题：
1.抽象系统
抽象是将复杂的概念简单化，在最高层次上，将软件系统抽象为对象和过程，使具象的事物概念化，易于理解，易于交流。
对象可以是系统、组件、接口、类、方法等等不同层次的概念，过程是系统运行的方式和流程。
2.复杂性
软件可以说是人类创造的最复杂的系统类，软件的各个模块之间有各种显性或隐性的依赖关系，随着系统的成长和模块的增多，这些关系的数量往往以几何级数的速度增长。
特别是现在流行的微服务架构，更需要解决服务之间的依赖性，所以，这个时候我们需要从更高的架构视角来解决以上这些问题。
软件架构的本质就是要管理复杂性。
3.交流性
软件架构会形成一套：设计文档，描述说明，流程图，架构图，这些会让复杂的软件系统以更易于理解和易于交流的方式展示。
有哪些软件架构
架构模式虽多，但常用的也就那么几种。
1.分层架构
分层架构，英文名layered architecture，是最常见的软件架构，也是事实上的软件标准架构。
分层架构将软件分成若干个水平层，每一层都有清晰的角色和分工，层与层之间通过接口通信。
分层架构，最常见的就是是四层结构，如下图所示：
第一层：表现层presentation：负责用户界面；
第二层：业务层business：负责实现业务逻辑；
第三层：持久层persistence：负责提供数据，比如：SQL 语句就放在这一层；
第四层：数据库database：负责保存数据，持久化重要的数据；
分层架构的优点
1）分工明确
不同技能的程序员可以分工，负责不同的层，天然适合大多数软件公司的组织架构。
2）降解系统复杂度
分层的核心目的还是为了降解系统复杂度，提高系统的健壮性和可维护性，这也就是为什么需要分层的原因。
分层架构的缺点
每一层都可以独立测试，其他层的接口通过模拟解决然而分层架构固然很好，但前提是分层合理。
扩展性差，增加需求必须依次扩展每一层，由于每一层内部是耦合的，扩展会很困难。
2.事件驱动架构
事件驱动架构，英文名Event Driven Architecture，是一个流行的分布式异步架构模式，可以用来设计规模很大的应用程序。
事件驱动架构是一种基于发布/订阅模式的消息异步通信的架构，你可以把它理解为架构层面的观察者模式。
事件驱动架构
通常，架构主要包含4种组件，如下图所示：
1）事件队列（event queue）
负责：接收事件的入口。
2）分发器（event mediator）
负责：将不同的事件分发到不同的业务逻辑单元。
是一个事件中枢处理单元，知道事件的处理流程，但不执行具体的事件业务处理逻辑，根据事件的特征对初始事件进行拆分编排为处理事件并进行分发。
3）事件通道（event channel）
负责：分发器与处理器之间的联系渠道。
是一组各自独立的组件，彼此之间没有依赖，自包含，不依赖于其他 Processor 的处理结果。
4）事件处理器（event processor）
负责：实现业务逻辑，处理完成后会发出事件，触发下一步操作。
事件驱动架构工作流程
第一步：客户端发送一个事件到事件队列event queues中，它用来将事件传送给event mediator；
第二步：Event mediator收到初始的事件后，会发送额外的一些异步事件给event channels来执行处理的每个步骤；
第三步：Event channels 既可以是消息队列，也可以是消息topic，大部分是消息topic，这样可以由多个消息处理器(event processor)处理同一个消息。
第四步：Event processors监听event channels,接收事件并处理一些业务逻辑。
事件驱动架构应用场景
典型的场景：比如在交易系统中，每个请求流程必须经过特定的步骤，如验证、订单、配送，以及通知买家等。
3.MVC架构
MVC架构是软件工程中的一种软件架构模式，它把软件系统分为三个基本的部分。
分别为：
- 模型Model
- 视图View
- 控制器Controller
主要为以上三大部分组成，如下图所示：
1.模型(Model)
模型封装了数据及对数据的操作，可以直接对数据库进行访问。
简要的讲：就是一个或多个javabean对象，用于存储数据和业务逻辑。
2.视图(View)
视图负责展示，没有具体的程序逻辑，比如：一个JSP页面想控制器提交数据和为模型提供数据显示，JSP页面主要使用HTML标记和JavaBean标记来显示数据。
3.控制器(Controller)
控制器用于控制程序的流程，将模型中的数据展示到视图中。
比如：Servlet对象根据视图提交的请求进行控制，即将请求转发给业务逻辑的javabean，并将处理记过存放到实体模型javabean中，输出给视图显示。
MVC架构优点
1）多个视图共享一个模型，大大提高代码的可重用性；
2）三个模块相互独立，改变其中一个不会影响其他两，所以依据这种设计模式，能构建良好的松耦合性的组件；
3）控制器提高了应用程序的灵活性和可控制性：控制器可以用来连接不同的模型和视图去完成用户的需求，这样控制器可以为构造应用程序提高强有力的手段。
MVC架构缺点
1）增加了系统结构和实现的复杂性
对于简单页面，严格遵循mvc，会增加结构的复杂性。
2）视图与控制器过于紧密的连接
视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的。
3）视图对模型数据的低效率访问
依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据，对未变化数据的不必要的频繁访问，也将损害操作性能。
3.微服务架构
最早一个系统业务量很小的时候，大部分Web工程的Java应用程序，打包为War包部署在一台服务器上。
比如：你正在构建一个在线商店系统，包含功能：用户、商品、下订单等功能，整体架构如下图所示：
随着业务访问量越来越大，单体应用就会出现巨大的瓶颈。
比如：
- 要修改一个地方就要将整个应用全部部署;
- 编译时间过长;
- 回归测试周期过长;
- 开发效率降低，因为所有业务都混在一起；
所以后期就会出现，按照业务为单位进行拆分，出现的微服务架构。
微服务优点
- 每个服务足够内聚，足够小，这样能聚焦一个指定的业务功能或业务需求；
- 开发效率提高，一个服务可能就是专一的只干一件事；
- 在开发阶段，或部署阶段都是独立的；
- 微服务能使用不同的语言开发；
- 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果；
- 每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库。
微服务缺点
- 分布式复杂性：在复杂程度上来说，微服务比单体建构要更为复杂些；
- 最终一致性：各个服务的团队，数据也是分散式治理，会出现不一致的问题；
- 运维复杂性：部署比单体项目复杂得多，运维更复杂；
- 测试复杂性：测试也会更复杂；
5.云架构
云架构，英文名cloud architecture，是指各项技术如何整合在一起以创建云，云是指能够抽象、汇集和共享整个网络中的可扩展资源的 IT 环境。
云被视为平台即服务（Pass），因为云提供商为用户提供了平台以及底层IT基础架构。
云架构主要解决扩展性和并发的问题，是最容易扩展的架构。
- 与传统的服务器相比，云平台可以将物理资源虚拟化为虚拟机资源池，灵活调用软硬件资源，实现对用户的按需访问；
- 而且在运行过程中根据用户并发量的不同，实时迁移虚拟机资源，一方面保证提供高质量的服务，另一方面最小化资源成本，提高CPU，内存等利用率；
这个模式主要分成两部分：
- 处理单元processing unit
- 虚拟中间件virtualized middleware
虚拟中间件又包含四个组件：
- 消息中间件（Messaging Grid）：管理用户请求和session，当一个请求进来以后，决定分配给哪一个处理单元；
- 数据中间件（Data Grid）：将数据复制到每一个处理单元，即数据同步。保证某个处理单元都得到同样的数据；
- 处理中间件（Processing Grid）：如果一个请求涉及不同类型的处理单元，该中间件负责协调处理单元；
- 部署中间件（Deployment Manager）：负责处理单元的启动和关闭，监控负载和响应时间，当负载增加，就新启动处理单元，负载减少，就关闭处理单
云架构的优点：
高负载，高扩展，动态部署。
云架构的缺点
1)实现复杂，成本较高；
2)数据隐私问题：由于隐私问题，一些法律法规以及一些公司政策不允许将数据存储在云环境中。
3)严重依赖互联网连接：通常云服务是通过互联网提供的，如果您处于互联网连接较差的地区，或者更糟糕的是，根本没有互联网，这可能是一个问题。
陈睿mikechen
10年+大厂架构经验，资深技术专家，就职于阿里巴巴、淘宝、百度等一线互联网大厂。
关注「mikechen」公众号，获取更多技术干货！
后台回复【面试】即可获取《史上最全阿里Java面试题总结》，后台回复【架构】，即可获取《阿里架构师进阶专题全部合集》