这是一个合适的架构，还是可以改进？
由于业务/企业需求和架构师的偏好的结合，我们已经确定了一种特定的体系结构，在我看来有些不太好，但我的架构知识非常有限，云知识更少，所以我希望能够进行一次明智的检查，看看是否可以在这里进行改进：
背景:我们正在开发一个完全重写的现有系统的替代品。这要求我们通过BAPI/SOAP服务从SAP实例中获取数据，并对SAP中的数据使用我们自己的一些数据库。目前，我们将要管理的所有数据都存在于分布式应用程序上的本地DB中，或者在需要从其上迁移的MySQL数据库中。我们需要创建少量的web应用程序来复制现有分布式应用程序的功能，并在我们控制的数据上提供与管理相关的功能。
业务/企业要求：
- 我们控制的任何数据库都必须在must中实现
- 尽量减少创建的数据库数量
- 第一阶段将让我们将我们的应用程序部署到Azure，但我们需要在将来将这些应用程序引入prem的能力。
- 我们的操作系统团队希望我们篡改所有的东西，因为他们认为这将使他们对代码的管理变得更加简单。
- 最小化/消除数据复制
- 编码栈将是用于微服务和管理应用程序的.NET核心，但对于主要前端应用程序则是角5。
根据这些需求，我们的架构师提出了这样的设计：
我们的前端将从一系列的微服务(我轻轻地使用这个术语，因为它们是‘域’级别和相当大)，这些将被分解为读服务和写入服务在每个领域。两者都将是可伸缩和负载平衡通过库伯内特斯。每个数据库还将在其容器中附加数据库的只读副本，并有一个数据库的主实例可用于写操作，这将推动对那些只读副本的更新。
(对于质量不好的映像，我很抱歉，我是从内存中重做的，因为，当然，除了在架构师的头脑中，没有关于这些东西的实际文档)
服务到服务通信将通过每个服务将侦听的消息队列发生，并处理任何相关消息。这将主要用于电子邮件生成，因为我们还没有发现任何其他需要服务来为通信提供信息服务的东西。任何需要涉及多个服务的“业务逻辑”都可能来自前端，其中前端将单独调用每个服务并处理原子性。
从我的角度来看，让我感到不快的是在服务的坞容器中旋转的只读db实例。服务本身和数据库在负载方面会有巨大的不同需求，所以如果我们能够单独地负载平衡它们，那么它就更有意义了。我相信MYSQL有一种通过主/从配置实现这一点的方法，在这种配置中，只要负载越高，新的从服务器就可以被提升。特别是当我们在云中使用我们的系统并为每个实例付费的时候，当我们只需要另一个db实例时，就会旋转出整个服务的一个新实例，这似乎是浪费的(相反，当我们真正需要一个web服务实例时，就会产生一个新的db副本)。但是，我不知道MS在这方面的局限性。
我最关心的是MS实现。将只读实例如此紧密地耦合到服务上是错误的。有更好的方法吗？
注意:我在软件工程上问过这个问题，他们把我指在这里。对不起，如果这不是合适的SE。
此外，也没有标记
回答 2
DevOps用户
发布于 2018-05-05 17:12:32
我最关心的是MS实现。将只读实例如此紧密地耦合到服务上是错误的。有更好的方法吗？
从本质上讲，您设计的是一个缓存系统--服务容器拥有数据的本地副本，因此在读取时不必进行额外的网络访问。
正如您已经指出的，一个更标准的方法是拥有一个所有容器都可以读取的读取副本集群。这允许您将它们与应用服务器分开扩展，这很好，因为它们通常需要不同的东西(您真的想要为每个应用程序容器分配大量的RAM吗？)这将增加对数据库读取的网络调用，但在被证明是一个问题之前，我不会将解决这个问题的体系结构复杂化。
如果它确实成为一个问题，一个更轻量级的处理问题的方法是在本地运行一个实际的缓存，比如memcache或redis。您可以对单个对象上的TTL进行适当的调优，并且它将自动释放很少请求的数据，以保持应用程序服务器的轻便。
DevOps用户
发布于 2018-12-02 08:51:02
我可以谈论很多关于架构的内容，但这是一个devops社区，所以我将讨论您对运行数据库的主要关注。
简短回答：
如果您要修改设计，以便为每个微服务指定"Azure SQL“，那么在我看来，它看起来还不错。每个微服务都可以有自己单独的Azure数据库实例(可能运行在共享集群上，但对您来说是不可见的)。要在-prem上移动它，您可以决定是要在kubernetes上构建"Azure SQL类“安装程序，还是只需在-prem上运行传统的Server集群。使用Azure SQL并不会将您的体系结构锁定在Azure中，我将在下面讨论。
长答案：
与开放资源数据库或无状态应用程序服务相比，MS SQL Server需要大量内存。它还需要软件许可(我们将在下面讨论优化成本)。因此，可能会出现这样的情况:运行每个服务的许可实例并不是特别符合成本效益的。您可以授权一个SQLServer实例，并在其上运行多个每次服务的私有数据库。更好的方法是使用Azure SQL，这是Server的托管数据库服务版本。这并不会将它们锁定在Azure中，因为您可以移动到AWS，AWS有“”。每个严肃的云提供商都将为所有主要的数据库提供专业管理的数据库服务。
此外，正如您所指出的，在与应用服务器代码相同的kubernetes pod中运行数据库不会允许您独立地扩展它们。此外，无状态应用程序服务器可以在没有持久存储的荚上运行。然后，无状态应用服务器就可以随意死亡并重新启动，并在云可用性区域之间移动。显然，数据库需要由pod“拥有”的持久存储。因此，数据库需要持久的卷声明。如果您希望它们以高可用性运行，则需要它们作为有状态集运行。在与应用服务器相同的pod中运行数据库是开发人员可能在本地运行的东西，但我不推荐它用于Server，因为它的启动速度比您的代码慢10倍。相反，在mac笔记本上运行映像，公开其端口。在windows膝上型计算机上，本机运行。
它被认为是每个微服务的一个非常标准的体系结构，它有自己的逻辑(但不一定是物理的)数据库，但是作为一个具有多个副本的无状态服务运行，这样就可以独立地扩展它们。同时Azure对Redis作为缓存也有很好的支持。因此，它被认为是每个微服务的标准体系结构，每个微服务都有自己的逻辑私有数据库、自己的私有Redis缓存和许多独立缩放的荚。如果您租用Azure SQL和Azure Redis，您将无法选择他们如何实际运行它。你为什么要这么做？让专业人员了解如何运行具有高性能的弹性设置，您可以“为所使用的东西付费”，并专注于编写您的业务逻辑，而不是管理您可以轻松租用的云中的有状态服务。
我看到开发人员在笔记本电脑上本地运行microservices进行调试和单元测试，然后部署到Azure上的Kubernetes，在那里微服务数据库都运行在Azure SQL上。我还看到团队在生产中使用Azure SQL运行，但在Azure中的普通VM上测试Server设置。为什么？因为Azure SQL只附带“生产定价”。该组织已经有了SQL Server on prem和DBA，因此在Azure的VM上安装和运行SQL Server来承载测试env的成本更低。所有的微型服务都有自己的私人数据库。在测试每个微服务数据库时，在VM上的共享SQL Server实例上使用两个节点集群进行恢复力测试。在生产中，每个微服务实例都是在Azure SQL上实现高性能和高可用性的，很可能运行一个对客户隐藏的共享集群。
https://devops.stackexchange.com/questions/4058
复制相似问题
腾讯云开发者
