微服务治理与SOA

Question

过去10年我一直在从事SOA主题项目，现在我们转而使用微服务架构。

SOA中的好处是我们有一个规范数据模型，其中确实是通过一些努力构建的，但最后所有系统最终都说出了相同的语言＆＃39;并通过服务总线集中通信。

在微服务架构中，团队是独立的，因为没有服务总线想知道所有这些整合点是如何工作的。

1）有没有办法让一些合同像SOA中的WSDL（用于SOAP）？

2）如果开发服务B的团队是自主的并部署新服务，那么它必须保留旧版本吗？在SOA中，这个问题得到了解决，在服务总线上我们保留了v1，并且我们对v2进行了转换。对于服务B有新版本的消费者而言，这是一种透明的。

3）如果微服务的数量非常高，你会采取什么样的政策，如下图所示，知道团队必须尽可能多的自主（敏捷＆＃39;）？

我不是最好的答案，我对不同意见感兴趣，因为这里没有神奇的解决方案。

感谢。

Answer 1

我们也正在经历类似的变化。

关于您是否执行合同的问题与您是通过服务总线连接还是直接连接无关。您可以构建您的微服务以使用SOAP和WSDL。整个行业似乎正在逐渐远离这一点。我们正在使用REST。

负责部署微服务的团队需要像对待客户一样对待所有外部各方。这意味着当发生更改时，他们需要保持向后兼容性，然后在其他团队中进行更改管理过程，以便在退役旧版本之前对其进行升级。我们尽可能避免破坏更改，否则使用语义版本控制。自动化测试有助于保持这一切。

在治理方面，我会围绕以下内容制定基本规则：

• 什么是（并且不是）被视为重大变化，以及如何在版本控制系统中处理
• 如何/何处发布和更新服务文档
• 客户如何进行身份验证
• 安全建议，如TLS和身份验证机制

虽然您可能没有涵盖所有服务的规范数据模型，但引入适合您的域的一些较小的约定可能是明智之举。在我的域中，这意味着始终使用3个字符的ISO标准货币代码和货币金额。我们从不假设货币或使用不同的代表。

Answer 2

两种架构都有相似的优缺点，也有一些区别。在这两种体系结构中，每项服务（与整体体系结构不同）都有一定的责任。因此，可以在各种技术堆栈中开发服务，从而将技术多样性带入开发团队。服务的开发可以在多个团队中进行组织，但是每个团队都需要了解SOA中的通用通信机制。

在微服务中，与SOA不同，服务可以独立于其他服务运行和部署。因此，更容易频繁地部署新版本的服务或独立扩展服务。

在SOA中，ESB（企业服务总线）可能会成为影响整个应用程序的单点故障。由于每个服务都通过ESB进行通信，因此如果其中一项服务变慢，则可能导致ESB被对该服务的请求所阻塞。另一方面，微服务的容错性要好得多。例如，如果一个微服务中存在内存泄漏，则仅会影响该微服务。其他微服务将继续处理请求。

在两种体系结构中，开发人员必须处理体系结构和分布式系统的复杂性。开发人员必须在微服务之间（如果消息队列用于微服务体系结构中）或ESB与服务之间实现服务间通信机制。

单元测试更加困难，因为开发人员必须在测试中模拟通信机制。由于许多不同的服务类型，因此两种架构都需要考虑部署和操作复杂性。

在SOA中，服务共享数据存储（如图1所示），而每个服务在微服务中可以具有独立的数据存储。共享数据存储有其优点和缺点。例如，数据可以在所有服务之间重复使用，同时带来服务之间的依赖性和紧密耦合。

最后但并非最不重要的一点是，SOA和微服务之间的主要区别在于大小和范围。微服务必须显着小于SOA的规模，并且主要是一种较小的（可独立部署的）服务。另一方面，SOA可以是整体，也可以包含多个微服务。

同样重要的是，SOA的设计和实现方式可能与此处描述的样式有所不同，这通常是由于侧重于用于集成单片应用程序的ESB。

Answer 3

我参与了类似的过渡，一路上犯了很多错误。以下是我作为中央管理机构所做的一些事情：

<强> 1。首先创建架构独立性

我认为最大的错误就是让旧的SOAP服务成为他们自己的东西。它不会起作用。第二个错误是让微服务成为数据CRUD服务（如产品，客户等）。这也行不通。

这些事情只会为你创造许多同步的相互依赖关系和更多的问题！

我会投资建立一个相互依赖最小化的架构。尽可能减少对同步通信的需求。我并不是指使用MQ，但微服务的主要功能应该与其他服务一起使用。

这需要一种全新的分解方式，而不是旧的SOAP服务。所以这是艰苦的工作，但后来避免了很多（exponental）问题。查看Self-Contained Systems。

<强> 2。协议治理

特别是如果您要转换到RESTful HTTP，我会为以下内容设置规则：

• 链接格式标准（以便可以统一抓取所有应用程序）
• 关联最佳做法（所有资源 可通过链接访问，网址不应硬编码等）。
• 文档标准（如何记录Media-Types）
• 版本控制媒体类型
• 而且重要的是，在非向后兼容的更改之后，标记版本的自动方式已过时。还有一个标准的宽限期，之后这些被删除（它们必须保持活着的时间）。按日历间隔或发布数量等

没有一种方法可以做到这些，所以你必须提出所有这些，然后执行它们。

我不会要求特定产品（如Swagger），并让这些决定与团队合作。

如果你只是在寻找JSON-RPC而不是REST，那么上述一些观点可能与你无关。

第3。像基础设施一样的东西

为身份验证和授权创建统一标准。同样，我会尽可能地使它们与产品无关，而不需要同步通信。

例如，定义使用Json Tokens。这些东西可以“脱机”使用，不与任何人通信，也可以包含有关用户授权的断言。

定义安全性约束，例如某些消息的通信加密。同样，我只需要“什么”而不是“如何”。

<强> 4。持续监督

我或许会建立一个建筑监督团队。很难创建一个合适的架构，更难以改变它而不会因为有时需要的快速和肮脏的解决方案项目而堕落，从而产生偷偷摸摸的依赖关系和隐藏的问题。

这些人需要成为实践领域的专家和建筑师，并且最终必须负责才能实现整个环境。

嗯，这是我即兴的事情清单，HTH ..