简单题，基本概念题，在校招和初级工程师面试中有可能遇到。
在谈及隔离的时候，最好的面试方案就是联系自己的实践经历，而后提及用过的隔离策略。一方面引导话题，一方面也是刷出亮点。
简单题，在校招和社招中都有可能出现。
在这个问题之下，你可以使用自己实践中的隔离的例子来证明隔离的必要性，引导话题，刷出亮点。
简单题，在校招和社招中都有可能遇到。
在这个问题之下，还是要结合自己的实践案例来刷亮点。
简单题。
在这个问题之下，装逼还是要罗列自己用过的隔离策略，而后面试官就可以对其中的细节进行追问，你就可以装逼了。
类似这种问题，你都可以根据自己的实践经验，谈一谈自己用过的隔离措施。
类似于这种选择类的题目，基本上可以认为要考虑的因素就是业务因素与技术因素。而且正常情况下，业务因素优先级高于技术因素。
同样地，在这个问题之下你可以结合自己的实践案例来刷亮点。
略难的题。这个题目的难点在于你可能只知道容器隔离这个名词，但是对容器技术的了解不深。
在这个问题之下，你可以结合实践来说在什么场景下应该使用什么隔离。
简单题，一般在社招里面会出现。
回答这个问题的最好方式，就是使用自己在实践中使用隔离策略遇到的问题来回答，但是要注意必须是一个硬技术的问题。
简单题，一般在社招中出现。
回答这个问题你就还是可以进一步结合自己的实践经验，阐述对系统造成的影响，最好是使用一些和性能、可用性有关的案例。
简单题，一般在社招里面出现。
在这种强调你遇到过什么问题下，最忌讳的就是你回答我没有使用过隔离策略。如果你这么回答，那么很容易就寄掉。你要选择一个能够体现你技术能力或者对业务深入思考的案例，而后引导话题，刷出亮点。
略难的题，难在很可能你都没听过这个东西，一般只会出现在社招。
在微服务架构，不仅仅代码是隔离的，也就是代码可以独立部署；数据也应该是独立，也就是一个微服务对应一个数据库，而且只有这个微服务可以方位这个数据库。
略难的题，一般出现在社招，校招不太可能会问。
正常来说，一般的业务研发是比较少考虑这种问题的，只有说站在一个比较高的视野上才会进行这种思考。那么在这个问题之下，刷亮点的最好方式，就是举一个通过网关来跟第三方服务保持隔离，并且要在这个网关上叠加丰富完善的服务治理措施，这样可以同时展现你在微服务架构和微服务治理上的深刻理解。
略难的题，一般出现在社招。
所谓的流量隔离其实就是防止某个微服务故障之后，这个流量会把另外一些微服务也冲垮，这个东西有点像是熔断。
你在这个问题之下要刷亮点，就还是要使用自己实践中的案例，还能起到引导话题的效果。
