在我们最近让我们一起学习.NET的微服务专场活动中，我们收到了一些很好的问题。我们在现场已经回答很多问题，但我们想继续回答一些在会议中出现的最热门的问题。如果你错过了现场直播，不要担心，因为你可以按需观看。
当我们扩展这些服务时，我们如何扩展与这些服务相关的数据库?
有一些定义良好的模式和最佳实践可以提高性能和扩展数据库。想要了解如何将数据划分为分区，以提高可伸缩性、减少和优化性能, 请参阅水平、垂直和功能性数据分区。想要深入研究微服务的伸缩性，分布式数据，为什么每个微服务都有数据库，在关系数据库和NoSQL数据库之间进行选择，请参考我们关于为Azure构建云原生.net应用程序的指导或下载免费的电子书。
我们是否需要为每个微服务使用一个新的数据库，或者微服务可以共享相同的数据库实例?
团队使用微服务的自主性是构建云原生应用的一个重要好处。为了能够使团队能够灵活地在生产中推出更新、安全补丁和bug修复，而不会破坏其他微服务, 最好使用独立的数据库实例。原生云应用架构的灵感来自于著名的12要素应用程序方法论。其中一个因素“支持服务”指出，数据存储、缓存、消息代理等辅助资源应该通过一个可寻址URL公开。云提供商提供了各种各样丰富的托管支持服务。我们建议检查云中可用的数据库选项，而不是自己拥有和维护数据库。
单个Web API能与微服务通信吗?
是的。如果微服务的端点在基础设施中是可到达的，或者使用公共端点安全地访问，那么单片应用程序可以与微服务进行通信。微服务及其数据可以通过其端点进行同步消费，或也可以通过消息传递(如事件总线)进行异步消费。作为现代化技术的一部分，我们推荐有助于渐进地迁移旧系统的扼杀模式。作为解决方案的一部分，您需要创建一个阻止请求的façade。façade将这些请求路由到旧应用程序或新服务。想要了解更多关于微服务通信和现代化技术的信息，请参阅.net体系结构指南。
如果微服务是松散耦合和独立部署的，它们如何相互通信?如何在微服务之间同步数据?
这是个很好的问题。在《为Azure构建云原生.net应用程序》一书的两个章节中详细解释了这个问题。这些链接会对你有所帮助:
- 原生云通信模式或下载免费电子书。
- 在分布式应用中管理数据。
- 你也可以下载关于微服务架构指南的免费电子书，其中涵盖了一些模式，如DDD、CQRS、事件源等。
微服务需要使用容器吗?
没有必要的。然而，使用容器也有它的好处。微服务，通常称为微服务体系结构，是设计指导和最佳实践。它帮助您将应用程序分解为由特定业务边界定义的多个较小的服务，这些服务由较小的团队独立管理。容器将应用程序及其配置和依赖项组合成一个单独的、独立的可部署单元。容器非常适合绑定和部署独立的微服务。您可以通过编写第一个微服务端点并将其容器化来了解其好处。
更多的microservices资源
您是否正在寻找更多用于.net开发的微服务和本地云资源?请持续关注微软的blog和官方文档。有任何问题，欢迎来Microsoft Q&A 论坛提问:
https://docs.microsoft.com/en-us/answers/products/dotnet.