在上一篇《微服务架构设计模式》读书笔记（一）：逃离单体地狱》中我们对比了单体架构和微服务架构的优缺点，已经实施微服务的组织和流程条件，同时也给出了微服务的概括性定义：把应用程序功能性分解为一组服务的架构风格。在本篇中，我们将继续深入微服务架构设计。

软件架构的重要性

软件架构定义

计算机系统的软件架构是构建这个系统所需要的一组结构，包括软件元素、它们之间的关系以及两者的属性。

——《Documenting Software Architectures: Views and Beyond》

软件的架构是一种抽象的架构，由软件的各个组成部分和这些部分之间的依赖关系构成。

软件需求可以分为两类：

功能需求：决定软件可以做什么

非功能需求：非功能需求也称为质量需求或者能力，包含开发阶段的质量、后续的可维护性、可测试性、可扩展性、可以部署性等质量属性

以上描述其实和《从零开始学架构》读书笔记（一）：概念与基础中讲述的软件架构的定义（顶层结构）和解决复杂性（为了实现高性能、高可用、可扩展、安全等）的理解很类似。

架构的重要性在于：决定应用程序的质量属性。

架构的4 1视图模型

逻辑视图：开发人员创建的软件元素及关系

实现视图：编译构建系统的输出，模块、组件及关系

进程视图：运行时的组件及关系

部署视图：进程如何映射到机器，由机器、进程及关系构成

分层式架构

分层式架构将软件运算按“层”的方式组织，每层都有明确定义的职责，每层只能依赖紧邻的下层。

可以将分层架构应用于前面所述四种视图中任何一种，流行的三层架构是应用于逻辑视图的MVC架构：

表现层：包含实现用户界面或外部API的代码业务逻辑层：包含业务逻辑数据持久层：实现与数据库交互的逻辑

其弊端是：

单个表现层：无法展现应用程序可能不仅仅由单个系统调用的事实单一数据持久化层：无法展示应用程序可能与多个数据库进行交互的事实将业务逻辑层定义为依赖于数据持久化层：理论上，这样的依赖会妨碍在没有数据库的情况下测试业务逻辑六边形架构

六边形架构是分层架构风格的替代品 [解决分层架构的弊端]，六边形架构选择以业务逻辑为中心的方式组织逻辑视图。

业务逻辑周围是适配器，有两种适配器：

入站适配器：通过调用入站端口处理外部请求（如Spring MVC Controller，实现REST接口或一组Web界面）出站适配器：通过调用外部应用程序或服务处理来自业务逻辑的请求（如实现数据访问对象DAO类）

好处：

将业务逻辑与适配器中包含的表示层和数据访问层的逻辑分离开，使单独测试业务逻辑容易反映现代应用程序的架构微服务架构

微服务架构是一种把应用程序功能性分解为一组服务的架构风格。

服务是一个单一的、可独立部署的软件组件，它实现了一些有用的功能。

服务的API封装了其内部实现服务之间交互使用API完成服务用于实现可能会更改的通用的功能服务的代码规模不一定小，但通常职责范围小

微服务架构把应用程序通过一些小的、松耦合的服务组织在一起，能提升开发、测试、维护、部署的效率，让组织的软件开发速度更快，同时提升可扩展性。

总结架构决定了软件的各种非功能性因素，比如可维护性、可测试性、可部署性和可扩展性，它们会直接影响开发速度。微服务架构是一种架构风格，它给应用程序带来了更高的可维护性、可测试性、可部署性和可扩展性。,