在我们最近让我们一起学习.NET的微服务专场活动中,我们收到了一些很好的问题。我们在现场已经回答很多问题,但我们想继续回答一些在会议中出现的最热门的问题。如果你错过了现场直播,不要担心,因为你可以按需观看。

观看视频

当我们扩展这些服务时,我们如何扩展与这些服务相关的数据库?

有一些定义良好的模式和最佳实践可以提高性能和扩展数据库。想要了解如何将数据划分为分区,以提高可伸缩性、减少和优化性能, 请参阅水平、垂直和功能性数据分区。想要深入研究微服务的伸缩性,分布式数据,为什么每个微服务都有数据库,在关系数据库和NoSQL数据库之间进行选择,请参考我们关于为Azure构建云原生.net应用程序的指导或下载免费的电子书

我们是否需要为每个微服务使用一个新的数据库,或者微服务可以共享相同的数据库实例?

团队使用微服务的自主性是构建云原生应用的一个重要好处。为了能够使团队能够灵活地在生产中推出更新、安全补丁和bug修复,而不会破坏其他微服务, 最好使用独立的数据库实例。原生云应用架构的灵感来自于著名的12要素应用程序方法论。其中一个因素“支持服务”指出,数据存储、缓存、消息代理等辅助资源应该通过一个可寻址URL公开。云提供商提供了各种各样丰富的托管支持服务。我们建议检查云中可用的数据库选项,而不是自己拥有和维护数据库。

单个Web API能与微服务通信吗?

是的。如果微服务的端点在基础设施中是可到达的,或者使用公共端点安全地访问,那么单片应用程序可以与微服务进行通信。微服务及其数据可以通过其端点进行同步消费,或也可以通过消息传递(如事件总线)进行异步消费。作为现代化技术的一部分,我们推荐有助于渐进地迁移旧系统的扼杀模式。作为解决方案的一部分,您需要创建一个阻止请求的façade。façade将这些请求路由到旧应用程序或新服务。想要了解更多关于微服务通信和现代化技术的信息,请参阅.net体系结构指南

如果微服务是松散耦合和独立部署的,它们如何相互通信?如何在微服务之间同步数据?

这是个很好的问题。在《为Azure构建云原生.net应用程序》一书的两个章节中详细解释了这个问题。这些链接会对你有所帮助:

微服务需要使用容器吗?

没有必要的。然而,使用容器也有它的好处。微服务,通常称为微服务体系结构,是设计指导和最佳实践。它帮助您将应用程序分解为由特定业务边界定义的多个较小的服务,这些服务由较小的团队独立管理。容器将应用程序及其配置和依赖项组合成一个单独的、独立的可部署单元。容器非常适合绑定和部署独立的微服务。您可以通过编写第一个微服务端点并将其容器化来了解其好处。

更多的microservices资源

您是否正在寻找更多用于.net开发的微服务和本地云资源?请持续关注微软的blog和官方文档。有任何问题,欢迎来Microsoft Q&A 论坛提问:
https://docs.microsoft.com/en-us/answers/products/dotnet.

版权声明:本文为MSReactor原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/MSReactor/p/14814955.html