![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#author("2022-12-20T16:42:44+08:00","default:Admin","Admin") #author("2022-12-20T16:42:54+08:00","default:Admin","Admin") [[Microservice]] #contents 微服务起源与SOA SOA（Service-Oriented Architecture，面向服务的架构）是一种在计算机环境中设计、开发、部署和管理离散模型的方法。 * SOA实现方法 [#qecbd051] SOA作为一种架构设计的概念和思想，需要借助具体的技术和方法来实现。目前SOA的主流实现方法包括： - Web Service - 服务注册表 - 企业服务总线。 ** ESB（企业服务总线） [#h1efec64] 简单 来说 ESB 就是一根管道，用来连接各个服务节点。为了集 成不同系统，不同协议的服务，ESB 做了消息的转化解释和路由工作，让不同的服务互联互通； &ref(SOA_架构.png); * SOA关键技术 [#u2733abc] 与SOA紧密相关的技术主要有UDDI、WSDL、SOAP和REST等，这些技术都是以XML为基础发展而来的。 ** SOAP [#h88b75bd] SOAP（Simple Object Acess Protocol，简单对象访问协议）定义了服务请求者和服务提供者之间的消息传输规范，该协议通过HTTP承载XML格式化的消息。通过SOAP，应用程序可以在网络中进行数据交换和远程过程调用(RPC）。SOAP主要包括封装、编码规则、RPC表示和绑定四个部分。 ** REST [#wd8a676b] REST（Representational State Transfer，表达性状态转移）是一种针对Web服务的设计和开发方式，通常使用HTTP、XML、URI和HTML等流行协议或标准，可以有效降低开发的复杂性，提高系统的可伸缩性。REST对信息的操作基本只支持POST、GET、PUT和DELETE，这些操作基于如下的设计理念： - 网络上的所有事物都被抽象为资源； - 每个资源对应一个唯一的资源标识； - 通过通用的连接件接口对资源进行操作； - 对资源的各种操作不会改变资源标识； - 所有操作都是无状态的。 * SOA架构和微服务架构的区别 [#u23478d2] 首先SOA和微服务架构一个层面的东西，而对于ESB和微服务网关是一个层面的东西，一个谈到是架构风格和方法，一个谈的是实现工具或组件。 - SOA“面向服务的架构”:他是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中。各个服务之间 通过网络调用。 - 微服务架构:其实和 SOA 架构类似,微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。 &color(red){微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想}; ** API网关 [#sde17aca] API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。 API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。 ** 适用于的场景 [#wc6769bb] SOA 更加适合于庞大、复杂、异构的企业级系统，这也是 SOA 诞生的背景。这类系统的典型特征就是很多系统已经发展多年，采用不同的企业级技术，有的是内部开发的，有的是外部购买的，无法完全推倒重来或者进行大规模的优化和重构。因为成本和影响太大，只能采用兼容的方式进行处理，而承担兼容任务的就是 ESB。 微服务更加适合于快速、轻量级、基于 Web 的互联网系统，这类系统业务变化快，需要快速尝试、快速交付；同时基本都是基于 Web，虽然开发技术可能差异很大（例如，Java、C++、.NET 等），但对外接口基本都是提供 HTTP RESTful 风格的接口，无须考虑在接口层进行类似 SOA 的 ESB 那样的处理。 ** 服务交付 [#fd6a46b0] SOA 对服务的交付并没有特殊要求，因为 SOA 更多考虑的是兼容已有的系统； 微服务的架构理念要求“快速交付”，相应地要求采取自动化测试、持续集成、自动化部署等敏捷开发相关的最佳实践。 如果没有这些基础能力支撑，微服务规模一旦变大（例如，超过 20 个微服务），整体就难以达到快速交付的要求，这也是很多企业在实行微服务时踩过的一个明显的坑，就是系统拆分为微服务后，部署的成本呈指数上升。 ** 总结 [#q4cfde8a] |功能|SOA|微服务|h |组件大小|大块业务逻辑|单独任务或小块业务逻辑| |耦合|通常松耦合|总是松耦合| |公司架构|任何类型|小型、专注于功能交叉团队| |管理|着重中央管理|着重分散管理| |目标|确保应用能够交互操作|执行新功能、快速拓展开发团队| #hr(); Comment： #comment_kcaptcha
