分布式系统设计真经：规则三：三次简化方案
规则三：三次简化方案
砍掉很多无关紧要的东西，留下精华，奉行极简主义
内容:在设计复杂系统时,从项目的范围、设计和实施角度简化方案。
场景:当设计复杂系统或产品时,面临着技术和计算资源的限制。
用法
- 采用帕累托( Pareto)原则简化范围
- 考虑成本优化和可扩展性来简化设计
- 依靠其他人的经验来简化部署
原因:只聚焦“不过度复杂”,并不能解决需求或历史发展与沿革中的各种问题
要点:在产品研发的各个阶段都需要做好简化
鉴于规则1，主要是关于避免超过“有用的”(实际的)需求和降低复杂度,本规则聚焦简化包括从感知需求到实际设计和实施在内的一切。规则1是关于抑制某些事情过于复杂的冲动,而规则3则是关于试图采用本文所述的方法来进一步简化方案。
有时候我们告诉客户把这条规则想成“问三个如何”:
如何简化方案范围?
如何简化方案设计?
如何简化方案实施?
其实，这个就是，在开始或者是在设计结束的回馈阶段，进行砍枝叶！
如何简化方案范围
对这个简化问题的答案是不断地应用帕累托原则(也叫80-20原则)收益的80%来自于20%的工作?对此,直接的问题是,“你收入的80%是由哪些20%的功能实现的?做得很少(工作的20%）的工作，然后取得很高的效益！
直接剔除产品里的不必要功能，就可以做5倍的工作，而且，可以用这些资源，去做更有用的事！
微信的功能，能留下客户的并不是它的那些钱包里的多得数不清的功能！网页！这些东西，就是属于一个扩展！！
如果删除产品中不必要的功能,那么可以做五倍的工作,而且产品并没有那么复杂!减少五分之四的功能,毫无疑问,系统将会加容
减少功能之间的依赖关系,因而可以更高效率和更高本益比地进行
释放出的80%的时间可用于推出新产品,以及投资于思考未来产品可扩展性的需求
保持大多数好处的前提下,思考如何减少不必要的功能《You can always do less》，其实，这个就是，精英主义，不需要那些含金量或者说，含能少的设计！它是对资源的一种极大的浪费！
最小多的努力获得经过验证的最大化客户感知数量
这种聚焦这“敏捷”的方法允许我们快速发布简单和容易扩展的产品
如何简化方案设计
简化后缩窄了的项目范围,可以使后续的设计和实施工作更加容易
简化设计与过度设计的复杂性密切相关。消除复杂性相将会当于在工作中忽略无关紧要的活动,简化就是寻找一条捷径
规则1中的例子说明了在数据库中只查询需要的数据,
select(*) from schema_name.table_name
应该为：
select ( column ) from schema _name.table_name
简化设计的方法表明,值先要看在本地,像内存这样的信息共享资源中是否已经有了数据请求
消除复杂性涉及能现在上经做更少的工作,而简化设计涉及更快和更容易地完成工传
简化方案实施
最后,我们来讨论一下实施的问题。与规则2的DID扩展过程保持一致,我们把实施定义为解决方案的代码实现。这里我们遇到了一些问题,诸如使用递归或迭代是否更有意义。我们是否应该定义一个特定大小的数组,或者准备好在需要时动态地分配内存?
对于解决方案,需要自己研发还是利用开源项目?或者从市场上采购?所有这些问题的答案都指向一个共同的主题:“如何利用其他经验和已经存在的解决方案来简化方案实施?”
- 因为不可能在每件事上都做到最好,所以我们应该首先寻找间被广泛采用的开源或第三方解决方案来满足需求
- 如果那些都不存骤在,那么我们应该看看在组织内部是否有人已经准备了可扩展的解决方案来解决问题
- 在没有专有解决方案的情况下,我们应该再从外部看看是否有人已经描述了一种可以合法复制或模仿的可扩展方案
只有无法在这三项中找到合适的选择情况下,我们才会开始尝试自己创建解决方案。最简单的实施几乎总是那些有过实施经历并通过实践证明了的可扩展方案
