高可用是一种面向风险设计，使系统具备控制风险，提供更高的可用性的能力。从概率学上讲，凡是可能出错的，随着次数的增加，出错将是不可避免的，这时我们就需要预先对各种风险作出评估，通过种种手段抑制避免这些风险，保障服务的可用性。 云原生和微服务虽然很好，具有灵活可拓展等一系列的优点，但想要做到高可用，还需要做很多努力，我们从控制风险、问题追踪、故障解决三个方面来讲：
-
控制风险 控制风险有四大因素：
-
减少风险数量：从源头上减少风险，比如外面下雨你不出门，那你就没有被雨淋的风险； -
降低风险变成故障的概率：比如在任何可能阻塞业务的代码中加入错误冗余处理使其不阻塞其他业务； -
减少故障的影响范围：把整体业务拆成一个个微服务，某个服务挂掉了，不会影响其他服务的正常运行； -
缩短故障影响时长：事前做好预警工作、平时做好监控工作、有充分的预案和灾备、事后做好复盘，能自动化的操作尽量自动化，需要人工的操作尽量一键化，比如一键切换、一键回滚、一键扩容等等。
Authing 为了避免风险作出了诸多努力：在测试前会使用 Sonar 等工具检查代码质量、每次上线前都会进行多轮的冒烟测试、对于线上还会有定时的自动化测试脚本，一旦某个环节出了问题，就会自动预警以及时修复等等。
-
问题追踪 平时要做好监控，发现问题才好追踪。对于云原生应用来讲，需要保证各个层面都有监控，日志集中管理，出现问题才好随时复盘，还应利用好各种工具来检测服务和集群的各项指标，出现问题前及时预警。 Authing 采用了 prometheus 、 grafana 等工具实时检测服务的各项指标，前端也做了相关埋点工作，并在各个层次和维度上记录了详细的日志统一管理，从开发、提测到上线，每一个节点都有记录了明细的相关文档可以追踪，这样可以保证及时预警避免事故发生，即便出了事故也可以快速定位修复问题。
-
故障解决 即便做了这样或那样的努力，有时候还是无法避免故障的发生，这时候就要尽快解决问题。在平时做了充分监控和记录的前提下，查阅日志和监控记录，复线问题，定位代码以找到错误并修复问题的速度就至关重要了。
Authing 采用了微服务架构，当问题出现时我们可以快速定位哪个模块出了问题，根据已有的日志和监控，快速定位、复现问题并解决问题，事后通过复盘避免类似事故的再次发生。
Authing 作为 SaaS 产品一直致力于提高自己的可用性，给客户更好的体验，我们会不断优化自己的架构，不断实践，不断进步。
