《架构即未来》中最常用的15个架构原则

《架构即未来》这本书的第12章简单阐述了架构设计的一些常用的原则(后面章节会详细阐述)。这些原则中很多都是在架构一开始的设计中就要考虑进去的,这样在出现任何问题时,我们都能够及时的处理,和把问题影响的范围有效的缩小。否则就像我现在的项目,一开始设计时,考虑的很少,出问题时,没有做到及时的反馈,和缩小影响范围,只能在事故的代价中将所需要的原则添加进来,慢慢完善。

1.N+1设计

要确保任何你所开发的系统在发生故障时,至少有一个冗余的实例。

一个实例确实很危险,当这个实例出现不明原因的问题不能对外服务,需要debug的时候,如果优先debug,那当前实例就要暂停服务直到你找到问题为止。如果你直接重启实例恢复服务,就没有事故现场进行debug了。而这时如果有一个冗余的实例,就可以先让冗余的实例对外服务,事故现场的环境也得以保留。

多个实例来做负载均衡也是一种不错的选择。

2.回滚设计

确保系统可以回滚到以前发布过的任何版本。

以前做游戏的时候经常遇到回滚,有时候是数据库回滚,有时候是服务器端回滚,一般都是回滚到上个版本。

3.禁用设计

能够关闭任何发布的功能。

当一个功能出现严重问题不得不关闭时,如果关闭整个系统代价就有点大了,所有要有单个功能的开关。像商城系统的支付功能就一定要有开关,如果出现比较严重的bug,可以关闭支付而不影响下单。

4.监控设计

在设计阶段就必须要考虑监控,而不是在实施完成之后补充。

如果监控做的好,不仅能发现服务的死活,检查日志文件,还能收集系统相关的数据,评估终端用户的响应时间。如果系统和应用在设计和构建时就考虑好监控,那么即使不能自我修复,也至少可以自我诊断。

5.设计多活数据中心

不要被一个数据中心的解决方案把自己限制住。

有钱就多建一个,让股东放心。

6.只用成熟的技术

只用确实好用的技术。

不管用什么技术,都要确保是一个成熟的技术。也许某个新技术有众多优点,比如,降低开发成本,提高开发效率,提高可扩展能力,减少终端用户的响应时间。但是,只要这项技术故障率比较高,就绝不能使用。

7.异步设计

只有在绝对必要的时候才进行同步调用。

异步适合并发。

8.无状态系统

只有当业务确实需要的时候,才使用状态。

无状态的系统更利于扩展,更利于做负载均衡。

9.水平扩展非垂直升级

永远不要依赖更大、更快的系统。

微服务是水平扩展的一个例子,不要把所有的功能都集中在一个系统里面。必要的时候把需求分为多个系统,而不是升级原有的系统。

10.设计至少有两个步骤的前瞻性

在扩展性问题发生前考虑好下一步的行动计划。

想的更远一点,就能减少重构的次数。

11.非核心则购买

如果不是你最擅长的,也提供不了差异化的竞争优势则直接购买。

云服务这种的就购买好了。

12.使用商品化硬件

在大多数情况下,便宜的是最好的。

硬件这块儿,满足需求即可,在必要的时候增加配置。

13.小构建,小发布,快试错

全部研发要小构建,不断迭代,让系统不断地成长。

小版本的失败率较低,因为失败率与解决方案中的变更数量直接相关。

14.隔离故障

实现隔离故障设计,通过断路保护避免故障传播和交叉影响。

避免多系统之间的互相影响,这个很重要。

15.自动化

设计和构建自动化的过程。如果机器可以做,就不要依赖于人。

人常犯错误,更令人沮丧的是,他们往往会以不同的方式多次犯同样的错误。

除特别注明外,本站所有文章均为duzhi原创,转载请注明出处来自https://www.duzhi.me/article/11096.html

联系我们

******

在线咨询:点击这里给我发消息

邮件:ashang.peng#aliyun.com

QR code