微服务与SOA实践

微服务与SOA实践

对于什么是微服务，什么是面向服务的体系结构以及它们如何相互关联存在很多混淆。从马丁福勒到史蒂夫琼斯的每个人都在关注这个问题。

什么是微服务？

微服务是一种架构设计模式。在微服务体系结构中，业务逻辑被分解成一系列小型，松耦合的分布式组件，这些分布式组件共同形成更大的应用程序。其中的组件被称为微服务，每个微服务在整体上执行单个任务或功能。每个微服务可以被一个或多个其他微服务调用来执行更大应用程序所需的特定任务; 这提供了一种统一的方式来处理诸如搜索或显示图像或其他可能需要多次执行的任务，并且限制了在应用程序内的不同位置开发或维护同一位功能的多个版本的需要。

使用微服务架构还提供了一种机制来提高新开发人员的生产力并缩短新功能的发布时间。每个微服务都有一个有限的代码库和相关联的工具集; 开发人员不再需要在变得富有成效之前了解庞大复杂的系统，他们只需要了解与他们所从事的微服务相关的子集。微服务可以快速开发，因为他们可以使用最适合当前任务的语言和工具集，而不用担心应用程序中现有部分已经使用或者大系统中的其他开发人员是否掌握这些语言和工具。

为了充分利用小团队速度优势进入市场，团队需要自主权; 他们必须能够快速做出决定，而且没有太多的疏漏。为了保证这一点，工作团队应该包括使产品能够通过和发布操作的所有相关人员。因为微服务组件是松耦合的并且通过API进行通信，所以大多数决策的高度自治且不会影响整个应用程序的功能。只要微服务发布API并执行发布API的功能，整个系统就能正常运行。

由于微服务架构中有许多独立组件，因此在大多数情况下，在公共或私有云等弹性网络上使用现代DevOps，对于确保整个系统的平稳运行非常重要。特别是在很多情况下，自动监控运行状况和负载，以及其他实例的自动部署（包含较少扩展未充分使用情况下的实例的缩减）变得至关重要。

什么是SOA？

SOA或面向服务的体系结构，是一种将多个较大的组件（通常是应用程序）集成在一起以形成可互操作的套件的机制。每个组件一般来说会从头到尾执行完整的业务逻辑，通常涉及完成整个更大操作所需的各种特定任务和功能。尽管SOA体系结构模式并不强制要求，组件通常都是松耦合的。

虽然SOA并不是一个严格的要求，但是SOA通常使用某种类型的集中管理 —— 审查委员会，首席架构师或架构委员会 —— 来严格定义系统的每个组件应该做什么以及应该如何执行。如果需要的话，可以在每个组件中分别定义和编写相同类型的功能，并且组件使用的语言和工具集是否集中确定和统一均可。SOA可以使用任何类型的SDLC，组织结构或与此类管理相一致的开发模型; 敏捷，瀑布，kanban或其他模板都是可以的，且不违反SOA原则。

此外，虽然现代DevOps和云部署对SOA来说当然是有帮助的，但鉴于此类系统中使用的组件数量较少，因此也不是必需要使用。但是，这些系统中的一些较大的组件可能非常复杂，以至于自动化是最困难的，并且在最坏的情况下显得完全不切实际。

例如，一个自动化部署的标准可能是通过一套100％的自动化测试。从而确保了现有功能在新版本中仍然有效，且新功能按预期工作。但随着越来越多的功能相互作用，可能会经常无意间破环功能的完整性从而使得开发工作增多。

此外，由于环境或网络问题，一些测试可能会变得不稳定，有些时候甚至会失败。当有一百个测试时，有5％的测试随机失败，1％ 的非严重故障。当有成千上万的测试时，相同的百分比会产生更大的影响，导致至少有一个随机失败的时间很长。因此，即使发布候选内容没有任何问题，也可能无法通过标准化测试。

直接比较 - 建立购物车

让我们看看一个在线购物网站。这个网站有几个不同的功能 —— 产品目录，用户帐户和购物车等等。

一个使用SOA的开发团队通常会将购物网站分解成主要的业务逻辑集合，并将它们作为单独的应用程序集成在一起。

