问微服务治理与SOA

EN

我也参与了一个类似的转变，其间我犯了不少错误。以下是我作为一个中央管理机构所要做的一些事情：

1.首先创建独立于体系结构的

我认为最大的错误就是让旧的SOAP服务成为他们自己的东西。恐怕行不通。第二个错误是让Microservices成为数据CRUD服务(比如产品、客户等)。那也没用。

这些东西只会给您带来许多同步的相互依赖关系和更多的问题！

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

这需要一种全新类型的分解，而这种分解将与旧的SOAP服务不同。因此，这是艰苦的工作，但避免了许多(指数)问题以后。看看自给系统。

2.协议治理

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

• 链接格式标准(因此所有应用程序都可以统一爬行)
• 链接最佳实践(所有资源都必须通过链接访问，urls不应该是硬编码的等等)
• 文档标准(如何记录媒体类型)
• 版本控制媒体-类型
• 更重要的是，在非向后兼容的更改之后，自动标记版本过时了.并有一个标准的宽限期，在此之后，这些人被移除(他们必须活着的时间)。按日历间隔或发布数量等。

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

我不会要求一个特定的产品(比如Swagger)，让团队来做这些决定。

如果您只是在寻找JSON而不是REST，那么上面的一些要点可能与您无关。

3.类似于的基础设施

创建统一的认证和授权标准。再一次，我将使这些尽可能独立于产品，而不需要同步通信。

例如，定义使用Json令牌。这些东西可以“离线”使用，无需与任何人通信，也可以包含有关用户的断言，这些断言也有助于授权。

定义安全约束，比如对某些消息进行通信加密。再说一遍，我只要求“什么”而不是“如何”。

4.持续监督

我也许会创建一个负责建筑监督的团队。很难创建一个合适的体系结构，更难以改变它而不被项目有时需要的快速和肮脏的解决方案所吸引，从而创建出狡猾的依赖关系和隐藏的问题。

这些人需要成为领域专家和建筑师，并最终负责整个景观的运作。

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

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

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

在SOA中，ESB (Enterprise )可能成为影响整个应用程序的单一故障点。因为每个服务都是通过ESB进行通信的，如果其中一个服务慢下来，它可能会导致ESB被对该服务的请求阻塞。另一方面，微服务在容错方面要好得多。例如，如果一个微服务中存在内存泄漏，那么只有该微服务会受到影响。其他微型服务将继续处理请求。

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

单元测试更加困难，因为开发人员必须在测试中模拟通信机制。由于许多不同的服务类型，部署和操作复杂性在这两种体系结构中都很受关注。

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

最后但并非最不重要的一点是，SOA和微服务之间的主要区别在于大小和范围。Microservice必须比SOA倾向的要小得多，并且主要是一个小型(呃)独立部署的服务。另一方面，SOA既可以是单一的，也可以是由多个微服务组成的。

同样重要的是，SOA是以不同的风格设计和实现的，这些样式可能与这里描述的不同，这通常是由于对ESB的关注，ESB是用来集成单片应用程序的。