个人总结，仅供参考，欢迎加好友一起讨论
架构 - 软件架构设计＜SOA与微服务＞
考点摘要
- 面向服务SOA（★★★★）
- 微服务（★★★★）
基于/面向服务的（SOA）
在SOA模型中，所有的功能都定义成了独立的服务。服务之间通过交互和协调完成业务的整体逻辑。所有的服务通过服务总线或流程管理器来连接。这种松散耦合的架构使得各服务在交互过程中无需考虑双方的内部实现细节，以及部署在什么平台上。
服务接口：共同的封装，共同的语言格式，共同的安全和容错处理，其标准高度的统一。统一标准下产生的构件是可以通用的。服务相关的协议都是基于XML发展而来的。遗留系统的集成，信息孤岛的联通这些问题都可以使用SOA来应用。比如可以把遗留系统作为一个个的服务挂接到总线，这样就可以重复利用起来了。松散耦合，粗粒度和标准化的接口都是服务的特点。
SOA特点
- 服务构件粗粒度，传统构件细粒度居多
- 服务构件的接口是标准的，主要是WSDL接口，传统构件常以具体API形式出现
- 服务构件的实现与语言无关，传统构件绑定某种特定语言
- 服务构件可以通过构件容器提供QoS的服务，传统构件完全由程序代码直接控制
Web Service
在Web Service（Web服务）的解决方案中，一共有三种工作角色，其中服务提供者和服务请求者是必须的，服务注册中心是一个可选的角色。它们之间的交互和操作构成了SOA的一种实现架构，如下图：
-
服务提供者
服务提供者是服务的所有者，该角色负责定义并实现服务，使用WSDL对服务进行详细、准确、规范的描述，并将该描述发布到服务注册中心，供服务请求者查找并绑定使用。
-
服务请求者
服务请求者是服务的使用者，虽然服务面向的是程序，但程序的最终使用者仍然是用户。从架构的角度看，服务请求者是查找、绑定并调用服务，或与服务进行交互的应用程序。服务请求者角色可以由浏览器来担当，由人或程序（例如，另外一个服务）来控制。
-
服务注册中心
服务注册中心是连接服务提供者和服务请求者的纽带，服务提供者在此发布他们的服务描述，而服务请求者在服务注册中心查找他们需要的服务。不过，在某些情况下，服务注册中心是整个模型中的可选角色。例如，如果使用静态绑定的服务，服务提供者则可以把描述直接发送给服务请求者。
Web Services的特征：
- Web Services是应用程序服务组件Web Services使用开放协议进行通信
- Web Services是独立的 (self-contained）并可自我描述
- Web Services可通过使用UDDI来发现
- Web Services可被其他应用程序使用
- XML是Web Services的基础（其实目前更多使用的是JSON）
- 业务方若想使用某个WebService的服务，什么都不用耦合，只需要记住UDDI在哪儿，用的时候现场查询、现场使用即可。
表述性状态转移REST
REST（Representational State Transfer，表述性状态转移）是一种通常使用HTTP和XML进行基于Web通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。
REST的5个原则：
- 网络上的所有事物都被抽象为资源。
- 每个资源对应一个唯一的资源标识。
- 通过通用的连接件接口对资源进行操作。
- 对资源的各种操作不会改变资源标识。
- 所有的操作都是无状态的。
SOA实现方式
服务注册表
服务注册表（service registry）虽然也具有运行时的功能，但主要在SOA设计时使用。它提供一个策略执行点（Policy Enforcement Point，PEP），在这个点上，服务可以在SOA中注册，从而可以被发现和使用。服务注册表可以包括有关服务和相关构件的配置、依从性和约束文件。从理论上来说，任何帮助服务注册、发现和查找服务合约、元数据和策略的信息库、数据库、目录或其他节点都可以被认为是一个注册表。大多数商用服务注册产品支持服务注册、服务位置和服务绑定功能。
企业服务总线ESB
企业服务总线是一个具有标准接口、实现了互连、通信、服务路由，支持实现SOA(Service Oriented Architecture，面向服务架构)的企业级信息系统基础平台。它提供消息驱动、事件驱动和文本导向的处理模式，支持基于内容的服务路由。SOA架构将各应用服务器(包括异构的服务器)上的各种服务连接到服务总线上，支持分布式的存储及分布式的处理、异步处理。为信息系统的真正松耦合提供了架构保障。简化了企业整个信息系统的复杂性，提高了信息系统架构的灵活性，降低企业内部信息共享的成本。
ESB的作用：
- 是SOA的一种实现方式，ESB在面向服务的架构中起到的是总线作用，将各种服务进行连接与整合。
- 描述服务的元数据和服务注册管理
- 在服务请求者和提供者之间传递数据，以及对这些数据进行转换的能力，并支持由实践中总结出来的一些模式如同步模式、异步模式等。
- 发现、路由、匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求者和服务提供者。高级一些的能力，包括对安全的支持、服务质量保证、可管理性和负载平衡等。
SOA的关键技术
| 功能 | 技术协议 |
|---|---|
| 发现服务 | UDDI、DISCO |
| 描述服务 | WSDL、XML Schema |
| 消息格式层 | SOAP、REST |
| 编码格式层 | XML（DOM、SAX） |
| 传输协议层 | HTTP、TCP/IP、SMTP等 |
UDDI（Universal Description Discovery and Integration，统一描述、发现和集成）提供了一种服务发布、查找和定位的方法，是服务的信息注册规范，以便被需要该服务的用户发现和使用它。UDDI规范描述了服务的概念，同时也定义了一种编程接口。通过UDDI提供的标准接口，企业可以发布自己的服务供其他企业查询和调用，也可以查询特定服务的描述信息，并动态绑定到该服务上。
WSDL（Web Service Description Language，Web服务描述语言）是对服务进行描述的语言，它有一套基于XML的语法定义。WSDL描述的重点是服务，它包含服务实现定义和服务接口定义。WSDL就是WebService接口对应的WSDL文件，该文件通过XML格式说明如何调用，可以看作WebService的接口文档（使用说明书）。
SOAP（Simple Object Access Protocol，简单对象访问协议）定义了服务请求者和服务提供者之间的消息传输规范。SOAP用XML来格式化消息，用HTTP来承载消息。通过SOAP，应用程序可以在网络中进行数据交换和远程过程调用（Remote Procedure Call，RPC）。
REST（Representational State Transfer，表述性状态转移）是一种只使用HTTP和XML进行基于Web通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。它的简单性和缺少严格配置文件的特性，使它与SOAP很好地隔离开来。
SOA vs SOAP
SOA指的是架构方法及流程，WebService（服务提供者）、UDDI（注册中心）、业务方（调用方、消费者）三者的地位、作用以及需要遵从的执行流程：WebService将自己的wsdl注册给UDDI，业务方先从UDDI获取到wsdl，进而才能访问WebService。
SOAP指的是SOA的三个组件互相访问时遵从的网络协议，即：用http请求承载，xml为组织格式，来传递输入输出的有约束的数据（例如必须有envelop、bind、soap:body等元素）。
微服务
首先，微服务也是属于面向服务的架构。
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP协议的RESTfulAPI)。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。
微服务是一种架构风格，将单体应用划分成一组小的服务，服务之间相互协作，实现业务功能每个服务运行在独立的进程中，服务间采用轻量级的通信机制协作（通常是HTTP/JSON），每个服务围绕业务能力进行构建，并且能够通过自动化机制独立地部署。
与单体架构的对比
特点与缺点
微服务的特点及优点：
| 优点 | 解析 |
|---|---|
| 复杂应用解耦 | 小服务【且专注于做一件事情】 化整为零，易于小团队开发 轻量级的通信机制 |
| 独立 | 独立测试 独立开发 独立部署【简单部署】 独立运行【每个服务独立在其独立进程中】 层次结构（Layered System） |
| 技术选型灵活 | 支持异构【如每个服务使用不同数据库】 |
| 容错 | 故障被隔离在单个服务中，通过重试、平稳退化等机制实现应用层容错 |
| 松耦合，易扩展 | 可根据需求独立扩展 |
微服务的缺点与挑战：
- 分布式环境下的数据一致性【更复杂】
- 测试的复杂性【服务间依赖测试】
- 管理的多样性【服务间依赖管理】
- 运维的复杂性，运维成本增加
- 部署自动化
- DevOps与组织结构
再次强调：
微服务有以下优势：
- 通过分解巨大单体式应用为多个服务方法解决了复杂性问题。它把庞大的单一模块应用分解为一系列的服务，同时保持总体功能不变，但整体并发却得到极大提升。
- 让每个服务能够独立开发，开发者能够自由选择可行的技术，提供API服务。
- 微服务架构模式是每个微服务独立的部署。开发者不再需要协调其他服务部署对本服务的影响。这种改变可以加快部署速度。
- 微服务使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的规模。甚至可以使用更适合于服务资源需求的硬件。
微服务架构带来的挑战如下：文章来源：https://www.toymoban.com/news/detail-705583.html
- 并非所有的系统都能转成微服务。
- 部署较以往架构更加复杂：系统由众多微服务搭建，每个微服务需要单独部署，从而增加部署的复杂度，容器技术能够解决这一问题。
- 性能问题：由于微服务注重独立性，互相通信时只能通过标准接口，可能产生延迟或调用出错。
- 数据一致性问题：作为分布式部署的微服务，在保持数据一致性方面需要比传统架构更加困难。
微服务架构模式方案
文章来源地址https://www.toymoban.com/news/detail-705583.html
微服务与SOA的对比
| 微服务 | SOA |
|---|---|
| 能拆分的就拆分 | 是整体的，服务能放一起的都放一起 |
| 纵向业务划分 | 是水平分多层 |
| 由单一组织负责 | 按层级划分不同部门的组织负责 |
| 细粒度 | 粗粒度 |
| 团队级，自底向上开展实施 | 企业级，自顶向下开展实施 |
| 一个系统被拆分成多个服务，粒度细 | 服务由多个子系统组成，粒度大 |
| 无集中式总线，松散的服务架构 | 企业服务总线，集中式的服务架构 |
| 集成方式简单（HTTP/REST/JSON） | 集成方式复杂（ESB/WS/SOAP） |
| 服务能独立部署 | 单块架构系统，相互依赖，部署复杂 |
到了这里，关于【新版】系统架构设计师 - 软件架构设计＜SOA与微服务＞的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