例如，整个购物车及其所有功能都是由大量人员开发的一个应用程序，他们都需要知道整个购物车如何工作才能对其进行修改。在该应用程序中，代码可用于执行诸如显示项目，添加和删除购物车中的物品，查看库存，处理运输选项，处理税务计算，处理账单，更改显示内容，以及将最终订单详细信息发送给用户（除其他事项外）。其中一个场景：用于在购物车内显示产品的代码在购物车应用程序内，可能与用于在浏览目录视图内显示产品项目的代码完全不同，导致需要两组类似但不同的代码来维护，并且可能还有一些更大的应用程序用户体验中的不一致。

使用微服务架构的组织会把这个购物车分解成更小的面向任务的服务。替代购物车应用程序的可能会是税务计算服务，添加/删除项目服务，送货服务，结算服务和组成最终订单服务。购物车功能还可以使用在购物应用程序内的多个场景使用的一些常用服务，诸如显示项目服务，显示产品图像服务，支票库存服务，用户支付偏好服务和电子邮件服务 —— 在那里在“购物车”与“产品目录”与“用户帐户”之间没有界限，通用代码被封装到各种服务中，并按需被所有功能调用。

在某个时候，贵公司决定许可“中心许可组织”的产品图像。必须更改图像的来源并将视图周围的统计信息添加到较大的购物应用程序中。在SOA架构中，产品目录应用程序和购物车应用程序必须独立更新以响应这些更改。

然后，这两个应用程序需要重新测试以确保所做的更改不会影响任何其他功能，然后重新部署，如果其中一个应用程序或两个应用程序中的其他功能位于该应用程序中，该进程可能会进一步延迟（取决于所采用的开发流程）被修改过程并不处于可释放状态。重新部署后，显然服务图像的新机制比旧的机制慢，而成为瓶颈。

客户投诉发现这种放缓并向管理层报告。有人决定通过部署整个产品目录应用程序和购物车的其他实例来处理额外负载（如果适当的监控和部署规则已经实现，可以自动实现）。整个过程需要大量额外的处理能力和存储空间，因为整个应用程序需要扩大规模，其中包括许多功能，如果没有额外的部署，这些功能可能运行良好。

而在微服务领域，只需要进行一项更改 —— 即显示产品映像服务的更新。该服务可以自行快速修改，测试和部署，而不会影响较大系统的任何其他部分。此外，当发现瓶颈时（很可能通过自动监控发现），可以部署（可能自动部署）此服务的其他实例，而不必部署产品目录功能或购物车服务所使用的其余服务的更多实例，支持增加部署所需的额外资源。

以上所有假设存在于你试图推出一个更大的网上商店，销售各种产品给不同地点的各种人。假设您只想向美国大陆的客户仅使用UPS作为唯一的托运人出售一种产品。许多真正的在线商店所需的基础设施和复杂性并不是必要的。

但是，您仍然需要跟踪用户信息，提供购物车和结账功能，并且有一个包含产品信息，图像的页面，甚至可能包含一些评论或推荐信息，但其中的每一个都需要比其他同行更少的功能网上商城。消费者需要对产品进行分类，需要找出不同的送货选项，需要处理添加和删除系统偏差以及完整多产品商店需要的各种其他功能。

在这种情况下，将SOA与购物车，用户帐户和产品展示组件集成到网站的其他部分可能比使用上面定义的具有更多粒度组件的微服务体系结构更有意义。在这个更简单的设置下，不仅每个大型组件都降低到可管理的复杂程度，而且实现这种类型的站点所需的开发人员和其他人员的数量很少，适用于小型独立团队进行扩展。

总而言之 ：似同非同

所以微服务和SOA有很多共同之处。它们通常情况下都是由松耦合分布式组件的系统。但是，这两种架构背后的意图是截然不同的：SOA尝试整合应用程序，并通常使用“中心管理模式”来确保应用程序可以互操作。而微服务试图实现部署新功能并快速有效地扩展开发组织。它侧重于管理的分散化，代码重用和自动化来执行此操作。