架构设计原则-大道至简

问题的复杂度要与解决问题的方法及成本相匹配；
规则一、避免过度设计
内容：在设计中要警惕复杂的解决方案
用法：通过测试同事是否能够轻松地理解解决方案来验证是否存在过度设计
原因：复杂的解决方案实施成本过高，而且长期的维护费用昂贵
要点：复杂的系统限制了扩展性。简单的系统易维护，易扩展且成本低

例子：例如设计一款家用空调，室外可以达到热力学温度0K，在室内可以达到300F，这是在浪费资源且毫无必要。-20~30度，过度设计有过度使用资源的情况，包括为研发和实施硬件，软件解决方案付出的较高费用。如果因为过度设计造成系统的研发周度过长，影响公司产品的发布计划。

规则二、方案中包括扩展
内容：提供及时可扩展性的DID方法
用法：Design(D)设计20倍的容量；Implement(I)实施3倍的容量；Deploy（D）部署1.5倍的容量
原因：DID为产品扩展提供了经济，有效，及时的方法
要点：在早期考虑可扩展性可以帮助团队节省时间和金钱。在需求发生大约一个月前实施（写代码），在客户蜂拥而至的几天前部署。

例子：“什么时候该在可扩展性上投入”有些轻率的回答是，最好在需要的前一天投入和部署。如果你能够多做到达需要改善可扩展性方案的前一天部署，那么 这笔投资的时机最佳，而且有助于实现公司财务和股东利益的最大化。
让我们面对现实，及时投入和部署根本就不可能，即使可能，也无法确定具体的时间，而且会带来很多风险。DID（设计-实施-部署）：思考问题和设计方案，为方案构建系统和编写代码；实际安装或者部署方案。

设计（Design）:DID方法的设计（D）阶段聚集在扩展到20倍和无限大之间，通过如今可扩展性大会，把领导者和工程师团队聚集在一起，共同讨论产品的扩展瓶颈，这是在DID设计阶段发现和确定需要扩展部分的一个好办法。

实施（I，Implement）:我们把规模需求的范围缩小到更接近现实，例如当前规模的3~20倍。

部署（D，Deploy）:在部署阶段资产的成本较高，如果是一家适度高增长的公司，也许我们可以把最大产能提高到1.5倍；如果是一家超高增长的公司，也许我们可以把最大产能提高到5倍。扩展具有弹性，它既可以扩张也可以收缩，因此灵活性是关键，因为你需要响应客户的请求，随着规模的收缩和扩张，在系统之间调整容量。

规则3-三次简化方案
内容：在设计复杂系统时，从项目的范围、设计和实施角度简化方案
用法：采用帕累托（Pareto）原则简化范围；考虑成本优化和可扩展性来简化设计；依靠其他人的经验来简化部署；
原因：只聚焦“不过度复杂”，并不能解决需求或历史发展与变革中的各种问题
要点：在产品研发的各个阶段都需要做好简化

例子：“问三个如何”：如何简化方案范围；如何简化方案设计；如果简化方案实施；
如何简化方案范围：
对这个简化问题的答案是不断的应用帕累托原则（也叫80-20原则）。收益的80%来自于20%的工作？对此，直接的问题是“你收入的80%是由哪些20%的功能实现的”，做得很少（工作的20%）同时取得显著的效益（价值的80%），解放团队去做其他的工作。如果删除产品中不必要的功能，那么可以做五倍的工作，而且产品并没有那么复杂！减少五分之四的功能，毫无疑问，系统将会减少功能之间的依赖关系，因而可以更高效率和更高本益比地进行扩展。此外释放出的80%的时间可用于推出新产品，以及投资思考未来产品可扩展性的需求。

如何简化方案设计：
简化设计与过度设计的复杂性密切相关；简化设计的步骤要求以易于理解，低成本，高效益和可扩展的方式来完成工作。

如何简化方案实施：
如何利用其它经验和已经存在的解决方案来简化方案实施？
首先寻找被广泛采用的开源或第三方解决方案来满足需求；
其次看看在组织内是否有人准备了可扩展方案；
再次看看外部是否有人已经描述了一种可以合法复制或模仿的可扩展方案；
只有这三项都无合适的情况下，我们才会开始尝试自己创建解决方案。

规则4-减少域名解析
内容：从用户角度减少域名解析次数
场景：对性能敏感的所有网页
用法：尽量减少下载页面所需的域名解析次数，但要保持与浏览器的并发连接平衡；
原因：域名解析耗时而且大量解析会影响用户体验

转载于:https://www.cnblogs.com/jasw/p/7261949.html