微服务Monolith .分期/ UAT环境

Question

在我们的组织中，我们希望采用一种面向服务的体系结构，其中新的需求(自然有界的上下文)正在作为单独的服务构建，这些服务以API的形式集成到主monolith中&有时也是前端的(如果今天我们将使用某种形式的webcomponents )。

今天，我们的一体式开发管道几乎没有固定的非驱动环境(qa、分阶段、演示等)。当我们构建单独的服务时，让这些服务成为这些非prod环境的一部分是最好的实践吗？

我看到的另一个选择是，我们可以只对这些较小的服务使用staging & production，并将所有非prod monolith环境指向staging环境。但是，问题变成了需要构建单个staging环境来隔离和处理来自不同的单点环境的数据。

我知道，最干净和最安全的方法是让所有服务(包括monolith)在任何&所有环境中一起运行。但是，负责这些服务的人员之间的协调也是必要的，对吧？

此外，我们希望为开发人员提供他们自己的按需预览环境。在这种情况下，我们是否要把所有其他服务分拆出来呢？

在我们对这个问题采取一种简单的方法之前，我只是想了解一下其他人在他们的团队中可能面临的不可预见的后果。

Answer 1

而事物是混合的

如果您的monolith很难部署，需要大量的资源，或者即使在开发环境中也有许可成本；那么您需要限制monolith存在的实例的数量。您的选择是创建一个模拟器来手动执行monolith可以完成的任务，这样您就可以测试微服务，或者使用测试直接操作数据存储。

但是，如果您的monolith非常容易部署，您也可以自动化它的部署。可以说，这将是一项“更大”的服务。

理想环境

您会发现，微服务成功的关键因素之一是尽可能地自动化部署。无论您使用主厨、盐类、TerraForm、CloudFormation，还是使用库伯内特斯这样的编排层进行容器化，都是您必须做出决定的选择。

解决这个问题的方法很多，但其核心是您需要使您的部署和配置尽可能自动化。使这更容易的一些方法包括：

• 外部化配置:部署系统将配置推送到服务。
• 服务发现:要么使用专用服务发现组件，要么利用您的基础设施(即DNS条目或Kubernetes使查找服务更容易的多种方式中的一些)
• 保护秘密:诸如用户名和密码之类的秘密，或者用于OAuth 2身份验证的客户端id和秘密id不应该被清除。如果您有动态加密和解密的方法，则可以利用您的外部配置。
• 持续集成/连续交付:每个提交到正确分支或标记的承诺都应该构建软件并将其部署到正确的环境中。

通过将部署作为整个过程的一部分，您的问题会自行回答。一旦您经历了自动化部署和适当配置不同环境的麻烦，为什么不只是在所有环境中进行更改时部署您的服务呢？这使得自动化测试和临时测试更容易完成。

团队责任

当您与大型软件团队(如亚马逊(商店前)、NetFlix、AirBnB等)交谈时，有一个共同的口号。也就是说，每个服务应该有一个团队。该团队负责与服务相关的一切工作，包括部署、测试、恢复测试、监控等。理想情况下，团队将是一个2个比萨饼团队(大约5-8人，视他们的饥饿程度而定)。

对于像我这样规模较小的开发团队来说，这并不是大多数公司都能做到的。例如，我有两个团队为我工作，将两个应用程序集成到一个应用程序中。为了处理协调工作，我们将计划会议与我们正常的scrum节奏结合起来。

• 每周我们都有一个Scrum，每个团队负责人都与架构师(在本例中是我)和业务人员一起工作，这样我们就可以解决与技术、计划或业务优先级相关的问题。
• 在发布计划中，我们确定了需要更紧密地协调的领域。

我们的版本通常是4个sprint值的工作，然后部署到生产。然而，与商业集团相比，我们的客户发布软件的官僚作风要大得多。你的经历可能不一样。然而，我可以说，从经验来看，部署越频繁，部署自动化就越重要。

Answer 2

我写下了一个专门针对这个主题的6个分钟博客-发帖。我将把它分解成几个要点(本质上，这是一个TL;DR)，并添加一些与作者的问题相关的要点。

• 生产是最重要的环境，应将其视为如此-必须在所有可能的方面对部署到生产进行测试，以减少停机的风险和无法预见的后果(与作者的声明有关)。
• "...Developers随需应变的预览环境.“--这样做并不意味着每个开发人员都必须部署整个”真正的“基础设施。开发人员需要一个环境来测试他们的代码，而不影响他们的同事，这是“随需应变环境”的主要目标。我指的是每个开发人员不部署“真正”的库伯内斯集群，其中包括所有相关资源，如webserver (nginx、阿帕奇)、数据库(MySQL、PostgreSQL)等等，这是非常普遍的，也是推荐的。真正的挑战将是使用相关数据填充数据库，并从开发环境中获取机密/参数，如果您有一个优秀的DevOps团队，他们应该能够在没有问题的情况下做到这一点。
• 我们是人类--你不希望你的DevOps工程师因为他们认为自己在开发环境中而意外地在生产中应用改变。这也被称为“困惑的代理问题”。
• 多环境意味着更多的金钱(而不是)--考虑到将环境划分为不同帐户的成本是很重要的。例如，如果使用网络应用程序防火墙(WAF)，则可以将防火墙附加到dev和stg的资源。将dev和stg分离到不同的帐户意味着您需要在两个帐户中创建WAF资源，因此需要支付“两次”。所有这一切都涉及到代价更高的问题，可能会为开发人员和stg之间可能共享的资源支付更多的费用，或者将无法预测的部署部署到珠三角可能导致不必要的停机时间。一旦你回答了这个问题，你就会知道你是否愿意把stg和dev分开。
• (可选)规则--如果您的组织需要满足诸如GDPR或HIPAA这样的法规，那么将环境拆分为单独的帐户会增加您满足这些规定的要求的机会。当然，在达到要求时，有很多事情需要考虑，而分离环境通常是你做的第一件事(根据过去的经验)。对于每个组织来说，这是不同的，但是这个任务总是摆在桌面上的第一件事。

有更多的理由，你应该分开你的环境，但我认为，这已经足够了。希望能帮上忙。