当前位置 博文首页 > 我总结出的架构原则和模式_编程哲学家的专栏:架构设计的几个痛
分层架构,每一层都分布式部署。使用冗余和故障转移的方式保证可用性。
- 应用层用负载均衡服务器,能够监测服务器的可用性,把不可能的踢出集群
- 服务层使用分布式调用框架dubbo
- 数据库使用同步复制,实现数据冗余。
- 还要考虑升级发布引起的宕机
整体来说就是冗余,故障转移,使用分布式调用框架。
- 分级管理 0级,1级。更重要的服务,使用更好的设备
- 超时设置 不超时会长时间占用服务器资源。 可以设置超时策略,重试,还是转移
- 异步调用
- 服务降级 高并发时,可以
拒绝服务。 随机拒绝部分请求
关闭功能。关闭部分不需要的功能。双十一就是这样干的
- 幂等性设计 针对于重试机制。不会出现下两个订单的情况
数据库高可用使用复制备份和故障转移解决
缓存的高可用作者认为应该使用集群分布式缓存,单点失效只是小部分失效不会造成数据库太大的压力
拂去耐受性(可以线性伸缩),可用性(随时可读写),一致性(所有应用访问得到相同的数据)。无法同时满足。
大型网站可能放弃一定的一致性。把一致性细分:
- 强一致性 各个副本总是一致的
- 数据用户一致 保证终端用户访问时,通过纠错和校验,确定一个一致且正确的数据返回给用户。
- 数据最终一致性 同一用户连续访问结果不同。 但是系统经过一段时间能够自我恢复和修正。
应该做到用户一致性
冷备:无法保证最终一致性和可用性(因为恢复时间太多)
热备:
- 异步热备 只写主存储区。 异步线程同步写从存储区
- 同步热备 同时写主备连个存储区。mysql支持半同步,保证至少有一个备写完。
读写分离也是基于数据备份
重新路由的过程
- 失效确认 心跳检测和应用程序访问失败报告 一般访问失败了还是需要再次发一次心跳,防止误判。
- 访问转移 重新路由,如果是对等的,直接路由就行了。但是如果是不对等的,就要根据路由算法,重新算数据等等。
- 数据恢复 转移之后修复宕机的服务,然后重新加入集群
采集之后可以对系统性能评估,集群规模伸缩性预测,进行风险预警,自动负载调整等。
主要用来做如下的功能: 系统报警,失效转移,自动优雅降级
cs