java单或与双活的区别_java架构师指南：使用微服务架构一般会有哪些风险

微服务架构中，常见的可用性风险到底有哪些吧，知道了有哪些风险我们才知道该如何去规避、去隔离风险。

我们可以从项目部署规模的角度去分析风险：

单机可用性风险：

这个很好理解，就是微服务部署所在的某一台机器出现了故障，造成的可用性风险。这种风险发生率很高，因为单机器在运维中本身就容易发生各种故障，例如 硬盘坏了、机器电源故障等等，这些都是时有发生的事情。不过虽然这种风险发生率高，但危害有限，因为我们大多数服务并不只部署在一台机器上，可能多台都有，因此只需要做好监控，发现故障之后，及时地将这台故障机器从服务集群中剔除即可，等修复了再重新上线到集群里。

单机房可用性风险：

这种风险的概率比单机器的要低很多，但是也不是完全不可能发生，在实际情况中，还是有一定概率的。比如最为常见的就是通往机房的光纤被挖断了，前段时间支付宝所在机房不是就发生过光纤被挖么。

咱们全国大小城市都在疯狂的进行基建，修桥修路修房子，GDP就这么搞起来了，地下的光纤挖断几根不是再正常不过的事情了么，哈哈。

如果我们的服务全部都部署在单个机房，而机房又出故障了，那就没辙了。好在，现在大多数中大型项目都会采用多机房部署的方案，比如同城双活、异地多活等。一旦某个机房出现了故障不可用了，咱们立即采用切换路由的方式，把这个机房的流量切到其它机房里。

跨机房集群可用性风险：

既然都跨机房集群了，可用性理论上应该没啥问题啊。但要知道这是在物理层面没有问题了，如果咱们的代码有坑，或者因为特殊原因用户流量激增，导致我们的服务扛不住了，那在跨机房集群的情况下一样会不可用。但如果我们提前做好了「容错隔离」的一些方案，比如 限流、熔断 等等，用上这些方法还是可以保证一部分服务或者一部分用户的访问是正常。更多知识可在java架构师问答社区(ask.lubanjava.com)中查看。