在设计高可用的互联网架构要注意什么?

=Start=

缘由:

在答辩的时候被问到的一个问题,当时想的太少,回答的比较磕绊,虽然重点好像都有提到,但是感觉不够系统,觉得可以简单整理一下,常读常新,也方便之后添加更多的内容。

正文:

参考解答:
1、设计层面
如果可能的话,在最初设计层面就应该根据实际并发/响应时间要求来考虑,即便初始的流量比较小(避免后期切换/重做成本高,但是也要考虑前期快速上线的需求)。
# 处理流程设计
简单可依赖
# 底层框架使用(也需要考虑团队的熟悉程度、学习成本)
Redis/Tair
MQ
Thrift/RPC/…
SpringBoot/Netty/…
2、实现层面
重点代码交叉review
上线前性能测试
3、部署层面
异地、多机房、分布式部署
最好能有一键流量切换功能
4、监控层面
日志打点要满足需求(异步&不落盘)
相关监控要到位(请求量、服务器监控、存储监控、业务健康性监控)
5、操作层面
常规操作SOP
异常处理SOP(扩容、降级、回滚)
参考链接:

=END=

声明: 除非注明,ixyzero.com文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://ixyzero.com/blog/archives/4082.html

《在设计高可用的互联网架构要注意什么?》上有11条评论

  1. 小团队互联网项目开发之备忘
    https://blog.devopszen.com/development_notes

    近期Web项目的开发和运营的经验,以下几条适合小型团队在资源和时间都有限的情况下做高效开发:

    1. 快速开发和迭代
    应该在最短时间内验证一个feature或者一个想法行得通还是不容易实现。这样还有时间进行系统的重新设计。最先验证feature中的关键点是否可行,再将所有关键点进行串联,和系统整合。

    2. 提早进入运营和市场
    我们都工作在互联网时间,每天互联网都在发生翻天覆地的变化,不进则退。同样的创意,世界上有很多团队在把它变成产品。

    3. 高效运行
    将现有系统尽可能的做得快速运行,减少数据冗余。以备以后需求增长中执行速度变慢。

    4. 容错和并行化
    每个请求,数据返回都可能失败或成功,需要不定的时间长度。所以系统要尽可能做到并行,容错。互联网项目尤其是这样,网络环境不是可信环境。

    5. 易于维护和管理
    项目中期应该做到容易监控和维护。

    有关开发效率和协作的几点
    https://blog.devopszen.com/team_performance

  2. 互联网系统可靠性基础:正确的异常处理
    https://blog.devopszen.com/exception

    Try catch 的内部实现
    异常必然发生
    异常处理的性能考虑
    几个理念:Fail fast vs Retry vs Let it crash
    异常和错误的类型
    守门员:全局异常处理
    异常处理总结和一些原则
    一些有用的资料

  3. 07 | 准备Plan B:如何设计兜底方案?
    https://time.geekbang.org/column/article/40744

    高可用建设应该从哪里着手?
    具体来说,系统的高可用建设涉及架构阶段、编码阶段、测试阶段、发布阶段、运行阶段,以及故障发生时。接下来,我们分别看一下。
    1、架构阶段:架构阶段主要考虑系统的可扩展性和容错性,要避免系统出现单点问题。例如多机房单元化部署,即使某个城市的某个机房出现整体故障,仍然不会影响整体网站的运转。
    2、编码阶段:编码最重要的是保证代码的健壮性,例如涉及远程调用问题时,要设置合理的超时退出机制,防止被其他系统拖垮,也要对调用的返回结果集有预期,防止返回的结果超出程序处理范围,最常见的做法就是对错误异常进行捕获,对无法预料的错误要有默认处理结果。
    3、测试阶段:测试主要是保证测试用例的覆盖度,保证最坏情况发生时,我们也有相应的处理流程。
    4、发布阶段:发布时也有一些地方需要注意,因为发布时最容易出现错误,因此要有紧急的回滚机制。
    5、运行阶段:运行时是系统的常态,系统大部分时间都会处于运行态,运行态最重要的是对系统的监控要准确及时,发现问题能够准确报警并且报警数据要准确详细,以便于排查问题。
    6、故障发生:故障发生时首先最重要的就是及时止损,例如由于程序问题导致商品价格错误,那就要及时下架商品或者关闭购买链接,防止造成重大资产损失。然后就是要能够及时恢复服务,并定位原因解决问题。

    为什么系统的高可用建设要放到整个生命周期中全面考虑?因为我们在每个环节中都可能犯错,而有些环节犯的错,你在后面是无法弥补的。例如在架构阶段,你没有消除单点问题,那么系统上线后,遇到突发流量把单点给挂了,你就只能干瞪眼,有时候想加机器都加不进去。所以高可用建设是一个系统工程,必须在每个环节都做好。

  4. 从拼多多系统漏洞, 阿里专家谈码农如何防背锅
    https://mp.weixin.qq.com/s/vx61KfZhkiKXHYSsJ52J_w

    处理故障三板斧
    1-止血,止血,止血
    2-复盘
    3-改进

    避免故障三板斧
    1. 发布前,确保有效的数字化监控
    2. 发布时,逐步灰度
    3. 发布后,一键回滚的能力

    理解产品周期与线上故障
    技术故障,在产品的初期,到发展期,到成熟期,到半衰期,是有着不一样的影响效力和重视程度。
    1、产品初期:一切为了快速试错+反馈
    2、产品发展期:故障的快速处理开始被要求
    3、产品成熟期:线上故障几乎是0容忍态度
    4、产品半衰期:既要业务创新,又要技术稳定

    敬畏每一次线上操作变更的风险,落实发布能够灰度、数据大盘监控、业务数据指标是否符合预期。

    加强有效报警,从对敬畏故障的思想做起,在基础能力建设完善的基础基础上,未来实现“无人盯守,发现问题,自动告警,风险预测,自动回滚”,让devOps从经常要搞到凌晨发布,无法安心入睡的困境中解救出来,减少一线拧螺丝人员的背锅次数,减少系统释放处来的背锅HC机会,最终实现已知领域内的线上功能服务的高可用。

  5. 分布式架构知识体系
    https://mp.weixin.qq.com/s/9xINMH9tJlmsjH6QdUPFxQ

    1、何为分布式何为微服务?
    2、为什么需要分布式?
    3、分布式核心理论基础,节点、网络、时间、顺序,一致性?
    4、分布式是系统有哪些设计模式?
    5、分布式有哪些类型?
    6、如何实现分布式?

  6. 互联网架构三板斧之并发
    https://mp.weixin.qq.com/s/87JWlUoc03UZy2ar3p4NlA

    对大流量系统的数据做分层校验也是最重要的设计原则,所谓分层校验就是对大量的请求做成“漏斗”式设计,在不同层次尽可能把无效的请求过滤,“漏斗”的最末端才是有效的请求,要达到这个效果必须对数据做分层的校验,下面是一些原则:
    1、先做数据的动静分离
    2、将90%的数据缓存在客户端浏览器
    3、将动态请求的读数据Cache在Web端
    4、对读数据不做强一致性校验
    5、对写数据进行基于时间的合理分片
    6、对写请求做限流保护
    7、对写数据进行强一致性校验

  7. 如果20万用户同时访问一个热点缓存,如何优化你的缓存架构?【石杉的架构笔记】
    https://mp.weixin.qq.com/s/RqBla4rg8ut3zEBKhyBo1w

    (1)为什么要用缓存集群
    (2)20万用户同时访问一个热点缓存的问题
    (3)基于流式计算技术的缓存热点自动发现
    (4)热点缓存自动加载为JVM本地缓存
    (5)限流熔断保护
    (6)总结

  8. 四种软件架构:Serverless架构、微服务架构、分布式架构、单体架构
    https://mp.weixin.qq.com/s/5CUm44VjXRCoxagYpMRQBQ

    一、单体架构
    单体架构比较初级,典型的三级架构,前端(Web/手机端)+中间业务逻辑层+数据库层。这是一种典型的Java Spring mvc或者Python Django框架的应用。

    单体架构的应用比较容易部署、测试, 在项目的初期,单体应用可以很好地运行。然而,随着需求的不断增加, 越来越多的人加入开发团队,代码库也在飞速地膨胀。慢慢地,单体应用变得越来越臃肿,可维护性、灵活性逐渐降低,维护成本越来越高。下面是单体架构应用的一些缺点:

    复杂性高: 以一个百万行级别的单体应用为例,整个项目包含的模块非常多、模块的边界模糊、 依赖关系不清晰、 代码质量参差不齐、 混乱地堆砌在一起。可想而知整个项目非常复杂。 每次修改代码都心惊胆战, 甚至添加一个简单的功能, 或者修改一个Bug都会带来隐含的缺陷。

    技术债务: 随着时间推移、需求变更和人员更迭,会逐渐形成应用程序的技术债务, 并且越积 越多。“ 不坏不修”, 这在软件开发中非常常见, 在单体应用中这种思想更甚。 已使用的系统设计或代码难以被修改,因为应用程序中的其他模块可能会以意料之外的方式使用它。

    部署频率低: 随着代码的增多,构建和部署的时间也会增加。而在单体应用中, 每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。全量部署的方式耗时长、 影响范围大、 风险高, 这使得单体应用项目上线部署的频率较低。 而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复,出错率比较高。

    可靠性差: 某个应用Bug,例如死循环、内存溢出等, 可能会导致整个应用的崩溃。

    扩展能力受限: 单体应用只能作为一个整体进行扩展,无法根据业务模块的需要进行伸缩。例如,应用中有的模块是计算密集型的,它需要强劲的CPU; 有的模块则是IO密集型的,需要更大的内存。 由于这些模块部署在一起,不得不在硬件的选择上做出妥协。

    阻碍技术创新: 单体应用往往使用统一的技术平台或方案解决所有的问题, 团队中的每个成员 都必须使用相同的开发语言和框架,要想引入新框架或新技术平台会非常困难。

    二、分布式应用
    该架构相对于单体架构来说,这种架构提供了负载均衡的能力,大大提高了系统负载能力,解决了网站高并发的需求。另外还有以下特点:
    降低了耦合度:把模块拆分,使用接口通信,降低模块之间的耦合度。
    责任清晰:把项目拆分成若干个子项目,不同的团队负责不同的子项目。
    扩展方便:增加功能时只需要再增加一个子项目,调用其他系统的接口就可以。
    部署方便:可以灵活的进行分布式部署。
    提高代码的复用性:比如service层,如果不采用分布式rest服务方式架构就会在手机wap商城,微信商城,pc,android,ios每个端都要写一个service层逻辑,开发量大,难以维护一起升级,这时候就可以采用分布式rest服务方式,公用一个service层。

    缺点 : 系统之间的交互要使用远程通信,接口开发增大工作量,但是利大于弊。

    三、微服务架构
    微服务架构,主要是中间层分解,将系统拆分成很多小应用(微服务),微服务可以部署在不同的服务器上,也可以部署在相同的服务器不同的容器上。当应用的故障不会影响到其他应用,单应用的负载也不会影响到其他应用,其代表框架有Spring cloud、Dubbo等。

    四、Serverless架构
    Serverless架构能够让开发者在构建应用的过程中无需关注计算资源的获取和运维,由平台来按需分配计算资源并保证应用执行的SLA(服务等级协议),按照调用次数进行计费,有效的节省应用成本。

    目前微服务架构在四种架构中处于主流地位,很多应用第一、第二种架构的企业也开始慢慢转向微服务架构。到目前为止微服务的技术相对于二三年前已经比较成熟,第四种架构将是未来发展的一种趋势。如果你喜欢我的文章,欢迎关注我的简书,后续我将教会大家利用spring cloud和docker轻松愉快的构建微服务。

  9. 高并发编程知识体系
    https://mp.weixin.qq.com/s/qaj37YYxz7afD-WfAZeN8Q

    1.问题
    1、什么是线程的交互方式?
    2、如何区分线程的同步/异步,阻塞/非阻塞?
    3、什么是线程安全,如何做到线程安全?
    4、如何区分并发模型?
    5、何谓响应式编程?
    6、操作系统如何调度多线程?

    2.关键词
    同步,异步,阻塞,非阻塞,并行,并发,临界区,竞争条件,指令重排,锁,amdahl,gustafson

    3.全文概要
    上一篇我们介绍分布式系统的知识体系,由于单机的性能上限原因我们才不得不发展分布式技术。那么话说回来,如果单机的性能没能最大限度的榨取出来,就盲目的就建设分布式系统,那就有点本末倒置了。而且上一篇我们给的忠告是如果有可能的话,不要用分布式,意思是说如果单机性能满足的话,就不要折腾复杂的分布式架构。如果说分布式架构是宏观上的性能扩展,那么高并发则是微观上的性能调优,这也是上一篇性能部分拆出来的大专题。本文将从线程的基础理论谈起,逐步探究线程的内存模型,线程的交互,线程工具和并发模型的发展。扫除关于并发编程的诸多模糊概念,从新构建并发编程的层次结构。

发表评论

电子邮件地址不会被公开。 必填项已用*标注