软件架构概述

架构需求与软件质量属性

软件架构风格

层次系统架构风格

面向服务的架构

SOA概述

面向服务的架构（Service -Oriented Architecture ,SOA），与SOA 紧密相关的技术有UDDI、WSDL、SOAP、REST等，而这些技术都是以XML为基础而发展起来的。

1. UDDI（Universal Description Discovery and Integration ,统一描述、发现和集成）

提供了一种服务发现、查找和定位的方法，是服务的信息注册规范，以便被需要该服务的用户发现和使用它。UDDI规范描述了服务的概念，同时也定义了一种编程接口。通过UDDI提供的标准接口，企业可以发布自己的服务供其他企业查询和调用，也可以查询特定服务的描述信息，并动态绑定到该服务上。

ps：UDDI 有点类似微服务的Nacos，服务注册中心，但要注意 服务提供者、服务请求者、服务注册中心里面服务注册中心为可选项，可以直接使用静态绑定的服务，服务提供者则可以把描述直接发送给服务请求者。

2. WSDL（Web Service Description Language ,Web服务描述语言）

是对服务进行描述的语言，它有一套XML的语法定义。WSDL描述的重点是服务，它包含服务实现定义和服务接口定义。

3. SOAP(Simple ObjectAccess Protocol ,简单对象访问协议)

定义了服务请求者和服务提供者之间的消息传输规范。SOAP用XML来格式化消息，用HTTP来承载消息。通过SOAP应用程序可以在网络中进行数据交换和远程过程调用（Remote Procedure Call，RPC）。主要包括** 封装、编码规则、RPC、绑定四个部分。SOAP消息基本上是从发送端到接收端的单向传输**，但它们常常结合起来执行类似于请求/应答的模式。而且所有的SOAP消息都用XML进行编码。

4. REST(Representation State Transfer , 表达式状态转移)

是一种只使用HTTP 和XML进行基于Web通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。它的简单性和缺少严格配置文件的特性，使得它与SOAP很好隔离开来，从根本上来说只支持几个操作（POST \GET \ PUT \ DELETE），这些操作适用于所有的信息。REST提出了如下的一些设计概念和准则：

• 网络上的所有事情都被抽象为资源
• 每个资源对应一个唯一的资源标识
• 通过通用的连接件接口对资源进行操作
• 对资源的各种操作都不会改变资源标识
• 所有的操作都是无状态的

ps：操作无状态‌意味着在当前的操作中，不需要依赖或参考任何历史信息或数据。这种操作通常支持短连接，比如浏览新闻网站上的新闻，一旦从服务器获取资源后，就可以与服务器断开连接，因为当前的操作不需要历史数据的支持。简单来说，无状态操作就像是服务器对于每个请求都视为第一次请求，不会依赖之前的请求数据，每次请求都是独立的，服务器不会保存任何与请求方相关的状态数据‌

微服务

微服务的核心特点为：小，且专注于做一件事情、轻量级的通信机制、松耦合、独立部署

ps :‌轻量级通信机制中的轻量级主要指的是通信协议与语言无关、与平台无关，且创建和销毁不需要消耗太多的资源，可以在程序中经常创建和销毁session的对象。

微服务的优势：

1. 技术异构性

在微服务架构中，每个服务都是一个相对独立的个体，每个服务都可以选择适合于自身的技术来实现。同时，在应用新技术时，微服务架构也提供了更好的试验场。因为对于单块的系统而言，采用一个新的语言、数据库或者框架都会对整个系统产生巨大的影响，这样导致我们想尝试新技术时，望而却步。但微服务不同，我们完全可以只在一个微服务中采用新技术， 待
技术使用熟练之后，再推广到其他服务。

2. 弹性

弹性主要讲的是系统中一部分出现故障会引起多大问题。在单块系统中，一个部分出现问题，可能导致整体系统的问题。而微服务架构中，每个服务可以内置可用性的解决方案与功能降级方案，所以比单块系统强。

3. 扩展
4. 简化部署

在大型单块系统中，即使修改一行代码，也需要重新部署整个应用系统。这种部署的影响很大、风险很高，因此不敢轻易地重新部署。而微服务架构中，每个服务的部署都是独立的，这样就可以更快地对特定部分的代码进行部署。

5. 与结织组织相匹配

我们都知道，团队越大越难管理，同时团队越大也代表系统规模越大代码库越大，这样容易引起一系列的问题。且当团队是分布式的时候，问题更严重。微服务作为独立的个体，可以根据组织情况，灵活进行代码库部署，以及设置服务所有权。

6. 可组合性

在微服务架构中，系统会开放很多接口供外部使用。当情况发生改变时，可以使用不同的方式构建应用，而整体化应用程序只能提供一个非常粗粒度的接口供外部使用。

7. 对可替代性的优化

在单块系统中如果删除系统中的上百行代码，也许不知道会发生什么，引起什么样的问题，因为单块系统中关联性很强。但在微服务架构中，我们可以在需要时轻易地重写服务，或者删除不再使用的服务。

面临的挑战：

1. 分布式系统的复杂度
2. 运维成本
3. 部署自动化

对于微服务架构而言，每个服务都是一个独立可部署的业务单元，每个服务的修改都需要独立部署。这样部署的成本是比较高的，如亚马逊，每天都要执行数十次、甚至上百次的部署，此时仍用人工部署是行不通的，要使用自动化部署。如何有效地构建自动化部署流水线，降低部署成本、提高部署频率，是微服务架构下需要面临的一个挑战。

4. DevOps 与组织结构

微服务不仅表现出一种架构模型，同样也表现出一种组织模型。这种新型的组织模型意味着开发人员和运维的角色发生了变化，开发者将承担起服务整个生命周期的责任，包括部署和监控，而运维也越来越多地表现出一种顾问式的角色，尽早考虑服务如何部署。因此，如何在微服务的实施中，按需调整组织架构，构建全功能的团队，是一个不小的挑战。

5. 服务间依赖测试

6. 服务间依赖管理

微服务和SOA差异

微服务可以讲也是SOA的一种，但依旧有差异，主要表现在以下方面：

对应的在实现方面也存在差异

ps： 简单说，微服务是比较细化的，一个开发团队就是一个公司的业务；SOA 则是笼统的，然后一个开发团队是一个公司的部门。