微服务架构面向服务型架构_微服务架构听起来像面向服务的架构

微服务架构面向服务型架构

我不了解面向服务的体系结构。我认为这只是那些高度理论化和非常不切实际的软件体系结构模式之一。

换句话说，我认为这是建筑狂热者的梦想。

然后，我读了Martin Fowler的标题为Microservices的文章，面向服务的体系结构突然开始对我有意义。

是什么改变了我的思想？

Martin Fowler 将微服务架构指定如下：

简而言之，微服务架构风格是一种将单个应用程序开发为一组小服务的方法，每个小服务都在自己的进程中运行并与轻量级机制（通常是HTTP资源API）进行通信。这些服务围绕业务功能构建，并且可以通过全自动部署机制独立部署。这些服务的集中管理几乎没有，可以用不同的编程语言编写并使用不同的数据存储技术。

读完这些后，我的脑海里有些响亮的声音。我意识到微服务架构听起来很像面向服务的架构，其指定如下：

面向服务的体系结构（SOA）是一种基于离散软件的软件设计和软件体系结构设计模式，这些离散软件将应用程序功能作为服务提供给其他应用程序。这称为面向服务。它独立于任何供应商，产品或技术。

服务是功能齐全的单元，例如检索在线银行对帐单。服务可以被其他软件应用程序组合以提供大型软件应用程序的完整功能。

我为什么不早点得到这个？我认为有两个原因：

我不是非常喜欢精美的体系结构图和技术失误，而这些都是经常用来解释面向服务的体系结构的工具。我猜你可以说我看不见树木上的森林。
我在职业生涯中创建的大多数应用程序都是“常规” Web应用程序。换句话说，向用户显示的用户界面是在后端呈现的。在这些应用程序中使用面向服务的体系结构对我来说没有任何意义，因为将所有内容添加到相同的二进制文件中比较简单。

单页Web应用程序的兴起对我的思想产生了重大影响。当后端向前端提供REST API来决定应如何呈现所接收的信息时，面向服务的体系结构将变得有意义，因为它具有以下优点：

我们可以将应用程序分为几个部分。每件作品都满足特定的需求，并具有自己的领域特定语言。
我们只能扩展应用程序中需要更多资源的那些部分。
我们可以部署单个服务，而不是部署整个应用程序。
不同的服务不必使用相同的编程语言。换句话说，我们可以使用最好的工具来完成这项工作。
不同的团队可以创建（和维护）不同的服务。

面向服务的体系结构不是灵丹妙药，但是它提供了解决由整体体系结构引起的问题的解决方案。

有两个最让我困扰的问题：

很难将代码组织到与应用程序其他模块没有依赖关系的模块中。尽管我认为这不是单片式架构的错，但仍然是从大多数单片式应用程序中发现的一个问题（如果使用Spring，则还有其他问题）。
整体语言常常充满折衷。我承认，我对领域驱动的设计有些痴迷，我很乐意在工作中使用它的全部功能。但是，当所有代码都属于同一个整体且必须满足具有不同词汇的不同业务需求时，很难做到这一点。也许这是企业应用程序经常使用非常通用且令人困惑的语言的原因之一。

也许我对此有点太热情了，但是可以肯定地说，面向服务的/微服务架构终于进入了我的工具箱。

这个名字并不重要

面向服务的体系结构可能声誉不好，因为它听起来像是企业精神，而且每个人都知道企业精神是一件坏事（至少在时髦圈子中如此）。也许这就是为什么有人开始称其为微服务架构的原因。

或者也许我不太了解面向服务的体系结构，这就是为什么我看不到它与微服务体系结构之间的任何区别的原因（这可能是事实）。

因为我不是体系结构顾问，所以我并不在乎这种体系结构样式的名称是什么。我所关心的是，我找到了一种解决由整体式架构引起的问题的新方法。

翻译自: https://www.javacodegeeks.com/2014/03/the-microservice-architecture-sounds-like-service-oriented-architecture.html

微服务架构面向服务型架构