Architecture 微服务治理与SOA

在过去的10年里，我一直在从事SOA治理项目，现在我们转向了微服务体系结构

SOA的好处在于，我们有一个规范化的数据模型，在这个模型中，我们的确付出了一些努力，但最终所有系统都使用相同的“语言”，通信通过服务总线集中

在微服务架构中，团队是独立的，因为没有服务总线，所以不知道所有这些集成点将如何工作

1） 有没有一种方法可以像SOA中的WSDL（用于SOAP）一样实施某些契约

2） 如果开发服务B的团队是自动的，并且部署了一个新的服务，那么它也必须保留旧版本吗？在SOA中，这个问题得到了解决，我们在服务总线上保留了v1和a，并将其转换为v2。对于消费者来说，服务B有一个新的版本是很方便的

3） 如果微服务的数量非常高，如下图所示，并且知道团队必须尽可能地自动化（“敏捷”），那么您会采取什么样的管理方式

我不是在寻找最好的答案，我对不同的观点感兴趣，因为这里没有神奇的解决方案

谢谢

---

我们也在经历类似的变化

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

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

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

• 什么是（或不是）被认为是突破性的变更，以及在版本控制系统中如何处理这一变更
• 如何/在何处发布和更新服务文档
• 客户端如何进行身份验证
• 安全建议，如TLS和身份验证机制

---

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

我也参与了类似的转换，在过程中犯了不少错误。以下是我作为中央管理机构应该做的一些事情：

1。首先创建架构独立性

我认为最大的错误就是让旧的SOAP服务成为他们自己的东西。这行不通。第二个错误是让微服务成为数据积垢服务（如产品、客户等）。那也不行

这些事情只会给你带来很多同步的相互依赖和更多的问题

我会投资于一个相互依赖性最小化的体系结构。尽可能减少同步通信的需要。我不是说使用MQ，而是说微服务的主要功能应该与其他服务一起工作

这需要一种全新类型的分解，而不是像旧的SOAP服务那样。因此，这是一项艰苦的工作，但避免了许多（指数）问题。退房

2。协议管理

特别是如果您正在过渡到RESTful HTTP，我将为以下内容设置规则：

• 链接格式标准（因此所有应用程序都可以统一爬网）
• 链接最佳实践（必须通过链接访问所有资源，URL不应硬编码，等等）
• 文件编制标准（如何编制文件）
• 媒体类型的版本控制
• 重要的是，一种自动的方式，在不向后兼容的更改后将版本标记为过时。还有一个标准的宽限期，在这个宽限期之后，它们将被移除（它们必须存活的时间）。按日历间隔或发布次数等

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

我不会要求特定的产品（比如Swagger），而是让团队做出这些决定

如果您只是在寻找JSON-RPC而不是REST，那么上面的几点可能与您无关

3。类似基础设施的东西

创建统一的身份验证和授权标准。同样，我会尽可能使这些产品独立，而不需要同步通信

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

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

4。持续监督

我可能会创建一个建筑监理团队。要创建一个合适的体系结构是很困难的，要想改变它就更难了，因为项目有时需要快速而肮脏的解决方案，这会造成潜在的依赖关系和隐藏的问题

这些人需要成为实际的领域专家和架构师，并最终对整个景观的功能负责

---

好吧，这是我临时准备的清单，嗯..

两种架构都有相似的优点和缺点，也有一些不同之处。在这两种体系结构中，与单片体系结构不同，每个服务都具有