Microservice

微服务起源与SOA

SOA(Service-Oriented Architecture,面向服务的架构)是一种在计算机环境中设计、开发、部署和管理离散模型的方法。

SOA实现方法 [edit]

SOA作为一种架构设计的概念和思想,需要借助具体的技术和方法来实现。目前SOA的主流实现方法包括:

ESB(企业服务总线) [edit]

简单 来说 ESB 就是一根管道,用来连接各个服务节点。为了集 成不同系统,不同协议的服务,ESB 做了消息的转化解释和路由工作,让不同的服务互联互通;

SOA关键技术 [edit]

与SOA紧密相关的技术主要有UDDI、WSDL、SOAP和REST等,这些技术都是以XML为基础发展而来的。

SOAP [edit]

SOAP(Simple Object Acess Protocol,简单对象访问协议)定义了服务请求者和服务提供者之间的消息传输规范,该协议通过HTTP承载XML格式化的消息。通过SOAP,应用程序可以在网络中进行数据交换和远程过程调用(RPC)。SOAP主要包括封装、编码规则、RPC表示和绑定四个部分。

REST [edit]

REST(Representational State Transfer,表达性状态转移)是一种针对Web服务的设计和开发方式,通常使用HTTP、XML、URI和HTML等流行协议或标准,可以有效降低开发的复杂性,提高系统的可伸缩性。REST对信息的操作基本只支持POST、GET、PUT和DELETE,这些操作基于如下的设计理念:

SOA架构和微服务架构的区别 [edit]

首先SOA和微服务架构一个层面的东西,而对于ESB和微服务网关是一个层面的东西,一个谈到是架构风格和方法,一个谈的是实现工具或组件。

微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想

API网关 [edit]

API网关是一个服务器,是系统的唯一入口。从面向对象设计的角度看,它与外观模式类似。

API网关封装了系统内部架构,为每个客户端提供一个定制的API。它可能还具有其它职责,如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。API网关方式的核心要点是,所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能。通常,网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。

适用于的场景 [edit]

SOA 更加适合于庞大、复杂、异构的企业级系统,这也是 SOA 诞生的背景。这类系统的典型特征就是很多系统已经发展多年,采用不同的企业级技术,有的是内部开发的,有的是外部购买的,无法完全推倒重来或者进行大规模的优化和重构。因为成本和影响太大,只能采用兼容的方式进行处理,而承担兼容任务的就是 ESB。

微服务更加适合于快速、轻量级、基于 Web 的互联网系统,这类系统业务变化快,需要快速尝试、快速交付;同时基本都是基于 Web,虽然开发技术可能差异很大(例如,Java、C++、.NET 等),但对外接口基本都是提供 HTTP RESTful 风格的接口,无须考虑在接口层进行类似 SOA 的 ESB 那样的处理。

服务交付 [edit]

SOA 对服务的交付并没有特殊要求,因为 SOA 更多考虑的是兼容已有的系统;

微服务的架构理念要求“快速交付”,相应地要求采取自动化测试、持续集成、自动化部署等敏捷开发相关的最佳实践。

如果没有这些基础能力支撑,微服务规模一旦变大(例如,超过 20 个微服务),整体就难以达到快速交付的要求,这也是很多企业在实行微服务时踩过的一个明显的坑,就是系统拆分为微服务后,部署的成本呈指数上升。


Comment:



(画像の文字列を入力して下さい)

トップ   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS