微服务和SOA:结合起来更完美


【编者的话】本文分析了企业内多种架构并存及整合的现实性和合理性,并分别简单分析了微服务和 SOA 架构的特点,指出二者可以形成完美的互补,以提高企业效率,减少 IT 成本。

尽管微服务不会替代面向服务的架构(SOA),但是二者在企业环境中可以互相补充。

整合是必要的

没有一个企业可以只用一种技术或一个系统就能满足所有计算需求。所有企业都需要由多种编程语言,多个供应商应用,多个合作系统,以及遗留应用来构成。

仅仅一种架构风格不能满足IT需求,因为我们通常需要处理遗留的各种离散技术,异构技术,不同的供应商系统,等等等等。最重要的是,每个系统都拥有不同的架构能力。

当一个新项目加入进来时,多数解决方案都会牵涉到评估系统中已存在的投入,服务种类,以及员工已具备的技能和经验集合。使用已存在的系统来设计方案是唯一可行的应用整合方式。

应用整合,用穆勒的话说,就是:


“企业内不同应用间的进程和数据共享。不论对大企业还是小企业,它已成为一个关键任务,去连接各种应用,评估跨企业的应用协作,以提升总体商业效率,增强可扩展性,以及减少IT成本。”
应用整合可以在三个层面进行:
  1. 用户接口整合(门户网站),尽管某些人可能会说这是个过期的整合风格,综合考虑应该推迟。
  2. 系统或服务整合
  3. 数据整合


软件架构

专家承认,没有一种架构是能满足所有企业的IT需求的。它依赖于你设计什么系统,以及它将在哪里使用。

一些著名的架构风格如下:
  • 层次架构
  • 事件驱动架构
  • 面向服务架构
  • 微服务架构
  • 基于服务的架构
  • 微内核架构


微服务和SOA

尽管了解所有架构模式很重要,但微服务架构在如今的分布式应用中引领潮流。

微服务对应用开发来说确实是一个考虑周密的架构模式,进一步的服务是通过 RESTful 接口暴露的。

ms.png

图1. 微服务架构图

微服务的部分特点是,它们不共享东西,有限界上下文(bounded context),使用 RESTful 服务接口,采用直接调用和 API 层调用,相比维护旧代码更偏好重写,以及独立部署。

这些特点中的一部分可理解成原子服务,没有分布式事务,无状态(因为它们通过 REST 暴露),不太确定的是微服务的合适大小,以及幂等性。

SOA 不止是 ESB 或者一个成熟的产品。SOA 是企业层面的架构风格,带来各种服务和系统的可视化,包括REST服务,SOAP服务,以及通过服务层的遗留应用等。

soa.png

图2. SOA 结构图

SOA 的特点是,它包含系统的互操作性,提供本地支持以整合、补充微服务和云,促进 IT 资产的重用,以及包含服务分类。

SOA 不会规定如何实现一个服务。这是留给每个服务设计者的事。因为 SOA 主要解决应用整合问题,所以它为大部分的整合需求而工作,如基于文件的整合,基于数据的整合,以及基于 web service(WS)的整合。这些在 SOA 中都可以通过 JCA,适配器等做到。

以下是摘自 Lucas Jellema 的 SOA 手册的涉及 SOA 的服务的一些本质特征:
  • 只要可能,服务都应该支持原子操作。
  • 服务应该无状态以使遗留足迹尽可能得小。
  • 服务应该保持幂等以允许重试而不产生副作用。
  • 服务应该大小适中。


现在,如果你稍微往回看一下,你会发现微服务的特点完美得匹配了 SOA 服务的服务定义。

SOA 架构下任意分类的服务都能被微服务具体化。或许那就是为什么每个人都说:"微服务即 SOA 使用得当!"那些做预算和项目支出的,难道你不同意企业级的任何服务都是可重用的吗?

总结一下,微服务不会替代 SOA,但是它们可以在大企业内和 SOA 形成非常完美的互补。

原文链接:Microservices and SOA: Better Together(翻译:池剑锋)

0 个评论

要回复文章请先登录注册