【系统架构设计】软件架构设计（2）
【系统架构设计】软件架构设计（1）
- 软件架构概述
- 架构需求与软件质量属性
- 软件架构风格
- 层次系统架构风格
- 面向服务的架构
- SOA概述
- 微服务
- 微服务和SOA差异
软件架构概述
架构需求与软件质量属性
软件架构风格
层次系统架构风格
面向服务的架构
SOA概述
面向服务的架构（Service -Oriented Architecture ,SOA），与SOA 紧密相关的技术有UDDI、WSDL、SOAP、REST等，而这些技术都是以XML为基础而发展起来的。
- UDDI（Universal Description Discovery and Integration ,统一描述、发现和集成）
提供了一种服务发现、查找和定位的方法，是服务的信息注册规范，以便被需要该服务的用户发现和使用它。UDDI规范描述了服务的概念，同时也定义了一种编程接口。通过UDDI提供的标准接口，企业可以发布自己的服务供其他企业查询和调用，也可以查询特定服务的描述信息，并动态绑定到该服务上。
ps：UDDI 有点类似微服务的Nacos，服务注册中心，但要注意 服务提供者、服务请求者、服务注册中心里面服务注册中心为可选项，可以直接使用静态绑定的服务，服务提供者则可以把描述直接发送给服务请求者。
- WSDL（Web Service Description Language ,Web服务描述语言）
是对服务进行描述的语言，它有一套XML的语法定义。WSDL描述的重点是服务，它包含服务实现定义和服务接口定义。
- SOAP(Simple ObjectAccess Protocol ,简单对象访问协议)
定义了服务请求者和服务提供者之间的消息传输规范。SOAP用XML来格式化消息，用HTTP来承载消息。通过SOAP应用程序可以在网络中进行数据交换和远程过程调用（Remote Procedure Call，RPC）。主要包括** 封装、编码规则、RPC、绑定四个部分。SOAP消息基本上是从发送端到接收端的单向传输**，但它们常常结合起来执行类似于请求/应答的模式。而且所有的SOAP消息都用XML进行编码。
- REST(Representation State Transfer , 表达式状态转移)
是一种只使用HTTP 和XML进行基于Web通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。它的简单性和缺少严格配置文件的特性，使得它与SOAP很好隔离开来，从根本上来说只支持几个操作（POST \GET \ PUT \ DELETE），这些操作适用于所有的信息。REST提出了如下的一些设计概念和准则：
- 网络上的所有事情都被抽象为资源
- 每个资源对应一个唯一的资源标识
- 通过通用的连接件接口对资源进行操作
- 对资源的各种操作都不会改变资源标识
- 所有的操作都是无状态的
ps：操作无状态意味着在当前的操作中，不需要依赖或参考任何历史信息或数据。这种操作通常支持短连接，比如浏览新闻网站上的新闻，一旦从服务器获取资源后，就可以与服务器断开连接，因为当前的操作不需要历史数据的支持。简单来说，无状态操作就像是服务器对于每个请求都视为第一次请求，不会依赖之前的请求数据，每次请求都是独立的，服务器不会保存任何与请求方相关的状态数据
微服务
微服务的核心特点为：小，且专注于做一件事情、轻量级的通信机制、松耦合、独立部署
ps :轻量级通信机制中的轻量级主要指的是通信协议与语言无关、与平台无关，且创建和销毁不需要消耗太多的资源，可以在程序中经常创建和销毁session的对象。
微服务的优势：
- 技术异构性
在微服务架构中，每个服务都是一个相对独立的个体，每个服务都可以选择适合于自身的技术来实现。同时，在应用新技术时，微服务架构也提供了更好的试验场。因为对于单块的系统而言，采用一个新的语言、数据库或者框架都会对整个系统产生巨大的影响，这样导致我们想尝试新技术时，望而却步。但微服务不同，我们完全可以只在一个微服务中采用新技术， 待
技术使用熟练之后，再推广到其他服务。
- 弹性
弹性主要讲的是系统中一部分出现故障会引起多大问题。在单块系统中，一个部分出现问题，可能导致整体系统的问题。而微服务架构中，每个服务可以内置可用性的解决方案与功能降级方案，所以比单块系统强。
- 扩展
- 简化部署
在大型单块系统中，即使修改一行代码，也需要重新部署整个应用系统。这种部署的影响很大、风险很高，因此不敢轻易地重新部署。而微服务架构中，每个服务的部署都是独立的，这样就可以更快地对特定部分的代码进行部署。
- 与结织组织相匹配
我们都知道，团队越大越难管理，同时团队越大也代表系统规模越大代码库越大，这样容易引起一系列的问题。且当团队是分布式的时候，问题更严重。微服务作为独立的个体，可以根据组织情况，灵活进行代码库部署，以及设置服务所有权。
- 可组合性
在微服务架构中，系统会开放很多接口供外部使用。当情况发生改变时，可以使用不同的方式构建应用，而整体化应用程序只能提供一个非常粗粒度的接口供外部使用。
- 对可替代性的优化
在单块系统中如果删除系统中的上百行代码，也许不知道会发生什么，引起什么样的问题，因为单块系统中关联性很强。但在微服务架构中，我们可以在需要时轻易地重写服务，或者删除不再使用的服务。
面临的挑战：
- 分布式系统的复杂度
- 运维成本
- 部署自动化
对于微服务架构而言，每个服务都是一个独立可部署的业务单元，每个服务的修改都需要独立部署。这样部署的成本是比较高的，如亚马逊，每天都要执行数十次、甚至上百次的部署，此时仍用人工部署是行不通的，要使用自动化部署。如何有效地构建自动化部署流水线，降低部署成本、提高部署频率，是微服务架构下需要面临的一个挑战。
- DevOps 与组织结构
微服务不仅表现出一种架构模型，同样也表现出一种组织模型。这种新型的组织模型意味着开发人员和运维的角色发生了变化，开发者将承担起服务整个生命周期的责任，包括部署和监控，而运维也越来越多地表现出一种顾问式的角色，尽早考虑服务如何部署。因此，如何在微服务的实施中，按需调整组织架构，构建全功能的团队，是一个不小的挑战。
-
服务间依赖测试
-
服务间依赖管理
微服务和SOA差异
微服务可以讲也是SOA的一种，但依旧有差异，主要表现在以下方面：
对应的在实现方面也存在差异
ps： 简单说，微服务是比较细化的，一个开发团队就是一个公司的业务；SOA 则是笼统的，然后一个开发团队是一个公司的部门。