Azure 架构良好的框架是一组指导原则,可用于提高工作负荷的质量。 该框架包含卓越体系结构的五大要素:

结合这些要素可帮助创建高质量、稳定且高效的云体系结构:

构成要素 说明
可靠性 系统从故障中恢复并继续正常运行的能力。
安全性 保护应用程序和数据免受威胁。
成本优化 管理成本以便最大程度地提供实现的价值。
卓越运营 让系统在生产环境中持续运行的操作过程。
性能效率 系统适应负载变化的能力。

互联网产品的架构评估——可用性、可靠性、可维护性、安全性

软件的核心是指核心业务和实现核心业务的相关技术,本文总结出互联网产品的架构评估检查表,以便在产品上线前做架构核查。

https://www.thoughtworks.com/zh-cn/radar

https://www.thoughtworks.com/zh-cn/radar/techniques?blipid=1298

https://docs.microsoft.com/zh-cn/azure/architecture/

3+1保障:高可用系统稳定性是如何炼成的?

一 概述

自己以及带领的团队曾经负责较多不同类型的互联网服务系统,如几十万应用数&亿级流量的云计算平台、年营收将近千亿的广告系统、亿级用户千万级日活的钉钉工作台系统、亿级交易额的钉钉市场&交易系统、算法在线离线工程系统等相关系统或子系统,整体而言无重大故障,达到定级故障数也很少,线上稳定性保障在一个不错的水位上。阶段性总结下我从团队技术负责人视角做好稳定性建设的实践性思考和简要思路,为感兴趣的技术同学提供一个实践指南。
我的团队稳定性建设思路包括了3大技术要素:良好的系统架构和实现、完备的团队研发运维流程机制、技术同学良好意识和能力,以及1个业务要素:良好的研发项目管理。

image.png

这是我经常问的一个问题,无论是在面试一些高P的时候,还是在晋升答辩当评委的时候。绝大多数啊的答案是:限流、降级、熔断。但是,成体系性的答案,基本上很少有人说出来。
首先,什么是系统可靠性(Reliability)和可用性(Availability)?而什么又是系统稳定性(Stability)?
系统可靠性:高可靠的系统,故障次数少,频率低,在较长的时间内无故障地持续运行。
系统可用性:高可用的系统,故障时间少,止损快,在任何给定的时刻都可以及时地工作。
举个“分布式系统原理与范型”书的第八章的例子:
如果系统在每小时崩溃1ms,那么它的可用性就超过99.9999%,但它还是高度不可靠的。
如果系统从来不崩溃,但要在每年八月中停机两个星期,那么它是高度可靠的,但是系统的可用性只有96%。
系统稳定性,则是在系统可靠性和可用性之上,即降低故障频次和提升止损速度的情况下,要求系统的性能稳定,不要时快时慢。

换言之,我不但需要系统尽可能地随时可以给我提供服务,并且,我希望系统能给我提供有质量保障的服务。
那么,回到最初的问题,基于系统稳定性建设,我们可以做哪些事情?

https://developer.aliyun.com/article/778248
https://developer.aliyun.com/article/778248

https://awps-assets.meituan.net/mit-x/slide-bundle-2018-2/45/3-%E7%BE%8E%E5%9B%A2%E7%A8%B3%E5%AE%9A%E6%80%A7%E4%BF%9D%E9%9A%9C%E5%B9%B3%E5%8F%B0Rhino.pdf

https://jimmysong.io/kubernetes-handbook/cloud-native/cloud-native-philosophy.html

https://mp.weixin.qq.com/s/NIu95lFJszpXcoIw6h3Lyg

SRE(Site Reliability Engineering),网站稳定性工程,最早是由 Google 设置的一类工程师岗位,专职负责其超大规模分布式产品(如搜索、Gmail、Docs 等)的稳定性。而后,SRE 慢慢发展成了一系列面向稳定性的,包括技术、管理、流程、组织架构,以及文化建设的最佳实践,并最终被提炼成一套方法论,广泛流传。