背景：我们正在开发一种替代现有系统的方法，该方法将彻底重写。这要求我们通过BAPI / SOAP Web服务从SAP实例中获取数据，并使用我们自己的某些数据库来存储不在SAP中的数据。当前，我们将要管理的所有数据都存在于分布式应用程序的本地数据库中，或者存在于需要迁移的MySQL数据库中。我们将需要创建一些Web应用程序，这些应用程序可以复制现有分布式应用程序的功能，并在我们控制的数据上提供与管理员相关的功能。
业务/企业要求：
我们控制的任何数据库都必须在MS SQL Server中实现
最小化创建的数据库数
第1阶段将使我们将应用程序部署到Azure，但是我们需要有能力在将来将这些应用程序部署到内部环境中。
最小化/消除数据复制
编码栈将成为用于微服务和Admin应用程序的.NET Core，而Angular 5将成为主要前端应用程序。
根据这些要求，我们的建筑师提出了以下设计方案：
我们的前端将来自一系列微服务（由于它们是“域”级别并且相当大，我会轻描淡写地使用该术语），它将在每个域中分为读取服务和写入服务。两者都可以通过Kubernetes进行扩展和负载均衡。每个数据库还将在其容器内连接有其数据库的只读副本，并且具有一个单独的db主实例可用于写入操作，该实例会将对这些只读副本的更新推送出去。
（对于质量差的图像，很抱歉，我正在从内存中重做它们，因为自然地，除了这些东西外，没有关于这些东西的实际文档）架构师的脑袋）
服务到服务的通信将通过每个服务将侦听并处理任何相关消息的消息队列进行。它的主要用途是用于电子邮件生成，因为我们还没有发现其他需要服务进行信息通信的服务。任何需要涉及多个服务的与“业务逻辑”相关的东西，都可能会从前端流出，在前端，前端将分别调用每个服务并处理原子性。
从我的角度来看，让我感到困惑的是只读的db实例在服务的docker容器内旋转。服务本身和数据库在负载方面将有截然不同的需求，因此，如果我们可以分别对它们进行负载平衡，则将变得更加有意义。我相信MYSQL可以通过主/从配置来做到这一点，只要负载变大，就可以启动新的从服务器。尤其是当我们将系统存储在云中并为每个实例付费时，在仅需要另一个数据库实例的情况下拆分整个服务的新实例似乎是浪费的（反之亦然，当我们只需要一个数据库实例时就拆分一个新的数据库副本）需要一个Web服务实例）。但是，我不知道MS SQL Server的局限性。
我最大的担忧是围绕MS SQL Server实现。将只读实例与服务紧密耦合在一起是错误的。有没有更好的方法呢？
注意：我在软件工程方面提出了这个问题，他们在这里指出了我。抱歉，如果这不是合适的SE。
也没有MS SQL Server标记
#1 楼
我最大的担忧是围绕MS SQL Server实施。将只读实例与服务紧密耦合在一起是错误的。有更好的方法吗？
基本上，您设计的是缓存系统-服务容器大概具有数据的本地副本，因此对于读取而言，它们不会您必须指出，必须进行额外的网络行程。
，更标准的方法是拥有所有容器均可读取的只读副本集群。这使您可以与应用程序服务器分开扩展它们，这很好，因为它们通常需要不同的东西（您是否真的要为每个应用程序容器分配大量RAM？）。这将增加对数据库读取的网络调用，但是在证明这是一个问题之前，我不会让体系结构复杂化来解决它。问题是要在本地运行实际的缓存，例如memcache或redis。您可以适当调整单个对象上的TTL，它会自动删除很少请求的数据，以保持应用服务器的正常运行。
评论
您是否知道一种负载平衡/提升ms sql server读副本的新实例的方法？
–马歇尔·泰格斯（Marshall Tigerus）
18年5月7日在14:12
我没有使用SQL Server的经验，但是您应该能够使用正常的过程。如果您的负载相当恒定，则可以按照通常的方式创建新的从属服务器。如果您需要自动缩放，则取决于您的托管平台。而且，您可以使用所选的负载均衡器对请求之间的负载进行均衡。
–熊佳亚诺夫
18年8月6日在16:35
#2 楼
我可以谈论很多有关该体系结构的信息，但这是一个devops社区，所以我将解决您对仅运行数据库的主要关注。简短的回答：
如果您要修改设计以对每个微服务说“ Azure SQL”，那么对我来说还可以。每个微服务都可以具有自己的单独的Azure SQL数据库实例（可能在共享群集上运行，但是对您不可见）。要稍后将其移动到本地，您可以决定是要在kubernetes上构建“类似于SQL的Azure SQL”设置，还是只需要在本地运行传统的SQL Server群集。正如我将在下面讨论的那样，使用Azure SQL不会将体系结构锁定在Azure中。
长答案：
与开放源数据库或Microsoft SQL Server相比，MS SQL Server需要大量内存无状态应用程序服务。它还需要软件许可（我们将在下面介绍优化成本）。因此，可能情况是，每个服务运行许可的实例并不是特别具有成本效益。您可以许可一个SQLServer实例并在其上运行许多每个服务的专用数据库。最好还是使用Azure SQL SQL Server的托管数据库即服务版本。这并不会将它们锁定在Azure中，因为您可以迁移到具有“用于SQL Server的Amazon RDS”的AWS。每个严肃的云提供商都将为所有主要数据库提供专业管理的数据库服务。
另外，正如您指出的那样，在与应用程序服务器代码相同的kubernetes pod中运行数据库将无法独立扩展它们。此外，无状态应用程序服务器可以在没有持久性存储的Pod上运行。然后，无状态应用程序服务器可能会死掉并随意重启，并在云可用性区域之间轻松转移。显然，数据库需要由pod“拥有”的持久性存储。因此，数据库需要持久的卷声明。如果希望它们以高可用性运行，则需要它们作为有状态集运行。开发人员可能会在本地在与应用程序服务器相同的Pod中运行数据库，但是我不建议在SQL Server中使用它，因为它的启动速度比代码慢10倍。而是在Mac笔记本电脑上运行SQL Server docker映像，以暴露其端口。在Windows笔记本电脑上，本机运行SQL Server Express。
对于每个微服务来说，它被认为是一种非常标准的体系结构，它具有自己的逻辑（但不一定是物理）数据库，但是可以作为具有许多副本的无状态服务运行，以便可以独立扩展它们。 Azure还对Redis作为缓存提供了很好的支持。因此，对于每个微服务来说，它被视为具有自己的逻辑私有数据库，它自己的私有Redis缓存以及许多独立缩放的Pod的标准体系结构。如果要租用Azure SQL和Azure Redis，则不必选择它们的物理运行方式。而你为什么要呢？让专业人员弄清楚如何运行具有高性能的弹性设置，您可以“为所用的东西付费”，并专注于编写业务逻辑，而不是管理可轻松租用的云中的有状态服务。
我已经看到开发人员在其笔记本电脑上本地运行MS SQL Server Express进行调试和单元测试，然后部署到Azure上的Kubernetes，其中微服务数据库都在Azure SQL上运行。我还看到团队在生产中针对Azure SQL运行，但是针对Azure中普通VM上的SQL Server安装程序进行测试。为什么？因为Azure SQL仅带有“生产定价”。该组织已经拥有SQL Server本地和DBA，因此它们在Azure的VM上安装和运行SQL Server来托管测试环境的成本较低。所有微服务都有自己的私有数据库。在每个微服务数据库中测试那些具有两个节点群集的VM上共享SQL Server实例上的虚拟服务器上的弹性。在生产中，每个微服务实例全部都在Azure SQL上实现高性能和高可用性，并可能运行对客户隐藏的共享群集。
评论
我建议您阅读官方的Azure模式文档。它们非常清晰，将为您提供很多您可以在讨论中指出的内容。例如，为您提供的体系结构基于CQSR。我发现Azure体系结构文档非常好，它涵盖了许多带有示例代码的著名模式以及如何在Azure上部署它们。它们可能与示例代码中的Kubernete无关，但是对于CQSR的建议围绕数据库管理和逻辑布局的建议，它们无疑将非常有帮助。
–simbo1905
18/12/2在8:57
评论
当然，将数据库和Web服务放在同一容器中不是一个好习惯。我真的不能说出MS SQL服务器，但是它们确实支持复制，直到我不知道哪一点（副本数）。