C# 使用autofac的实时可重构/可更新（微型）服务的最佳实践？

目前正在考虑如何（重新）设计一个微服务，以支持动态重新配置（XML、Json等）和/或更新（Dll）

我是Autofac的粉丝，我认为它可以用于此

最佳实践是什么？我已经知道更新功能已经过时了

多租户似乎不适用于此

我唯一能想到的是对所有可重构类使用C工厂，然后让这个工厂“决定”新的配置/组件是否可用？ 工厂当然是由Autofac控制的

希望有人能给我指出正确的方向

亲切问候,，

---

Henry

这里面有很多内容，答案很大程度上取决于您的应用程序及其工作方式，因此无法提供具体的答案或指导。最好的人能提供的是关于如何通过DI实现动态事物的建议，并希望您能将这些概念应用到您的应用程序中

你已经注意到了。我鼓励您仔细阅读整个问题，因为顶部对变通方法的描述以及本期后面对个别问题的解决将有所帮助

加载插件程序集 如果应用程序中的程序集在运行时发生更改，则很可能需要重新生成容器。很可能您已经在处理一些事情，比如在子进程中运行插件，以便可以转储和重新加载应用程序域；当在插件中发现不同的依赖版本时，您正在处理程序集绑定问题，等等。插件程序集已经是一个挑战；在运行时更改它是。。。嗯，这是一只非常复杂的野兽

如果您在运行时更改插件程序集，我建议您从头开始重建容器。基本上是重新运行应用程序启动逻辑位来注册内容。这意味着您的插件将使用一个独立的容器，而不是应用程序托管的东西。或者，您可以使用子生命周期范围，动态地注册插件内容，并假装子范围是一个“容器”，但当您开始动态地进行绑定重定向之类的工作时，这也可能会有点麻烦

我为什么说重建

• 依赖项可以更改：如果您添加一个插件，并且依赖项集可以更改，这意味着您可能将错误版本的依赖项加载到容器中，并且您将很难调试出现的错误
• 可枚举性可以改变：如果你有一个类似于“插件管理器”的东西，它是一个单例，并且它解析了所有插件的列表，那么你就改变了它。您需要转储单例并重新创建它。这意味着转储保存单例的生存期范围

“但是，”你可能会说，“我没有依赖版本控制的问题！我强制所有插件使用相同的版本！”

“是的，”我会回答，“这正是为什么没有人能给你具体的指导。这就是为什么可以提出建议，提供想法，但这将是100%由你来决定什么适合你的应用。”

更改配置 总的来说，我建议您使用两种可在运行时更改的配置策略：

• Lambda注册：每次解析都会运行Lambda注册。如果该值在运行时可能会更改，则注册一个lambda，该lambda每次执行配置查找可能就是答案。您将始终获得最新的值
• 在DI之外更改的配置处理程序：处理JSON配置的

  Microsoft.Extensions.Configuration

  位允许JSON配置文件在运行时更改，并在封面下重新加载配置。这不是DI的一部分，这是配置系统的一部分。

  Microsoft.Extensions.Logging

  接收器还具有提供动态可配置日志过滤器的功能。这也完全超出了DI的范畴。利用这些东西。不要把所有的重量都放在你的IoC容器上

“但是，”您可能会说，“我需要更改影响整个应用程序的内容！我有一个动态配置，需要更改服务可用的端口以及影响整个主机进程的端口！”

“是的，”我会回答，“这将需要更多的自定义编码，你必须完成这项工作。它可能需要一个完整的单独容器（一个用于“启动”的容器和一个用于“运行时”的容器）。这将是特定于应用程序的，没有人可以为此提供特定的指导。”

多租户技术 多租户支持对于每个租户都不一样的事情非常有用。可能您为每个租户注册了不同的消息处理程序（或其他）。令人惊叹的。您可以像在应用程序级别一样轻松地将上述概念用于多租户。您可以“删除租户作用域”在运行时重新配置它，这是可行的。但是请记住，如果您这样做了，您将必须执行一些锁定，以确保在执行重新配置时，针对该租户的请求将被搁置

性能注释

---

一般来说，IoC容器针对解析操作而不是构建操作进行了优化。如果您预计某个区域会出现大量的客户流失，请尝试使用lambda注册或努力避免重建集装箱。

感谢您的详细回答，我非常感谢！我指的是优雅地过渡到新版本的组件。是否有支持多个组件/实现版本的IoC容器？那么，不是替换实现而是在它旁边设置一个新的实现？这是一个实际的要求吗？我不确定我是否理解这个问题。。。但是我不知道所有容器的所有特性，所以要弄清楚谁支持你要做的一些研究。是的，我还需要做更多的研究。但我想知道我的要求是可行的还是简单的cra