精读《从零开始做架构》( 二 ) _架构

高可用高可用是指系统无中断地执行其功能的能力，代表系统的可用性程度，本质是通过“冗余”来实现。常见高可用类型包括计算高可用，存储高可用。
可扩展性可扩展性指系统为了应对将来需求变化而提供的一种扩展能力，当有新的需求出现时，系统不需要或者仅需要少量修改就可以支持，无须整个系统重构或者重建。由于软件系统固有的多变性，新的需求总会不断提出来，因此可扩展性显得尤其重要。对架构师要求：

预测变化：如何把握预测的准确性比较复杂，没有固定的标准，靠直觉和经验。
应对变化：技术上做到开闭原则，如何对扩展开放付对修改关闭，抽象出稳定和变化。

低成本低成本可以是人力成本，服务器成本。低成本给架构设计带来的主要复杂度体现在，往往只有“创新”才能达到低成本目标。这里的“创新”既包括开创一个全新的技术领域（这个要求对绝大部分公司太高），也包括引入新技术，如果没有找到能够解决自己问题的新技术，那么就真的需要自己创造新技术了。
安全安全本身是一个庞大而又复杂的技术领域，并且一旦出问题，对业务和企业形象影响非常大。
从技术的角度来讲，安全可以分为两类:
一类是功能上的安全;功能安全其实就是“防小偷”，本质上是因为系统实现有漏洞。常见的安全问题,例如:常见的XSS攻击、CSRF攻击、SQL注入等。
另一类是架构上的安全。如果说“功能安全”是为了防小偷，那么架构安全就是为了防强盗。
规模规模带来的复杂度主要原因在于“量变引起质变”，当数量超过一定阈值后，复杂度会发生质的变化。常见的规模带来的复杂度有:

功能越来越多，导致系统的复杂度指数越来越高;
数据越来越多，系统的复杂度发生质变;

架构原则合适原则合适原则，合适优于业界领先。真正优秀的架构都是在企业当前人力、条件、业务等各种约束下设计出来的，能够合理地将资源整合在一起并发挥出最大功效，并且能够快速落地，不要面向简历去设计架构，高大上的架构不等于适用。
简单原则简单原则，简单优于复杂。面对系统结构、业务逻辑和复杂性，我们可以编写出复杂的系统，但在软件领域，复杂代表的是“问题” 。架构设计时如果简单的方案和复杂的方案都可以满足需求，最好选择简单的方案。其实，简单比复杂更加困难。
演化原则演化原则，演化优于一步到位。业务在发展、技术在创新、外部环境在变化，这一切都是在告诫架构师不要贪大求全，或者盲目照搬大公司的做法。应该认真分析当前业务的特点，明确业务面临的主要问题，设计合理的架构，快速落地以满足业务需要，然后在运行过程中不断完善架构，不断随着业务演化架构。
架构设计流程识别复杂度识别复杂度主要的复杂度问题列出来，然后根据业务、技术、团队等综合情况进行排序，优先解决当前面临的最主要的复杂度问题。
（1）构建复杂度的来源清单——高性能、可用性、扩展性、安全、低成本、规模等。
（2）结合需求、技术、团队、资源等对上述复杂度逐一分析是否需要？是否关键？ “高性能”主要从软件系统未来的TPS、响应时间、服务器资源利用率等客观指标，也可以从用户的主观感受方面去考虑。“可用性”主要从服务不中断等质量方面去考虑。“扩展性”则主要从功能需求的未来变更幅度等方面去考虑。
（3）按照上述的分析结论，得到复杂度按照优先级的排序清单，越是排在前面的复杂度，就越关键，就越优先解决。
设计备选方案确定了系统面临的主要复杂度问题后，方案设计就有了明确的目标，我们就可以开始真正进行架构方案设计了
架构设计备选方案的工作更多的是从需求、团队、技术、资源等综合情况出发，对主流、成熟的架构模式进行选择、组合、调整、创新。
(1)根据自己的经验设计一个方案。因为可选的模式有很多，组合的方案更多，往往一个问题的解决方案有很多个；如果再在组合的方案上进行一些创新，解决方案会更多。简单原则，适合原则。
(2)看看业界优秀的方案是什么，和我们业务场景比较，比较关键复杂度问题
(3)设计多个备选方案，3-5个左右，备选方案有差异，
评估和选择备选方案列出我们需要关注的质量属性点，然后分别从这些质量属性的维度去评估每个方案，再综合挑选适合当时情况的最优方案。质量属性按照优先级排序，首先挑选满足第一优先级的，如果方案都满足，那就再看第二优先级……以此类推。不要纠结，当差不多的时候，先落地比争论摇摆要强