许多组织已经从SOA转移，但微服务的引入已经改变了治理游戏。 吐温泰勒解释了事情的变化。

微服务为IT的各个方面带来变化，尤其是IT治理的完成方式。 用英国政府数字服务部技术和运营副主任迈克尔·布伦顿 - 斯帕尔的话来说，"Microservices trade complicated monoliths for complex interacting systems of simple services."(微服务 交易(交换/替代) 用于简单服务的复杂交互系统的复杂整体 )

这组复杂的简单服务需要相互交流，并以与传统巨石/单体不同的方式进行管理。但这在实践中意味着什么？来！我们讨论一下。

分散的微服务治理

整体治理是集中的。决策是自上而下的，并且保持严格的控制以确保整个组织和应用程序堆栈的一致性。随着时间的推移，这种模式退化，创造了一个技术和架构停滞不前的系统，并减缓了创新的步伐。团队被迫仅仅遵循既定的事情顺序，而不是寻找新的，创造性的问题解决方案。

对于微服务治理，分散模型效果最好。正如应用程序本身被分解为众多相互依赖的服务一样，大型孤立的团队也被分解为小型的多功能团队。这是从开发，测试和IT团队转变为较小的DevOps团队的过程。

团队可以使用他们的首选语言和工具来构建他们拥有的服务，而不是使用相同的编程语言或技术框架来解决整个组织中的所有问题。这将导致缺乏统一性，这实际上可能是一个好处而不是一个缺点。首先，当每个决策涉及的繁文缛节较少时，解决方案的实施速度会更快。而且，由于构建服务的团队拥有其实施和维护，因此对服务的运行拥有更多的所有权，并且他们能够将其发展到更高的水平。

因此，对于刚刚创建并且没有单体历史的应用程序，这种分散的治理模型何时开始？它不是最低可行产品（MVP）阶段，因为在那时，应用程序只不过是一个想法。然而，当一个应用程序投入生产时，它很快就需要采用微服务架构，这就是分散治理开始的时候。

创新与治理

创新速度是实施DevOps的关键目标之一。但IT对治理的关注似乎与此结果相矛盾。这就是为什么IT和开发团队在尝试在创新和实际治理之间找到适当平衡时彼此之间往往会相互争吵的原因。

然而，这是一种错误的二分法。真正的创新不会忽视良好的治理，而伟大的治理应该支持最好的创新。因此，开发和运营团队处于同一方并具有相同的优先级和目标的DevOps原则是良好治理的推动因素。

对于微服务，分散治理是必要的。

DevOps团队必须明白，通过选择他们选择的平台和工具的能力，我们有责任遵守IT部门制定的企业标准。这就是为什么亚马逊在大约十年前刚刚开始作为云供应商时采用了“你建立它，你运行它”的座右铭。亚马逊网络服务公司希望其开发人员与IT共享对其提供的应用程序和功能的稳定性和可靠性的责任。这一原则有助于推动它成为当今领先的基础设施即服务平台。

在不牺牲控制的情况下加速治理的一种方法是自动执行任务。这种自动化可以在治理的不同方面发生，例如安全性和可靠性。

安全

自动化安全涉及策略的组合。与单个大型单片应用程序相比，分布式，API可访问的应用程序对攻击者具有更多潜在的入口点，但通常，使用访问控制规则，Web应用程序防火墙（WAF）的组合可以更容易地保护这些入口点。规则，身份验证和速率限制。自动执行这些任务需要一个可以处理负载平衡，内容缓存，安全策略等的现代Web服务器。

这种平台的一个例子是Nginx Plus。其ModSecurity WAF可保护应用程序层免受攻击，例如SQL注入，本地文件包含，跨站点脚本和某些类型的分布式拒绝服务攻击。此工具可用于静态分析代码，针对代码运行渗透测试和模糊输入，并识别常见的安全相关编程错误，例如无效输入。

可靠性

为了使微服务应用程序顺利运行，其服务需要能够彼此通信并且能够很好地协同工作。这需要良好的服务发现。随着为服务提供动力的底层节点或容器的更改，它们需要由系统识别。这样，服务仍然可见，并且可以成功路由请求。

此外，随着请求的激增，它们无法由单个实例处理，需要跨其他实例进行路由以共享工作负载。这种类型的服务发现和负载平衡 - 在协同工作时 - 使您能够构建可承担任何工作负载的可靠应用程序。

对于微服务治理，分散化是必要的。它提供了开发人员所渴望的创新和灵活性，同时保持了IT运营人员所需的安全性和可靠性。当您希望管理您的应用程序以使其更可靠和安全时，促进分散治理的工具是时间的需要。