架构决策，是技术管理者最重要的能力
决策失误，是“技术债”的主要来源
那么什么是架构决策能力呢？简单来说，就是当团队因架构方案的选择，出现争议、迟迟不能决定时，管理者需要具备的、一锤定音的能力和方法。
新架构多久落地，说到底只是个效率问题。但如何拍板确定新架构的设计，则是重要的方向性问题。如果方向不对，那么无论团队里有多少精兵猛将，也只能跟着漫无目的地瞎忙，这就是所谓的“一将无能，累死三军”。
选择“不作为”，往往更加可怕
举个例子，有两个团队成员坐在会议室里，争论两个架构设计方案孰优孰劣。他们各执一词，谁也说服不了谁。这时，你作为技术管理者，应该怎么办？
给大家分析哪一种方案更好，现场拍板；
指出当前双方考虑不周到的地方，再给大家时间去准备，并在 Deadline 前决策拍板；
泛泛地对大家说：“不够具体”、“没有重点”，“再回去想想”……
一把手是团队的天花板，并为团队的所有问题负责。
做好架构决策的流程和模板
流程
当事人发起架构决策申请；由产品负责人判断：该申请是在产研中心部门内协调解决，还是上升至 CTO 办公室解决；在产研中心部门内，或联合 CTO 办公室，完成架构评审；将结果发还至当事人征询意见；由当事人判断是否仍有疑虑，需要进行架构仲裁；若需要则发起仲裁会，解决分歧；若不需要则结案归档，执行决策。
技术管理者如何做好架构决策
第一项特质：要学会站在全局视角看待问题，学会看到技术架构的“外部价值”
这种“外部价值”包括：公司利润、人效、资源利用率、业务风险，等等。
第二项特质：具备相当的技术深度，以及非常好的学习能力和逻辑思维。
架构设计，专业分工和协作精神的体现
好的架构设计，就像优秀的组织协作一样，既能帮助 IT 系统做好各模块的专业分工，又能体现模块间的协作精神。
所谓的“专业分工、充分协作”，到底是做了什么呢？<br>
拆分是指将一个负责的功能按角色、按职责拆分，核心特征是单一模块的功能既单纯又简单。比如，要从零实现一个淘宝网，是相当复杂的事。但我们可以将其拆分成订单中心、用户中心、商品中心、库存中心等许多模块；订单中心还可以再拆分，比如拆分成订单创建、订单查询、订单履约等功能；如果实现仍然复杂，我们还可以继续拆分，直到能够用简洁优雅的代码去实现。
合并是指将类似的职责放在一个模块完成，抽象出可重用、复用的部分，提升业务响应效率。比如订单创建、订单查询都需要对数据库进行操作，那么与数据库的交互就应该统一封装。
抽象地看，架构是由元素（element）和关系（relationship）组成的。在架构设计中，那些稳定、可复用的部分应该变成组件或应用模块，对应着架构中的「元素」；而面向不确定性的设计，则需要变成协作方式，为可能的扩展作准备，对应着架构中的「关系」。
认知延伸：如何看待微服务和中台架构
架构设计本质上是一种“中庸思想”，如果单纯考虑功能设计，我们的目标只有一个：让架构响应业务调整的速度更快。
保证各「元素」职责清晰的情况下，抽象出稳定的功能或组件，用业务流程去串联起来
所以，无论是微服务还是中台，都有其巨大的实践价值，但二者只是架构设计核心原则的一种成熟的实践模式和承载方式，不是解决架构问题的“灵丹妙药”。
复杂架构设计如何落地执行
关键认知：在个人视角里，整个世界都可以按照确定性内容和不确定性内容做简单区分；
架构将其抽象为元素和关系，元素对应着确定性内容的处理，是看待这个世界的稳定视角；关系对应着不确定性内容的处理，是看待这个世界的响应视角；
人类的理解能力有限。包含内容过多的元素，会导致理解困难，需要将其拆分；
同理，将元素归类的时候，也不能贪多，不然会导致理解困难。优秀的架构师，会将合理数量的元素进行归类，归类后的整体一般被称作 component 或 module，也可以直译为“组件”。比如，我们永远以“元素数量为 10 ”作为一个衡量点，只要一个组件包含的元素 / 职责超过 10 个，就要进行拆分；
元素归类一般采用 “V” 字型分析法，即流程分解为功能，功能聚合为组件；
如果组件明确了，意味着职责就建设好了，架构的元素（element）建设问题就解决了。组件对外暴露的能力，我们统一称之为服务；
那么，架构的关系（relationship）建设问题该如何解决呢？稳定的关系，用来表达确定性的交互，使用 SOA 架构，做好服务调用就可以；不稳定的关系，用来表达不确定性的交互，使用 EDA 架构；
在每一个新需求到来时，尤其是大版本的更迭，架构师需要介入产品经理和程序员的沟通中，判断新需求是否大幅增加了某些组件的复杂度，并决定是否调整组件职责，或对现有组件进行拆分。所以，从实际的业务发展来看，组件的数量是逐步增长的，如果一开始就很多，基本属于过度设计；如果业务复杂度已经翻倍了，组件数量却没变，基本属于缺乏设计。
产品思维，契约精神是基础，洞察人性才能成就卓越
产品，是企业及个人价值的最好载体
产品是企业对外提供服务的载体，也是企业核心竞争力具象化的载体。
一般来说，随着产品能力的提升，内部产品有机会演变为外部产品。我认为，这也是培育公司“第二曲线”业务非常切实可行的办法。
培养产品思维的核心脉络
一个叫做“契约精神”，前者让你拥有入门级的产品思维
将自己的每个工作成果都当作产品，并将产品交付或售卖；
尝试理解这个产品的用户到底是谁；
在用户付出了时间、精力或金钱后，明确你的产品到底交付了什么？又承诺交付了什么？
不惜代价信守这个承诺。
一个叫做“洞察人性”，让你可以成为卓越的“产品经理”
洞察人性是要树立“以人为本”的理念，了解产品使用者的真正诉求，用户通过使用产品，会觉得自己更棒了，让自己变得更卓越。先成就用户，然后成就产品。
产品思维六步法
实践产品思维的第一步，就是面对所有的工作，都要习惯性自问：我到底要交付一个什么样的产品？
第二步，明确产品的用户到底是谁。
第三步，明确服务契约。
第四步，将产品打磨至卓越。
卓越产品的“三个一”思考法，即“一站一键一秒”
让用户在一个位置，点击一个按键，在一秒内达成目标
第五步，要习惯于成就用户，时刻谨记：以人为本。
技术人需要时刻提醒自己，产品设计的第一驱动力应该来自于用户价值，而不是技术方案的优劣。
第六步，关注数据，持续完善。
高可用设计，让产品没有后顾之忧
解剖高可用设计
真正的高可用，是指实现所有元素、所有连接的高可用。只要一个元素或一个连接没有做高可用设计，都意味着风险的存在。
更准确地说，所谓高可用，是要保证“业务的连续性”，即在用户眼里，业务永远是正常（或基本正常）对外提供服务的。
在最理想的情况下，我们既保证高可用，也保证高可靠；但出现问题时，我们优先保证高可用，其次保证高可靠。
手段
冗余设计
降级服务
组织层面
研发管理水平的高低，决定了你在版本发布方面的成功率和信心。
研发管理规范，应该为代码版本进入下一个环境设置准入标准，对于任何异常，都有负责人进行修正。如果异常通过了评估，审核者要对其负责。
系统 Bug 在导致生产故障前，也往往会有各类异常，我们要做好监控并正式的处理掉它。
关键在于要注意，真正的、为业务负责的高可用设计，不是画框图就能解决的，它是一个面向 IT 组织的整体设计。
