为何使用云原生应用架构 二 ：独霸天下之四大绝技

Posted 2021-06-30 魏小言

文章目录

• 为何使用云原生应用架构 二 ：独霸天下之四大绝技
• • 安全是生产的第一要素
  • 如何才能做到即安全又快速呢？
  • • 可视化
    • 错误隔离
    • 容错
    • 自动恢复
  • Q&A
  • 附录

为何使用云原生应用架构 二 ：独霸天下之四大绝技

  上篇提到云原生架构让企业拥有绝对的敏捷力量，在市场竞争中具备优势！“ 四大绝技——速度 “ 使基于云原生架构的服务赋予了强劲的抗风险性的同时，创造了丰富的创新价值。

  然而，只是拥有了速度还是不够的！

安全是生产的第一要素

  在中国，无论是省道、国道、还是人流湍急的小城马路，“ 安全第一 ” 的警示牌随处可见。“ 安全是生产的第一要素 “ 不错，在互联网价值交付中，这一要义同样重要，尤其是在极速部署的状态下，安全变的更不可控。一旦失控，就会像油门踩到底的汽车一冲而出，必将付出惨痛的代价，甚至是致命的事故！

  在交通工业发展中，不同的交通工具设计的时候都会兼顾速度和安全性，云原生应用架构在追求快速变动的需求、稳定性和安全性之间也需要同时兼顾！

  那么我们如何才能做到即安全又快速呢？

如何才能做到即安全又快速呢？

  我们在前文提到了，如何迅速的从错误中恢复，未涉及如何预防错误，也就是安全保障。

  在企业中，在预防错误，确保安全的方面做足了功夫。方案评审、代码 CR 、单元测试、集成测试、回归测试…一系列的措施来预防错误，然而这一切都不能提供一致性的衡量生产缺陷度量！更是在追求速度上的拦路虎！最致命的是，这套流程执行完后，还是不能完全预防错误！

  云原生应用架构中，为了保障价值交付中的安全，绝技将出下面招式，接招吧！

可视化

  我们需要监测架构的可视化工具，监测架构中的一切数据，实时反应数据较基准「数据正常指标」之间的变化「包括绝对值、变化率」，以至于在发生故障时，第一时间能够进行问题定位，是什么组件/阶段导致了数据的差异。

  功能丰富的指标、监控、告警、数据可视化框架和工具是云原生应用架构的核心！

  在CNCF提供的解决方案中，Prometheus 作为全面拥抱云原生的监控系统可完全胜任，Prometheus 详细介绍及架构刨析可见之前的文章：普罗米修斯？古希腊泰坦之神？异性？不，新一代企业级监控组件——Prometheus！

错误隔离

  为了能够限制错误的影响范围，我们需要对可能受到错误组件和功能进行范围隔离。试想一下，若放弃隔离，一旦错误触发，将引起全盘故障。服务一旦停摆，将会是灾难性的。传统的单体架构往往就是这样的故障模型！

  云原生架构通常使用微服务设计，将全盘系统依据最小服务单元进行拆分，大转微治理，有效的将错误风险范围限制在最小服务单元中！但需结合必要的容错设计可完全隔离错误。

  错误隔离有许多变形，比如热点隔离或活动隔离，团队需支撑特殊规模「比如，大型晚会直播、传统节日庆祝活动…」的服务时，将会对流量进行完全隔离，整个功能链路由非日常生产环境完成，即能完全对规模服务进行隔离，又能更好的保障规模服务的稳定进行！ 类似的场景和解决方案还有很多，本文不做重点，将放在后面的文章详细讲解。

容错

  仅仅依靠服务拆分成微服务，进行错误隔离，还不够！我们需要为防止微服务将错误传递给所依赖它的上游服务，造成级联事故做容错处理！

  我们一般解决最常用的，也是最受欢迎的，容错措施就是 “ 断路器 ”。它在 Mike Nygard 的 《 Release It ! - Pragmatic Programmers 》 一书中，一些容错模型里有详细的介绍。简单来说，它的工作原理就像家庭线路里常用的保险丝或空气阀，在电流过载超过标准阈值时，将自动断开电路，确保用电安全。在架构中，断路器会自动断开错误模块与依赖之间的回路防止级联现象产生，同时会进行优雅的回退行为。这里的回退一般是指在提供服务中预设的降级方案措施。

  微服务加上容错的配合，可以完美的实现错误隔离，有效的进行安全管理。这其中错误的级联事故场景，典型的有重试机制。

  我们为确保服务的高可用性，将会对服务失败进行策略重试。某些策略如失败立即重试，在一些网络原因导致的服务失败场景中，采用这一策略则会导致全部失败；上游依赖服务将会进行再次重试造成级联现象。在整个链路中会形成重试 + 失败 + 服务超时 的局面！ 如何更好的设计重试策略，可以见上篇文章：你真的会重试吗？——重试之二进制指数退避机制 本文不做重点。

自动恢复

  凭借可视化工具、错误隔离、容错处理，我们已经拥有了确定错误的工具，从错误中快速恢复，并在错误检测和恢复中持续提供为客户提供不错的服务水平。 在对错误的采集梳理中，常规的一些错误，如服务器无心跳…往往呈现出相同且易于检测模式，且我们处理的方式极其一致，重启或重新部署。

  针对这种常规呈现模式化的错误，云原生架构提供了自动恢复的能力，将会依据相关的配置，进行自动的检测和自主的恢复。赋予架构自主思维能力或叫做自愈能力。

  有了这些招式，极大程度的进行错误预防及自主恢复处理。凭借速度、安全 两大招式，解决了软件交付的质量低与缩短周期长的问题。

  在业务飞速发展中，急需扩展的服务能力 和 规划基础设施最大负载 之间的冲突怎么解决呢？遇到规模活动需求，老是花钱买机器扩容，但平时资源闲置，试想一下，你的团队是如何解决的呢？

Q&A

1、Mike Nygard 流动解决问题专家、架构师

曾任Cognitect首席架构师，被誉为在线业务的“流动解决问题专家”。Nygard曾先后为美国政府、军队、银行、金融、农业和零售等多个行业交付过运营系统，这种实际运营的经历改变了他对软件架构的看法，也让他对在相当不友好的环境下构建高性能、高可靠性的软件有了独特的见解。他写过多篇文章和社论，是软件架构经典著作《架构之美》和《软件架构师需要知道的97件事》的作者之一。

2、四大绝技中有了绝佳的速度、安全，剩下的是那些呢？迫切渴望知晓！

下节将详细讲解 弹性扩展，请关注后续博文。

附录

信息、决策的及时上传下达，团队才能拧成一股劲。

欢迎加入Q群聊【编程技术交流分享群717647116】，微信群请私信博主添加