Qicz’s Thoughts HUB

The creative and technical writing. Do more, challenge more, know more, be more.

分布式系统/高并发系统设计原则

DID 原则 : Design - Implement - Deploy

  • 设计(Design)20倍的容量。
  • 实现(Implement)3倍的容量。
  • 部署(Deploy)1.5倍的容量。

确保一定时间内,不会因为业务体量的变化出现对架构较大的升级调整。但尽快如此,也不能过度咯。

1、换个思路理解 DID 在软件建构领域,有一个原则叫DID, 通常用来保证资源和时间的最小化。

DID:

  • 设计(Design)20倍的容量。
  • 实现(Implement)3倍的容量。
  • 部署(Deploy)1.5倍的容量。

这个DID一般是从资源成本的更小消耗来出发,希望将更低成本的设计发挥更大的作用,对更高成本的部署更谨慎的使用。

换个思路,在需求开发与系统设计层面出发,也应该遵循这种规律,即在前期设计层面下足功夫,用更周到的设计来实现 方案,以便在部署上线后的改动最小。

但是,往往在实际开发中这个过程都是本末倒置的,从 ‘拍脑袋就做’ 到 ‘开发中发现行不通’ 到 ‘返工’,或者更严重的上线 之后才发现问题,导致更大的返工成本。

2、过度设计 通常意义的过度设计包含两方面:

超出了需求的本意,比如我要一个一公里的代步工具你给我设计了一架飞机。 导致系统过度复杂。 我认为,还有一种也应该称之为过度设计,即设计出了合理的但是没人感兴趣的产品。比如所有人都买了一款可用但是有瑕疵的手机v1, 不到一个月,一款同款产品v2出现,虽然更完美,价格更低,但是基于成本没人会买单。

但是v2一定是推广不了的吗?也不一定,怎么推广?顺势而为。比如运营商推出5G, 只有v2支持,这叫顺势而为;国家规定,只有支持5G的手机才能使用,这也叫顺势而为。晚上做班车下班,遇到一个之前的领导,他说为什么当时order-platform可以推广,那是因为借着海外的大势…

3、精简精简在精简,拆分拆分在拆分。 这个,和过度设计想对应。和成就感相挂钩。

帕累托法则:80%的成果源于20%的时间。如果时间有限,那么尽量把时间放在容易产生成果的事情上,有成果便有产出,才有成就感。

ref: https://younghz.github.io/DID#id-1-%E6%8D%A2%E4%B8%AA%E6%80%9D%E8%B7%AF%E7%90%86%E8%A7%A3-did

KISS 原则 : Keep it Simple and Stupid

单个接口简单易用,把一个事情搞复杂是把一件简单的事,但把一个复杂的事简单化,确实一件复杂的事。

DIP 原则 : Dependence Inversion Principle

根据接口业务场景分包、分类,可分为基础服务、公共服务、业务实现。

业务接口»公共服务»基础服务(约定俗成)

CAP 原则

  • Consistency : 一致性
  • Availability : 可用性
  • Partition tolerance : 分区容错性

三者不可兼得,系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在CA之前做选择。也就是只有满足CA或满足CP

CAP基础上衍生了BASE原则。BASE 是指基本可用(Basically Available)、软状态( Soft State)、最终一致性( Eventual Consistency),核心思想是即使无法做到强一致性(CAP 的一致性就是强一致性),但应用可以采用适合的方式达到最终一致性。

基本可用(Basically Available)

分布式系统在出现故障时,允许损失部分可用性,即保证核心可用。 这里的关键词是“部分”和“核心”,具体选择哪些作为可以损失的业务,哪些是必须保证的业务,是一项有挑战的工作。例如,对于一个用户管理系统来说,“登录”是核心功能,而“注册”可以算作非核心功能。因为未注册的用户本来就还没有使用系统的业务,注册不了最多就是流失一部分用户,而且这部分用户数量较少。如果用户已经注册但无法登录,那就意味用户无法使用系统。例如,充了钱的游戏不能玩了、云存储不能用了……这些会对用户造成较大损失,而且登录用户数量远远大于新注册用户,影响范围更大。

软状态(Soft State)

允许系统存在中间状态,而该中间状态不会影响系统整体可用性。这里的中间状态就是 CAP 理论中的数据不一致。

最终一致性(Eventual Consistency)

系统中的所有数据副本经过一定时间后,最终能够达到一致的状态。

ref:https://mp.weixin.qq.com/s/YVhPawEyWuWMUeNBwTuPoQ

SMART 原则

  • Specific : 明确性
  • Measurable : 衡量性
  • Attainable : 可实现性
  • Relevant : 相关性
  • Time-based : 时限性

TODO : 待进一步完善

SLA服务等级 - Service Level Agreement

高可用架构 - 会话层>接口层>存储层>基础服务层