微信公众号关联网站,怎么把自己的网站放到网上,app开发费用报价表,如何查看网站图片尺寸架构设计的愿景就是高可用、高性能、高扩展、高效率。为了实现架构设计四高愿景#xff0c;需要实现自动化系统目标#xff1a; 标准化。 流程自助化。 可视化#xff1a;可观测系统各项指标、包括全链路跟踪。 自动化#xff1a;ci/cd 自动化部署。 精细化#xff1a…
架构设计的愿景就是高可用、高性能、高扩展、高效率。为了实现架构设计四高愿景需要实现自动化系统目标 标准化。 流程自助化。 可视化可观测系统各项指标、包括全链路跟踪。 自动化ci/cd 自动化部署。 精细化监控平台、数据分析精细化。
要实现这些在中小型公司架构师可以 hold 住而在大企业/大厂里面虾兵蟹将是无法搞定的至少是 vp 级别来推动。
整个自动化体系需要多平台、系统、工具来解决各类场景的自动化执行各个平台之间要相互联动形成体系化而不是相互脱离各自发展。目前还没看到一站式平台可以串接需求、设计、开发、测试、发布、运维等而高可用系统架构设计要从产品、开发、运维、硬件等全方位去统筹综合考虑形成一体化。 一、可用性 1.1 业务可用性指标
所谓业务可用性(availability)也即系统正常运行时间的百分比架构组/SRE 最主要的 KPI (Key Performance Indicators 关键业绩指标)。对于我们提供的服务web/api来说现在业界更倾向用 N 个 9 来量化可用性最常说的就是类似“4个9(也就是99.99%)”的可用性。 故障时间故障修复时间点-故障发现报告时间点
服务年度可用时间%1-故障时间/年度时间× 100%。 1.2 故障的度量与考核
对管理者/部门而言可用性是产品的整体考核指标。对于研发工程师而言使用故障分来考核
类别描述权重高危S级事故故障一旦出现故障可能会导致服务整体不可用100严重A级故障客户明显感知服务异常错误的回答20中级B级故障客户能够感知服务异常响应比较慢5一般C级故障服务出现短时间内抖动1
考核指标可以使用故障分度量故障分故障时间分钟* 故障级别权重。 1.3 服务分级
如果是一个分布式架构设计系统由很多微服务组成所有的服务可用性不可能都是统一的标准。
为了提高我们服务可用性我们需要对服务进行分类管理并明确每个服务级别的可用性要求。
类别服务可用性要求描述一级核心服务核心产品或者服务99.99%全年53分钟不可用系统引擎部分一旦出现故障整个系统瘫痪二级重要服务重要的产品功能99.95%全年260分钟不可用类比汽车轮子该服务出现问题该重要功能不可用。三级一般服务一般功能99.9%全年8.8小时不可用类比汽车倒车影像该部分出现问题稍微影响用户体验四级工具服务工具类是服务0.99非业务功能比如爬虫、管理后台、运维工具
二、高可用架构设计总体思想
高可用系统的架构设计要从产品需求、代码开发、运维部署、故障管理等系统全生命周期进行全方位去考量和设计核心思想就是 故障事前故障预防总结经验做到有智慧的绕开问题。 故障发现及时发现通过完善观测平台及时发现问题吧。 故障恢复快速恢复做好应急预案降低故障影响。 故障总结复盘总结故障问题层层剖析问题产生的原因由表及里分析问题发生的本质。
高可用系统的架构设计思想包括但不限于 2.1 系统设计 产品层面主要是故障发生后的兜底策略等。例如生成式大模型考虑远程代码执行漏洞设计时尽量避免将用户输入内容作为代码部分进行执行如需执行需要将服务部署在经过安全隔离的环境中。 代码架构系统都是研发人员设计和编码写出来的因此首先要对研发层面有一个代码架构规范例如编码规范、如果代码架构设计不足就会造成影响全局的架构设计。同时借助代码分析工具分析代码可能存在的 bug 或者安全漏洞例如对于业务设计需要将用户输入内容作为代码部分进行执行需要应用程序做安全防范。 做好容量规划和评估主要是让开发人员对系统要抗住的 QPS 量级有一个基本认知方便后续进行合理的架构设计和演进。 2.2 故障预防 应用层面的高可用预防主要是负载均衡、弹性扩缩容、异步解耦、故障容错、过载保护等。 数据层面的高可用预防主要是冗余备份热备冷备、失效转移确认转移恢复等。 模块变更机制预防核心模块变更、新数据集、模型上线、流程变更、新模块、核心 sdk 变更等上线的规范化与审批。 模块健康度系统查询系统健康状态如调模块调用情况、资源使用情况、进程情况、服务处理状态等快速判断故障模块是否异常。我们健康检查系统是通过拉取各个运营系统容量系统、变更系统、监控系统等的模块各项指标数据结合历史故障数据分析模块可能存在的异常。 2.3 故障发现 运维层面发现主要是发布测试、监控告警、容灾、故障演练等。 完善报警治理四五星报警周期治理优化指标报警方式完善新指标提高报警的准确率、可靠性、时效性。 故障大屏全面了解整个业务的健康状况。 2.4 故障恢复 制定《故障管理规范》 做好故障应急预案建设大招平台针对特定故障建立相应应急预案在出现故障后使用相应的应急预案进行快速恢复最大程度降低影响范围。 切流系统工具可用区/IDC 出现故障问题可以切流到其他可用区。 2.5 故障总结 故障复盘复盘总结每个故障问题层层剖析问题产生的原因由表及里分析问题发生的本质。 故障汇总进行故障分类、定级、影响等如果系统组够大当然需要故障管理系统来管理。 三、代码架构高可用
系统都是研发人员设计和编码写出来的因此首先要对研发层面有一个代码架构规范例如编码规范、如果代码架构设计不足就会造成影响全局的架构设计。例如我们之前一个系统很多功能耦合在一个大单体应用里面某个功能接口出现问题就导致整个系统崩溃。
通过规范研发流程可以让我们更好地去研发和维护一个高可用的系统 3.1 制定研发规范和原则 设计文档评审原则例如新项目重构项目的设计文档一定要评审通过评审及时发现问题。 遵守代码架构规范包括编码规范、项目层次规范、模块规范、依赖规范等。工程的顶层目录结构设计规范团队内部保持统一尽量简洁提高代码的可维护性。遵循团队内部的代码规范 代码规范可以大大减少 bug 并且提高可用性。 3.2 设计阶段
原则上新功能或者模块要有设计文档规范好相关方案设计文档的模板和提纲让团队内部保持统一例如 架构数据模型、接口定义 流程正常流程、异常场景设计。 交叉影响配置接口、数据库、可靠性、性能等。
设计文档能够指导整个开发流程包括编码、接口文档和测试用例所有出现的问题都可以追溯到设计文档中。
设计文档是否需要评审新项目、重构项目、大的系统优化或者升级一定要评审。 3.3 编码阶段
遵循代码规范进行编码。 单元测试代码编写完需要有一定的单测能力来保证代码的健壮性同时也能保障我们后续调整逻辑或者优化的时候可以保证代码的稳定。 日志规范对日志进行分类错误日志和业务日志尽量分开存放便于开发人员查看也便于通过日志对系统进行及时监控。要接入统一日志系统、能够做到分布式链路追踪。 代码安全借助代码分析工具分析代码可能存在的 bug 或者安全漏洞。 1、API 安全建议 2、API 数据传输采用随机、不可预测、复杂的 Token 机制 3、对 API 调用的数据、功能等实施严格访问控制并严格设置白名单清单 4、严格定义 API 输入数据类型并校验、过滤所有传入数据 5、对 API 的请求采用公开密码算法进行数字签名和校验 6、加密 API 请求流量可采用非对称加密算法逐个加密敏感信息字段加密结果需做 Base64 编码等 7、设置 API 请求频率限制策略。 3.4 线上发布阶段
系统灰度发布确保故障不会造成大面积影响。
接口监控完善确保及时发现发布过程可能存在的问题。
总结一下代码层面可能引发的故障/问题 代码逻辑 bug。 超时配置不合理。 新老版本功能兼容性问题。 代码缺陷引发 core 或者内存溢出。 代码安全漏洞如 sql 注入等。 日志不规范导致无法快速定位问题小问题演变故障。
四、容量评估和规划 4.1 容量评估
明确系统的业务场景如果是管理工具平台相关可能不太关注 QPS 相关指标。如果是应对业务系统一般都要考虑 QPS 均值和峰值。
如果是新系统可以先搜集产品和运营同学对业务的大体预估可以大体估算出 QPS 相关指标。如果是老系统那么就可以根据历史数据来评估。评估的时候要从一个整体角度来看全局的量级然后再细化到每个子业务模块要承载的量级。 4.2 容量规划
是指系统在设计的时候就要能够初步规划好系统大致能够维持的量级比如是十万级还是百万级别的请求量或者更多。不同量级对应的系统架构设计完全不一样。尤其到了千万、亿级别的量级的时候架构设计会有更多的考量。
这里值得注意的是不需要在一开始就设计出远超当前业务真实流量的系统要根据业务实际情况来设计。同时容量规划还涉及到系统上下游的各个模块、依赖的存储、依赖的三方服务分别需要多少资源需要有一个相对可量化的数据。容量规划阶段更多是要依靠自身和团队的经验比如要了解系统的 log 的性能、redis 的性能、rpc 接口的性能、服务化框架的性能等等然后根据各种组件的性能来综合评估已经设计的系统的整体性能情况。 4.3 性能压测
容量评估和容量规划之后还需要做就是性能压测。最好是能够做到全链路压测。
性能压测的目的 一是确保系统的容量规划是否准确。如果系统规划的容量是能够抗千万级别的 QPS。那么实际上真的能够抗住吗 在上线之前首先要根据经验来判断 其次是通过性能压测得暴露系统爆弱环节。性能压测要关注的指标很多但是重点要关注的是两个指标一个是 QPS一个是响应耗时要确保压测的结果符合预期。
我们中心的 SRE 压测任务建立常态化压测机制使核心链路在目标 QPS 下保持稳定。
搭建压测平台定期根据实际现网请求生成源模块到目标流量的放大系数测出不同业务资源占用率峰值辅助容量评估。
五、高可用系统架构设计 5.1 架构分层
为了降低应用服务管理的复杂性我们把整个系统划分成若干个层次每一层专注解决某个领域的问题并向上提供服务。
典型架构分层设计如下按照功能处理顺序划分应用这是面向业务深度的划分。同时禁止逆向调用。
每个公司的架构分层可能不一样但是目的都是为了统一架构术语方便团队内部沟通。 接入层主要流量入口经过简单 应用层直接对外提供产品功能例如网站、API 接口等。应用层不包含复杂的业务逻辑只做呈现和转换。 服务层根据业务领域每个子域单独一个服务分而治之。 数据层数据库和 NoSQL文件存储等。 我们先列出目前我们系统有哪些环节,每个环节是否薄弱. 客户端访问服务器端经过很多环节任何环节出问题都不能访问
接入层 dns 被劫持域名是否使用 https。 黑客攻击是否有弱密服务器权限数据库权限。 ddos 攻击是否有必要使用高防 IP 接入流量。 CC 攻击免费和收费版域名分开网关是否有限流和防刷措施。
应用层/服务层 服务代码 bug。 服务引发 core/内存溢出。 依赖第三方服务不可用。 自身没有做好监控告警不能及时发现问题。 上线变更操作导致故障。 流量过载导致服务不可用。 服务没有做好性能压测无法应对流量高峰影响。
数据层 数据一致性问题。 数据误操作如误删除。 数据库损坏如服务器磁盘损坏导致数据库不可用等。
整体架构层 服务器故障。 系统整体架构容量规划不合理无法应对流量高峰影响。 缺少切流工具无法降低故障影响。 5.2 接入高层可用设计
在接入层这里主要是架构运维的高可用要求的事项 域名高可用 域名规范解析和规范化管理应该制定《域名规范管理说明》例如根据产品重要等级制定使用高防 IP 的策略。 域名解析 DNS 防劫持必须使用 https。 ddos 攻击是否有必要使用高防 IP 接入流量。 规范 API 管理 明确各个 API 限流和防刷策略。
接入层架构参考 当系统对外的接口繁多同时不同的项目不同的接口没有一个统一管理的系统也不方便监控和跟踪 api 的健康状况。需要 api 网关方便 api 日常管理包括控版本管理升级回滚。 更重要的是 api 网关起到限流防刷CC 攻击作用保护后端服务。 5.3 应用层高可用设计 5.3.1 应用层设计主要原则 可以水平扩展通过接入层的负载均衡实现故障自动转移。 无状态设计无状态的系统更利于水平扩展更利于做负载均衡。状态是系统的吞吐量、易用性、可用性、性能和可扩展性的大敌要尽最大可能避免。 回滚设计 确保系统可以向后兼容如果应用服务上线后出现 bug可以紧急回滚。 灰度发布结合接入层设计 A/B 功能实现灰度发布比如按 ip请求参数等分发流量。 幂等设计系统中的多次操作不管多少次都应该产生一样的效果或返回一样的效果。 调用设置超时调用服务一旦超时通信框架应该返回异常调用方根据调度策略选择重试或者请求转移。 异步调用调用不重要的服务同步变为异步。 降级处理服务具备降级能力。 运行环境隔离对于生成式大模型的远程代码执行设计原则在独立且无敏感数据的环境中执行代码任务同时限制资源任务执行完成后将环境销毁。 5.3.2 应用服务可能存在异常的情况 服务内部出错、异常。 服务响应超时。 服务负载过高 网络链路延迟或中断 服务依赖链中部分依赖 SLA 不达标造成整体服务不可用 服务链条过长造成 SLA 整体不可控 5.3.3 提高服务可用性机制
解决的思路服务分级治理、服务隔离、自我保护、失效转移或恢复、服务降级。 服务分级治理将服务分级管理对于核心/重要的使用更好硬件并隔离部署避免连锁的故障响应。 服务隔离措施依据服务重要性分级或流量特点、用户画像等从物理上隔离服 务。将服务使用的资源CPU、线程、IO 等隔离主要使用舱壁模式比如核心服务单独部署三级服务可以混合部署。 自我保护措施快速失败(failfast)、限流、调用超时、熔断Resilience4j 失效转移机制失效检测、失效重试、失效转移(failover)、失效恢复failback) 服务降级措施在流量高峰服务可能由于大量的并发调用导致性能下降最后引起服务不可用。为了保证网络和核心流程可用需要服务降级。
依据依赖服务的重要性或依赖程度强、弱实行相应服务降级手段 同步变异步低优先级服务调用同步变异步比如日志存储等。 降级开关拒绝部分服务通过流量网关做相应的限流甚至直接拒绝服务。 5.3.4 具体容错机制说明
1、failover失效转移失败自动切换”是一种备份操作模式。
Fail-Over 失效转移是一种备份操作模式当主要组件异常时其功能转移到备份组件。其要点在于有主有备主故障时系统能够自动地切换到备用服务上, 保证服务继续运行。比如内部调用 nginx 代理不能是单点提供服务需要有主备模式通过 keep-alive 机制自动切换到备用服务上。核心和重要服务都需要按 N1 原则部署。通常用于读操作
2、failfast快速失败快速识别就是只发起一次调用失败后立即报错。
fail-fast 是“快速失败”尽可能的发现系统中的错误使系统能够按照事先设定好的错误的流程执行对应的方式是“fault-tolerant错误容忍”。以 JAVA 集合Collection的快速失败为例当多个线程对同一个集合的内容进行操作时就可能会产生 fail-fast 事件。例如当某一个线程 A 通过 iterator 去遍历某集合的过程中若该集合的内容被其他线程所改变了那么线程 A 访问集合时就会抛出 ConcurrentModificationException 异常发现错误执行设定好的错误的流程产生 fail-fast 事件。通常用于非幂等性的写操作
3、failback故障自动恢复故障转移Fail-Over之后服务能够自动恢复。
Fail-over 之后的自动恢复在簇网络系统有两台或多台服务器互联的网络中由于要某台服务器进行维修需要网络资源和服务暂时重定向到备用系统。在此之后将网络资源和服务器恢复为由原始主机提供的过程称为自动恢复。
4、failsafe失效安全出现异常时直接忽略。即使发生了故障也不会对系统/服务造成伤害或尽量减少伤害。
Fail-Safe 的含义为“失效安全”即使在故障的情况下也不会造成伤害或者尽量减少伤害。维基百科上一个形象的例子是红绿灯的“冲突监测模块”当监测到错误或者冲突的信号时会将十字路口的红绿灯变为闪烁错误模式而不是全部显示为绿灯。通常用于写入审计日志等操作
5、接口幂等设计
应用调用服务失败后会将请求重新转发到其他服务上这个时候要进行幂等性的判断有可能服务调用失败是网络问题导致的实际上业务处理成功了。 5.4 服务分级治理
服务层设计最主要原则服务分级管理。
线上有很多服务每个服务的可用性要求不一样我们需要先这些服务做分级。 各级服务的部署原则核心服务独立服务器且 N1 部署。三级和四级服务可以共享服务器部署。 各级服务上线发布原则核心和重要服务晚上12点上线。三级和四级随时可上线。 各级服务监控原则。
一级核心服务
定义
可用性:99.99%极高可用性全年53分钟不可用。
条件 服务自身可用性99.99%。 依赖数据资源服务可用性要求应用服务研发方自定义。 依赖第三方服务可用性要求应用服务研发方自定义。 需要部署的服务器数N 台。
服务设计满足以下原则 冗余 N1 部署故障自动转移到多部署一个节点避免单点问题。 可监控服务流量预警、端口存活、进程占用的资源、服务接口功能逻辑是否正常应用 FGC 等情况。 可回滚、灰度灰度部署服务部署的服务出现问题可快速回滚。 可独立部署可以直接在运维平台打包部署而不需要依赖其他服务部署完成后才能部署运行。 可独立测试可以单独测试。 水平扩展流量激增可快速扩容。 异步设计服务需要通知第三方服务必须通过消息队列进行异步方式完成。 幂等设计服务可以重复调用不影响结果。 可容错自身有容错和修复能力 隔离手段服务使用的资源CPU、线程、IO 等隔离使用舱壁模式 自我保护手段快速失败(failfast)、流控、超时、熔断 失效转移或恢复手段失效检测、重试、转移(failover)、回退恢复failback) 降级手段依据依赖服务的重要性或依赖程度强、弱,同步变异步降级开关、拒绝部分服务等。
二级重要服务
定义
可用性99.95%故障具备自动恢复的能力全年260分钟不可用。
条件 服务自身可用性99.95%。 依赖数据资源服务可用性要求应用服务研发方自定义。 依赖第三方服务可用性要求应用服务研发方自定义。 需要部署的服务器数N 台。
服务设计满足以下原则 冗余 N1 部署故障自动转移到多部署一个节点避免单点问题。 可监控监控进程、端口存活、进程占用的资源应用 FGC 等。 可回滚、灰度灰度部署服务部署的服务出现问题可快速回滚。 故障隔离服务器只部署唯一该应用服务该应用服务出现问题只影响自身服务问题。 可独立部署可以直接在运维平台打包部署而不需要依赖其他服务部署完成后才能部署运行。 可独立测试可以单独测试。 水平扩展流量激增可快速扩容。 可容错自身有容错和修复能力。
三级一般服务
定义
可用性99.9%全年8.8小时不可用。
条件 服务自身可用性99.95%。 依赖数据资源服务可用性要求应用服务研发方自定义。 依赖第三方服务可用性要求应用服务研发方自定义。 需要部署的服务器数N台。
服务设计满足以下原则 冗余 N1 部署可以单点部署。 可监控可监控服务进程、端口存活是否正常。 可回滚、灰度灰度部署服务部署的服务出现问题可快速回滚。 故障隔离一个服务器上可以部署多个应用但保证服务器资源充足。 可独立部署需要独立部署。 可独立测试可以单独测试。 水平扩展流量激增可快速扩容。 可容错需要具备一般的容错能力。
四级工具服务
定义
可用性99.9%全年8.8小时不可用。
条件 服务自身可用性99.9%。 依赖数据资源服务可用性要求应用服务研发方自定义。 依赖第三方服务可用性要求应用服务研发方自定义。 需要部署的服务器数N 台。
服务设计满足以下原则 冗余 N1 部署可以单点部署进程存活就可以。 可监控不需要监控。 可回滚、灰度只要部署成功就可以。 故障隔离哪个服务器有资源就可以部署。 可独立部署不用考虑。 可独立测试不用考虑。 水平扩展不用考虑。 可容错不用考虑。
六、高可用的数据层架构
数据是最宝贵的资产。
数据存储高可用主要手段是冗余备份和失效转移机制。数据备份是保证数据有多副本任意副本的失效都不会导致数据的永久丢失。从而实现数据完全的持久化。而失效转移机制是保证当一个数据副本不可访问时可以快速切换访问数据的其他副本。保证数据可用。 6.1 数据架构设计原则 6.2 数据一致性设计
分布式的 CAP 理论
在一个分布式系统中Consistency一致性、 Availability可用性、Partition tolerance分区容错性最多只能同时三个特性中的两个三者不可兼得。 C 一致性Consistency说的是每一个更新成功后分布式系统中的所有节点都能读到最新的信息。即所有节点相当于访问同一份内容这样的系统就被认为是强一致性的。 A 可用性Availability是每一个请求都能得到响应。请求只需要在一定时间内返回即可结果可以是成功或者失败也不需要确保返回的是最新版本的信息。 P 分区容错性Partition tolerance是说在网络中断消息丢失的情况下系统照样能够工作。这里的网络分区是指由于某种原因网络被分成若干个孤立的区域而区域之间互不相通。
在非金融的互联网分布式应用里面主机多数据大部署分散。所以节点故障网络故障是常态。一般是为了保证服务可用性而舍弃一致性 C。即保证 AP。
分布式的 BASE 理论
BASE 理论它是在 CAP 理论的基础之上的延伸。包括基本可用Basically Available、柔性状态Soft State、最终一致性Eventual Consistency。 基本可用分布式系统出现故障的时候允许损失一部分可用性。比如阿里双十一大促的时候对一些非核心链路的功能进行降级处理。 柔性可用允许系统存在中间状态这个中间状态又不会影响系统整体可用性。比如数据库读写分离写库同步到读库主库同步到从库会有一个延时这样实际是一种柔性状态。柔性事务和刚性事务对立刚性事务也叫强一致性比如 ACID 理论。 最终一致性例如数据库主从复制经过数据同步延时之后最终数据能达到一致。
柔性事务(遵循 BASE 理论)放弃了隔离性减小了事务中锁的粒度使得应用能够更好的利用数据库的并发性能实现吞吐量的线性扩展。异步执行方式可以更好的适应分布式环境在网络抖动、节点故障的情况下能够尽量保障服务的可用性 (Availability)。因此在高可用、高性能的应用场景柔性事务是最佳的选择。
柔性事务对 ACID 的支持 原子性严格遵循。 一致性事务完成后的一致性严格遵循事务中的一致性可适当放宽。 隔离性并行事务间不可影响事务中间结果可见性允许安全放宽。 持久性严格遵循。
在业内关于柔性事务最主要的有以下四种类型 两阶段型就是分布式事务两阶段提交对应技术上的 XA、JTA/JTS。这是分布式环境下事务处理的典型模式。 补偿型TCC 型事务Try/Confirm/Cancel可以归为补偿型。服务器A 发起事务服务 B 参与事务服务 A 的事务如果执行顺利那么事务 A 就先行提交如果事务 B 也执行顺利则事务 B 也提交整个事务就算完成。但是如果事务 B 执行失败事务 B 本身回滚这时事务 A 已经被提交所以需要执行一个补偿操作将已经提交的事务 A 执行的操作作反操作恢复到未执行前事务 A 的状态。这个需要服务 A 可以幂等操作。 异步确保型将一些同步阻塞的事务操作变为异步的操作避免对数据库事务的争用。 最大努力通知多次尝试交易的消息通知与失败重试例如商户交易结果通知重试、补单重试 6.3 完善的数据备份和恢复机制
完善的数据备份和恢复机制能力在发生数据丢失的时候可以使用备份快速恢复。 七、服务运营
运营层面主要故障总结 运营操作失误 缺乏应急机制。 缺乏故障处理机制。 缺乏故障演练导致切流后引发更大故障。
具体措施 7.1 故障预防
1、灰度发布
服务发布上线的时候要有一个灰度的过程。先灰度 1-2 个服务实例然后逐步放量观察。
A/B 测试就是一种灰度发布方式指为产品已发布 A 版本在发布 B 版本时在同一时间维度让一部分用户继续用 A 版本一部分用户开始用 B 版本如果用户对 B 版本没有什么反对意见那么逐步扩大范围把所有用户都迁移到 B 版本上面来。灰度发布可以保证整体系统的稳定在初始灰度发布时就可以发现及调整问题以保证其影响度。
通过灰度发布降低发布影响面和提升用户体验就算出问题也只会影响部分用户从而可以提前发现新版本中的 bug然后在下一次发布前提前修复避免影响更多用户
灰度发布的主要分类 金丝雀发布在原有部署版本可用的情况下,同时部署新版本应用作为金丝雀。 滚动发布一般是取出一个或者多个服务器停止服务执行更新并重新将其投入使用。周而复始直到集群中所有的实例都更新成新版本。 蓝绿发布蓝绿部署是不停老版本部署新版本然后进行测试。确认 OK 后将流量切到新版本然后老版本同时也升级到新版本。
2、容灾备份部署 备份数据备份热备冷备冗余异地 过载保护 同城多活-》异地多活 流量切换 重试防雪崩概率很小成本很高
3、故障演练
故障演练是应用高可用能力测评的核心 通过例行化故障演练、找出系统风险点、优化业务系统、产出可行有效的故障处理预案。 7.2 完善的服务故障发现
1、监控告警机制
在高可用服务设计章节提到核心服务可以监控服务流量预警、端口存活、进程占用的资源、服务接口功能逻辑是否正常应用 FGC 等情况需要一个完善监控告警机制并在告警后通过一定的策略进行处理以致服务可以快速恢复。例如监控 FGC如果在一分钟内存出现10次 FGC自动重启服务。 网络流量监控 。 系统监控服务器资源和网络相关监控CPU、内存等 。 日志监控统一日志收集各个服务监控跟踪(log2) 。 应用监控端口存活、进程占用的资源应用 FGC 等情况。 业务监控服务接口功能逻辑是否正常。 立体监控监控数据采集后除了用作系统性能评估、集群规模伸缩性预测等 最终目标是还可以根据实时监控数据进行风险预警并对服务器进行失效转移自动负载调整最大化利用集群所有机器的资源。
2、全链路观测平台
构建服务全链路观测能力并有效降低 MTTR 各项指标。
掌握数据分析方法构建数据服务指标有效评估业务整体服务质量沉淀一般通用指标方案能成功复用到其他项目。 八、高质量的服务管理 服务规范管理CMDB 对项目、服务、服务器进行统一管理。 代码质量管理通过 ci 工具流程快速检测代码规范和安全隐患。 自动化发布发布不影响用户完善发布流程自动化发布可以及时回滚 。 自动化测试上线完成后进行全面自动化测试。 性能压测通过对服务压测了解服务可以承载并发能力以致可以让运维通过预警进行服务器扩容 。 代码控制测试环境使用测试分支beta 环境发布 tag线上使用该 tag 发布。 发布流程规范上线发布流程。 灰度发布灰度发布服务 。 应急处理机制 。 故障处理规范。 形成闭环管理有迹可循来源可溯、去向可查等完整的生命周期管理。 九、能力和职责
海恩法则提到再好的技术、再完美的规章 在实际操作层面也无法取代人自身的素质和责任心 。
因此要做到高可用的架构设计职责也要清晰明确要不然出现问题相互推诿问题解决进度很慢会直接影响业务服务可用性。 9.1 职责清晰明确
1、架构师职责 高可用架构设计包括业务流程模块划分组合框架设计流程纰漏最后架构设计技术实现步骤。系统性的思考权衡利弊综合各种因素设计出具有前瞻性的架构。 和运维协调沟通提出高效的服务治理解决方案把控服务质量管理。 协调沟通开发之间沟通产品之间沟通市场沟通运维沟通、沟通后产出图形化文档及设计。 规范和统筹保证系统秩序统一规范稳定高效运行。
2、运维/SRE 职责 熟悉系统技术架构和架构师制定各种规范化要求。 和架构师共同协调沟通对系统架构提出可靠性伸缩扩展数据库切分缓存应用等解决方案。 提供监控系统自动化发布系统代码管理文档平台自动运维平台等基础设施 制定运维规范。 建立运维安全体系。 建立容灾备份体系。
3、研发职责 参与架构师的架构师设计并根据设计实现具体细节。 针对开发功能进行自测压测。 开发代码使用工具或组件符合架构师制定规范。包括代码规范、文档规范。 代码部署符合运维部署规范要求。 9.2 作为架构师/SRE 具备能力
人的能力素质是解决问题的根本
作为架构师需要能力
具备对操作系统、容器技术、网络大型分布式微服务架构深入理解和实践经验。能理解业务的可靠性需求转化为技术指标运用云原生、混沌工程、全链路压测等技术手段建立业务的可观测提升业务的 MTBF(平均故障间隔时间 Mean Time Between Failure)、降低 MTTR(平均修复时间 Mean time to repair)通过系统与数据能力不断帮助业务取得成功。
自动化体系建设能力
能对日常发布、变更工作、容量规划进行主动的自动化体系建设并能沉淀指导方法有效指导多业务建设。
掌握故障预防和发现技巧
掌握通过构建和实施全链路压测和混沌工程等故障预防手段提升 MTBF。
掌握通过构建和实施系统异常检测和监控告警机制等故障发现手段降低 MTTI。
构建观测平台能力
具备构建服务全链路观测能力并有效降低 MTTR 各项指标。
精通数据分析方法构建数据服务指标有效评估业务整体服务质量沉淀一般通用指标方案能成功复用到其他项目。
技术深度能力性能分析基础扎实深入底层
能多维度的分析业务的性能瓶颈通过架构调整内核、软件参数等手段调优沉淀一般通用性调优方案。
技术广度能力
理解云原生相关技术与生态能指导业务架构、技术架构调整落地为云原生应用。
