微服务是否使SOA变得无关紧要?

Rancher by SUSE

于 2017-05-16 13:25:42 发布

阅读量574

点赞数

文章标签： soa docker 架构微服务应用

本文链接：https://blog.csdn.net/RancherLabs/article/details/72267912

版权

服务导向架构（简称SOA，service-oriented architecture）已经死亡?你可能会这么想。

但其实不然。的确，随着新技术的出现，SOA本身的价值可能已经大不如前，但是SOA的遗产仍在推动微服务市场发展。

将SOA原则纳入微服务的设计和构建是确保您的产品或服务长期处于有利地位的最佳方式。从此意义上讲，理解SOA，对于在微服务世界中取得成功至关重要。

在本文中，我将解释设计微服务应用程序时应采用哪些SOA原则。

介绍

如今，在移动终端开发环境中，代码为王，构建具有RESTful界面的服务变得前所未有的容易，将其连接到数据存储就可以了。如果你想要更进一步，就把几个公共软件服务（免费或付费）整合在一起，这样你就可以拥有一个满足需求的持续交付流水线。欢迎来到现代Web和完全buzzworthy兼容的应用程序开发过程。

在许多方面，微服务是SOA的直接产物，有点像服务世界的朋克摇滚。没有严格的规则，只是一些基本原则让所有人保持大体想法一致。就像朋克摇滚，微服务最初信奉的是一种按自己的节奏来的行业伦理。此后微服务一直在不断发展，一些架构方式开始让微服务转变为主流。不光是使用微服务的dot com或Web公司——所有的公司都对此感兴趣。

定义

为体现本讨论的目的，以下是我将要使用的定义。

微服务：特定业务功能的实现，使用队列或RESTful（JSON）接口作为单独的可部署工件，可以用任何语言编写，并利用持续交付流水线。
SOA：基于组件的架构，其目标是在组织内部跨技术组合促进重用。这些组件需要松耦合，可以是集中管理的服务或库，并要求组织使用单个技术栈来最大限度地实现可重用性。

基于微服务的开发的优点

正如您所知，微服务具有SOA所缺乏的几个很好的特性：

允许规模较小、自给自足的团队拥有支持特定业务功能的产品/服务，这大大提高了他们渴望的业务敏捷性和IT响应能力。
自动构建和测试，虽然可能不及SOA，现在是关键的筹码。
允许团队使用他们想要的工具，主要围绕使用哪种语言和IDE。
以敏捷为基础的开发与直接访问业务。微服务和移动开发团队已经成功地向企业展示了技术人员如何适应并接受不断反馈的业务。以往，瀑布式软件交付方法受制于不必要的开销和交付日期延长的影响，随着业务的变化，开发团队一开始创建的产品，在交付时常常无法满足业务需求。甚至像Rational Unified Process（RUP）这样的迭代开发方法在业务、产品开发和开发人员进行实际工作之间都有抽象层。
对服务的最小粒度的普遍了解。关于“添加客户端业务功能还是客户端管理业务功能”的争论一直存在，这并不完美，但至少两者都可以被实际运营业务的业务方所了解。你可能不愿相信，但技术并不是所有业务（对于世界上大多数企业而言）。回溯到SOA还是行业霸主时期，一些服务只执行一个数据库操作，其他服务则在系统中添加客户端，当IT缺乏一致的标准，就会导致业务的混乱。

SOA如何助力？

看完这些定义后，你可能会想：“微服务听起来好得多”。的确，这正是未来发生演变的原因，只是它抛弃了许多在SOA世界中获得的经验教训。它放弃了SOA尝试实现的所有美好的事物，因为这一领域的IT供应商们为了推出更多的产品，而改变了一切。

企业集成模式（定义企业如何采用新技术或概念）是微服务利用SOA世界所做的工作的关键所在。每个参与整合空间的人都可以从这些模式中获益，然而它们只是概念，微服务是实现这些概念的一种很好的技术方法。

下面，我列出了微服务生态系统中应用SOA原理获得巨大成功的另外两个领域。

API网关（née ESB）

微服务鼓励点对点连接，每个客户端都可以按自己的方式处理日期和其他细微之处。由于大多数公司提供的微服务的数量急剧增加，这种方式不可持续。

因此，在SOA环境中，企业服务总线（ESB）旨在为不同应用程序提供通信方式。SOA原本打算将ESB用于服务组件之间进行传输—而不是整个企业的中心。厂商推动，大公司购买，人们对这种模式的评价十分糟糕。

ESB中成功的产品已经转变为今天的API网关供应商，便于单一组织集中管理它们所呈现的端点，并为那些多年来尚未触及但对业务至关重要的旧式服务 (通常是soa/soap) 提供转换服务。

首要标准

SOA具有WS- *标准。此标准虽然严厉，但在很大程度上保证了互用性。这些标准，特别是像WS-Security和WS-Federation这类更常见的标准，允许企业调用在其合作伙伴系统中使用的服务——虽然它们只是一个清单，任何人都能理解。

微服务已经开始形成一套正式标准，也带来了一票提供相应服务的供应商。OAuth和OpenID认证框架就是两个很好的例子。随着微服务的成熟，在内部构筑一切是有趣、充实、且对自身有益的，但最终令人沮丧的是，随着新特性的引入，它会产生大量的技术债务，代码不断地需要被修改。

标准正迅速整合的另一面是API设计和描述。在SOA世界中，有一种方法。对人而言它既没有美感，又几乎不可读，但是Web服务定义语言(WSDL)是一种通用的标准化的编目网络服务的格式。

截至2017年4月，所有主要的参与者（包括谷歌、IBM、Microsoft、MuleSoft和Salesforce.com)都参与了提供构建RESTful api的工具，这些都是OpenAPI倡议的成员。曾经那个有多个标准（JSON API、WASL、RAML和Swagger）的破碎市场，现在变成了可以用单一方式描述所有内容。