微服务架构与SOA之间的区别 [英] Difference between Microservices Architecture and SOA

问题描述

我一直在阅读微服务架构，我试图看到它与常规SOA之间的区别（除了单独部署的服务之外）。任何人都可以告诉我这个差异，也许是微服务架构的专业人员和公司？

解决方案

我想你可以想到微型服务架构作为SOA专业化的风格。不要忘记，接受的视图之一是所有SOA真的是四个句子：

• 边界是明确的


• 服务是自主的


• 服务共享模式和合同，而不是类



• 服务兼容性基于策略

  
  
  

  ^{- Don Box，Microsoft（prec.Net 3.0）}

这将带给我们微型服务的规范定义，来自Lewis / Fowler：

<简而言之，微服务架构风格是
开发单个应用程序作为一套小型服务的一种方法，每个
在自己的进程中运行并与轻量级$
机制，通常是HTTP资源API。这些服务是围绕业务功能构建的
，并且可以通过完全
自动部署机器独立部署。对这些服务的集中式
进行了最低限度的集中管理，可以使用不同的
编程语言编写并使用不同的数据存储技术。

从这个定义可以看出，微服务至少达到了前两个原则（其实就是第二个原则），但是它们是否满足第三个要求（我不太了解原则4）所以我不会评论）。

第三个原则可能不适用于微服务的原因是微服务的一个特点是它们通常暴露在一个RESTful API上，根据Fowler的看法，根本不会暴露合同和模式（超过正常的HTTP语言），

服务，每个...与轻量级机制通信，通常是HTTP资源API

微服务风格偏离SOA的另一种方式是使用这个处方：

这些服务是...通过全自动部署机器独立部署

遵循SOA的原始原则并不阻止我将我的服务二进制文件手动复制到我的生产环境中，而是使用微服务方法，服务部署和管理应该完全自动化。

I've been reading up on Microservice Architecture and I am trying to see a difference between it and regular SOA (apart from the services all deployed individually). Can anyone tell me the difference and maybe the pro's and con's of Microservice Architecture?

解决方案

I guess you could think of the Microservices Architectural Style as a specialisation of SOA. Don't forget that one of the accepted views is that all SOA really is, is four sentences:

• Boundaries are explicit
• Services are autonomous
• Services share schema and contract, not class

• Service compatibility is based on policy

  ^{-Don Box, Microsoft (pre-.Net 3.0)}

This brings us to the canonical definition of microservices, from Lewis/Fowler:

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralised management of these services, which may be written in different programming languages and use different data storage technologies.

From this definition, it's clear that microservices fulfil at least the first two tenets (with a real emphasis on the second), but it's questionable whether they fulfil the third (I don't really understand tenet 4 so I won't comment).

The reason the third tenet may not hold for microservices is that one of the characteristics of microservices is that they are generally exposed over a RESTful API, which, one could argue, does not expose contract and schema at all (over and above the regular HTTP verbiage), as we see from Fowler:

a suite of small services, each... communicating with lightweight mechanisms, often an HTTP resource API

Another way in which a microservices style deviates from SOA is with this prescription:

These services are... independently deployable by fully automated deployment machinery

Following the original tenets of SOA does not prevent me from manually copying my service binaries into my production environment, but with the microservices approach, the service deployment and management should be fully automated.

这篇关于微服务架构与SOA之间的区别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！