数据密集型引用系统设计——可靠性，可扩展性与可维护性

系统设计的过程，这三个特性其实是我们尽力去满足的。以下是我在阅读《数据密集型引用系统设计》一书的一些总结。有些思考收益，在这里总结分享给大家

可靠性

1、可靠性：容错能力，极端情况下，系统也能够提供正常的服务能力。

• 硬件故障：上云。
• 容器节点故障or进程挂掉：通过健康检测机制，分发流量
• 软件故障（系统故障）：前置手段：代码质量保证，充分的qa测试
• 人为失误：运维中的人工操作导致的故障。
  • 前置手段：最小出错方式设计系统，尽可能对外少暴露不需求的操作权限
  • 能力分级：按照重要程度对外提供能力，高危操作强制约束流程以及误操作后的sop

所有类型故障的通用手段：
监控报警能力，熔断降级能力

可扩展性

2、可扩展性：系统的可扩展性主要体现在集群服务的动态扩容能力。随着服务负载的增加，我们也需要有相应的手段来应对。

关于服务负载：
负载增加，但是系统资源不变，系统性能会发生什么变化；
负载增加，但是要求系统性能不变，需要增加多少资源

关注点
在不同的场景下，我们关注的性能指标也不尽相同。比如批处理系统hadoop，一般都会关心吞吐量，即每秒可处理的数据条数；
再比如一般的在线系统，我们更加关注的是服务的响应时间。

应对服务负载增加的情况，目前大部分公司的解决方案就是云部署，容器化部署，通过动态的分配服务器资源，可以快速满足业务的负载增加

可维护性

可操作性：良好的操作性可以解决软件的局限性，但是不规范的操作可能会击垮软件。
这里放到我们的mis服务来看，可操作性性也就是产研同学操作mis平台的便利性，如何才能更简单，更快速，更安全的把一个规则策略配置并上线

可运维性：传统的技术公司可能会有专门的运维团队来负责整个服务的运维，但是随着技术的迭代发展，目前很大一部分的运维工作是在RD侧维护，也就是自运维。
所以我们需要一些手段来满足自运维的诉求，比如说系统，业务的监控报警故障感知能力，再有就是快速的服务扩容能力，以及异常情况下的熔断降级能力。通过这些自运维的能力，来保证服务的稳定性，提高服务的可运维性

简单性：其实这是我比较同意的一个观点。在做系统设计的过程中，保留一定的前瞻性设计即可。千万不能把业务中不确定会不会发生的能力提前实现了。可以先规划，但是不能先落地。
保证我们的系统的简单性，这样才能更加利于我们系统的稳定性和扩展性。

可演化性：一成不变的系统是不存在的。想法，目标，业务，问题，时刻 都在变化。所以，能够保持我们系统的高内聚，低耦合，对于系统的演化和升级十分重要。