架构师速成-架构目标之可用性

  1. 服务器等,从而共同完成工作任务。各种负载均衡的软硬件有很多,我们可以单独讲解一下。
  2. 配置中心,原来单一节点的配置,被类似zookeeper的多节点配置中心取代。
  3. 流量控制,流量控制是保证大流量下系统可用性的重要手段,当系统流量不足以支撑所有流量时,只保留合理的流量处理。其他流量直接丢弃,否则系统会被压垮,造成雪崩。
  4. 功能降级,另外大流量情况下,有些无关紧要的功能可以暂时降级,后期通过数据补全的方式进行修正,将核心的资源用于最关键的业务。比如双11时,为保证购买可以暂时不考虑推荐,这样省掉推荐资源,供给购买环节。
  5. cdn,其实也算是分布式的一种解决方案,但是更专业,所以单独讲解。智能路由、资源加速等等是满足可用性的利器。

为满足可用性,需要的支撑系统:

  1. 运维系统

    1. 运维系统需要提供分布式的自动扩容
    2. 热备、冷备
    3. 各种分布式系统的运维工具
    4. 异地多活
    5. 分批自动化发布
    6. 灰度发布
  2. 监控系统
    1. 分布式服务的健康状态监控
    2. 流量监控
    3. 故障监控、异常发现
时间: 2024-08-10 02:03:26

架构师速成-架构目标之可用性的相关文章

架构师速成-架构体系

经过这段时间的反思和整理,终于对架构有了一个较为明确的理解.架构是产品从无到有以及慢慢壮大过程中所需要的全部技术体系总称,架构过程: 配置.编码.测试.运维.监控分析.安全.运营等一系列技术体系的选型.取舍 技术选型基础上进行规划.设计.实现.迭代.制定相关规范 相关技术及规范运用到产品开发的整个过程中,并在产品迭代过程中对架构进行迭代优化 架构不止包含技术的框架,比如有人用了spring就觉得我已经是架构师了,其实架构并不是这么简单.我们以做一个新浪微博类似产品为例,现实应该是这样的: 产品初

架构师速成-架构的目标

架构的目标为了实现以下特性: 正确性 系统首先需要正确,运行稳定 可用性 软件系统对于用户的商业经营和管理来说极为重要,因此软件系统必须非常可靠,一般99.99%是一个比较基本的要求. 快速开发 互联网目前是一个快鱼吃慢鱼的时代,已经不是大鱼吃小鱼了.因为小鱼在一夜之间就长大了,把大鱼吃掉了.诺基亚就是明证,facebook就是明证. 良好体验 良好的体验对用户的吸引力是巨大的,某迅公司往往是抄一个产品,把用户体验做好,然后原产品就没有然后了. 伸缩性 用户激增的时候,网站可以伸缩来支持用户的增

架构师速成-架构目标之正确性

本系统架构模式: 统一异常 统一异常处理是保证程序正确性的第一步,这是第一个架构模式.具体如何实现,详见前面的文章. 日志 日志也是保证程序正确的一大手段,虽然是在错误出现后,日志才会记录.但是日志是快速确认问题,并分析出隐藏问题的重要手段. 关键点 日志文件按照级别进行区分,将错误和普通调试日志分开 日志文件滚动方式,可以按天及按大小滚动,定时清理 日志级别可以实时调整设置 性能 支撑系统: 测试系统 自动化单元测试,保证基础模块的正确性 自动化功能测试,保证每次代码更新的正确性 监控系统 监

.NET 高级架构师0003 架构师之路(2)---架构师的职责

2 架构师的职责 近来看到CSDN上有个CTO俱乐部,里面聊得是不亦乐乎.我怀着无比崇敬的态度,拜读了一下牛人们的发言.里面有个哥们发起一个话题:"CTO, 你多久没有写程序了?".有人回答:"不写代码的CTO,属于......这公司问题大了!".看到这里,我就赶紧撤了,怕忍不住反驳几句,反而遭到牛人们的群殴.试想,一个上点规模的IT公司,还得靠CTO来写程序的话,那是不是才叫问题大了呢.当然,我没有做过CTO,所以我有我的不同看法,而且还愿意表达出来,无知者无畏.

架构师速成8.3-架构师必须要了解的规则(转)

作为一个架构师,有些规则是必须要掌握的,这就想软件的公理,如果你学物理不知道牛顿定律,那就不要学了.在软件行业也有类似的东西,我称之为软件定律.例如: ACID,CAP,BASE ACID 传统数据库系统中,事务具有ACID 4个属性 (1)原子性(Atomicity):事务是一个原子操作单元,其对数据的修改,要么全都执行,要么全都不执行. (2)一致性(Consistent):在事务开始和完成时,数据都必须保持一致状态.这意味着所有相关的数据规则都必须应用于事务的修改,以保持数据的完整性:事务

架构师速成8.2-架构师要懂产品

产品和架构两个截然不同的职业,好像风马牛不相及,其实不是这样的.产品的思想需要经过技术的手来成为现实,在成为现实之前,需要技术理解.评估.碰撞.优化.把控.验证等等.当然架构师就承担了这一系列技术的责任,而且在一个产品的实现过程中,技术架构并不是很重要的,前期可以没有架构,简单快速验证,只有在用户多了之后,架构才有真正的用处.在初创公司,很多架构师都等不到用户多了的那一天,来实现自己的架构梦.所以产品这一关架构一定要把好,只有你把好了,后面才有机会让你去架构. 当然架构师的懂产品,是懂产品的生命

架构师速成5-小学

很高兴你很快的进入了小学,小学的东西会让你更加的耀眼. 阶段: 小学 学时:2-3个月 升学标准 能自己制定目标及计划,get thing done. 可以轻松制作一个让你身旁人惊叹的ppt 能做一个简单的网站(或者客户端软件),数据能保存到数据库. 实践经验干货来了. 先说ppt吧,这个上一期已经讲了,如果你ppt做到出神入化,基本不需要做架构这么苦逼的事情了.因为你很容易成为老板的心腹,军师,走上人生正道.作为一个苦逼的小学程序员,很羡慕吧.那就再努力学一下,不用多久,你就会升职加薪,当上总

架构师速成6.6-知识的收集整理学习

知识如何学习前面已经讲了2节,这节主要讲知识的整理和沉淀. 其实我之前也一直没有好好的思考过这个问题,今天在整理自己的wiz知识库的时候突发灵感,所以有了这一节. 其实知识获取的过程分为搜索->收集->整理->精化->应用->分享,前一部分跟时间管理的收集也很相近吧.知识获取的思路适用于有目的的知识收集和日常的备忘性的知识收集.当然你随机收集一些资料记录下来其实效果并不是很理想,重要的是你要有目的的学习才能最大的发挥你的心智以及潜意识.当你主动要学习一项知识时,你的潜意识会主

架构师速成7.3-devops为什么很重要

evops是一个很高大上的名字,其实说的简单点就是开发和运维本身就是一个团队的,要干就一起把事情干好.谁出了问题,网站都不行.作为一个架构师,必须要devops,而且要知道如何推行devops. 首先要自动化,举个阿里的例子,阿里通过aone系统来实现半自动化部署: 开发人员开发代码先自测通过后,提交代码到git. 在aone中一键部署到日常环境.部署是自动化扫描依赖冲突,系统安全等问题. 测试接到部署成功的通知,进行测试,如果测试通过,则审批通过,可以线上发布. 线上运维人员一键部署到线上,部