主要观点总结
文章全面系统地介绍了高可用系统架构，从设计思想、架构原则到工程能力、服务管理等方面进行了深入剖析。文章首先通过海恩法则、墨菲定律等概念，强调人的素质和责任心在系统运行中的重要性。随后，文章提出了架构设计四高愿景，并讨论了为实现这些愿景所需的自动化系统目标。同时，文章也强调了个人学习实践和总结笔记，对架构设计的重要性。在代码架构高可用部分，文章探讨了代码架构规范、设计、编码、发布等阶段应注意的问题。在容量评估和规划部分，文章讨论了如何评估系统容量，并根据业务实际情况进行容量规划。在高可用系统架构设计部分，文章详细讨论了系统架构分层、接入高层可用设计、应用层高可用设计、服务分级治理、数据层架构、服务运营、高质量的服务管理以及能力和职责等关键方面。最后，文章通过总结强调了实现高可用架构设计的核心在于人的素质和责任心，以及明确架构师、运维/SRE、研发等角色应具备的能力。
关键观点总结
关键观点1: 高可用系统架构的重要性
文章从全局角度，全面系统地梳理了高可用系统架构，强调设计思想、架构原则、工程能力、服务管理的重要性。
关键观点2: 人的素质和责任心
通过海恩法则、墨菲定律等概念，强调人的素质和责任心在系统运行中的决定性作用。
关键观点3: 架构设计四高愿景
文章提出了架构设计四高愿景，包括高可用、高性能、高扩展、高效率，并讨论了为实现这些愿景所需的自动化系统目标。
关键观点4: 个人学习实践和总结笔记
强调了个人学习实践和总结笔记对架构设计的重要性，有助于形成系统的架构设计思路。
关键观点5: 代码架构高可用
讨论了代码架构规范、设计、编码、发布等阶段应注意的问题，强调了代码规范、单元测试、日志规范的重要性。
关键观点6: 容量评估和规划
解释了如何评估系统容量，并根据业务实际情况进行容量规划，包括容量评估、规划、性能压测等步骤。
关键观点7: 高可用系统架构设计
详细讨论了系统架构分层、接入高层可用设计、应用层高可用设计、服务分级治理、数据层架构、服务运营、高质量的服务管理以及能力和职责等关键方面，强调了架构师、运维/SRE、研发等角色应具备的能力。
正文
2.3 故障发现
系统都是研发人员设计和编码写出来的，因此首先要对研发层面有一个代码架构规范，例如编码规范、如果代码架构设计不足，就会造成影响全局的架构设计。例如我们之前一个系统，很多功能耦合在一个大单体应用里面，某个功能接口出现问题，就导致整个系统崩溃。
通过规范研发流程可以让我们更好地去研发和维护一个高可用的系统：
原则上新功能或者模块要有设计文档，
规范好相关方案设计文档的模板和提纲，让团队内部保持统一，例如
-
架构：
数据模型、接口定义；
-
流程：
正常流程、异常场景设计。
-
交叉影响：
配置接口、数据库、可靠性、性能等。
设计文档能够指导整个开发流程，包括编码、接口文档和测试用例，所有出现的问题都可以追溯到设计文档中。
设计文档是否需要评审：
新项目、重构项目、大的系统优化或者升级一定要评审。
遵循代码规范进行编码。
-
单元测试：
代码编写完需要有一定的单测能力来保证代码的健壮性，同时也能保障我们后续调整逻辑或者优化的时候可以保证代码的稳定。
-
日志规范：
对日志进行分类，错误日志和业务日志尽量分开存放，便于开发人员查看，也便于
通过日
志对系统进行及时监控。
要接入统一日志系统、能够做到分布式链路追踪。
-
代码安全：
借助代码分析工具，分析代码可能存在的 bug 或者安全漏洞。
1、
API 安全建议：
2、API 数据传输采用随机、不可预测、复杂的 Token 机制；
3、对 API 调用的数据、功能等实施严格访问控制，并严格设置白名单清单；
4、严格定义 API 输入数据类型，并校验、过滤所有传入数据；
5、对 API 的请求采用公开密码算法进行数字签名和校验；
6、加密 API 请求流量，可采用非对称加密算法逐个加密敏感信息字段，加密结果需做 Base64 编码等；
7、设置 API 请求频率限制策略。
系统灰度发布：确保故障不会造成大面积影响。
接口监控完善，确保及时发现发布过程可能存在的问题。
总结一下代码层面可能引发的故障/问题：
-
代码逻辑 bug。
-
超时配置不合理。
-
新老版本功能兼容性问题。
-
代码缺陷引发 core 或者内存溢出。
-
代码安全漏洞：如 sql 注入等。
-
日志不规范导致无法快速定位问题，小问题演变故障。
明确系统的业务场景，如果是管理工具平台相关，可能不太关注
QPS
相关指标。如果是应对业务系统，一般都要考虑 QPS 均值和峰值。
如果是新系统，可以先搜集产品和运营同学对业务的大体预估，可以大体估算出 QPS 相关指标。如果是老系统，那么就可以根据历史数据来评估。评估的时候，要从一个整体角度来看全局的量级，然后再细化到每个子业务模块要承载的量级。
是指系统在设计的时候，就要能够初步规划好系统大致能够维持的量级，比如是十万级还是百万级别的请求量，或者更多。不同量级对应的系统架构设计完全不一样。尤其到了千万、亿级别的量级的时候，架构设计会有更多的考量。
这里值得注意的是，不需要在一开始就设计出远超当前业务真实流量的系统，要根据业务实际情况来设计。同时，容量规划还涉及到：系统上下游的各个模块、依赖的存储、依赖的三方服务分别需要多少资源，需要有一个相对可量化的数据。容量规划阶段更多是要依靠自身和团队的经验，比如要了解系统的 log 的性能、redis 的性能、rpc 接口的性能、服务化框架的性能等等，然后根据各种组件的性能来综合评估已经设计的系统的整体性能情况。
容量评估和容量规划之后，还需要做就是性能压测。最好是能够做到全链路压测。
性能压测的目的：
-
一是确保系统的容量规划是否准确。如果系统规划的容量是能够抗千万级别的 QPS。那么实际上真的能够抗住吗 ？在上线之前首先要根据经验来判断，
-
其次是通过性能压测得暴露系统爆弱环节。
性能压测要关注的指标很多，但是重点要关注的是两个指标：一个是 QPS，一个是响应耗时要确保压测的结果符合预期。
我们中心的 SRE 压测任务：
建立常态化压测机制，使核心链路在目标 QPS 下保持稳定。
搭建压测平台
，定期根据实际现网请求生成源模块到目标流量的放大系数，测出不同业务资源占用率峰值，辅助容量评估。
为了降低应用服务管理的复杂性，我们把整个系统划分成若干个层次，每一层专注解决某个领域的问题，并向上提供服务。
典型架构分层设计如下：
按照功能处理顺序划分应用，这是面向业务深度的划分。同时禁止逆向调用。
每个公司的架构分层可能不一样，但是目的都是为了统一架构术语，方便团队内部沟通。
