文章目录
架构即未来-摘要及读书笔记大纲
The art of scalability
可扩展的艺术-- 现代企业可扩展的流程、组织、web架构
中文译名 架构即未来
全书分为三个部分阐述可扩展性：组织层面、流程中的扩展性管理、技术架构的扩展性问题。内容大纲
scalability也可译为伸缩性，extension 才是扩展性的意思，这本书scalability的意思更准确的应该是伸缩性，规模可调整、可大可小，不一定都是扩展放大的意思
1、组织层面
人员的可扩展性
项目成员的个人技能，能力、经验是否满足项目的要求需要首先考虑，人是项目可扩展性的基础，是最重要的因素。
没有人，项目工作无法落地，不合适的人，项目目标不能很好完成，而且会影响团队士气，打击其他成员的积极性。
成功的项目是合适的人在 合适的时间做合适的事情，。
合适的人包括 知识、技能、经验、能力等几个方面，合适的行为即1、与团队成员和谐相处，2、认同公司文化、价值观，3、积极向上的氛围，有个人与团队共成长的意愿。
可扩展性的技术组织
- 角色：
不同角色承担不同责任，避免角色缺失、角色边界不清。角色缺失导致部分功能无人参与实施或遗漏，其结果就是项目上线有未知不可控风险，
另一个极端就是角色冲突，同样的事情多方参与，没有主导方，导致的结果就是没人对结果负责，互相推诿，最终影响项目的及时交互、上线，影响公司利益。
-
责任：
明确到人或组织，应该避免任务无人负责或多人共同负责的情况，多方参与的项目，要区分责任主体和支持方，可以 -
通过RASCI工具来分析。
R 责任主体方，A 批准方 S 提供资源的人或组织，C 提供信息或数据支持的人或组织 ,Informed 关心项目进展，不实际参与项目实施的相关人员。
实际工作中，每个任务实现过程中都要关注 R和A,S的主体，确保不遗漏，不扩大范围。 -
RASCI工具：
Responsiable 执行者，负责人
Acceptable 批准人
Supported 为项目完成提供资源的人
Consulted 为项目完成提供数据、信息的人
Informed 需要了解项目进展的人
任务分配过程中正确处理冲突，冲突分为两种：认知型冲突和情感型冲突。
认知型冲突是关于谁做，怎么做的问题引起的冲突，不同工作经验、不同知识背景、不同角色的人对同一个事情的看法是不一样的，认知型处理的好，对项目的成功是有益的，所以一个项目团队应该多元化，应该把跨职能人员引入团队，提升团队的整体认知水平；
另一种冲突是情感型冲突，所谓情感型冲突是以角色或控制为基础的冲突，是一种跨团队的冲突，情感型冲突是关于该谁做的问题，往往在不同职能部门间发生，引起沟通障碍，降低效率，增加成本，是应该避免的冲突。
组织形式
-
职能型组织
按职能分部门，专业性强，部门内个人同质性，责任规则明确，有标准可依，不足之处在于项目缺少单一的负责人，整体负责各部门相关人员，沟通效率低。传统瀑布式研发流程适合这种组织形式。 -
矩阵式组织
纵向-功能型组织：按技能、职能及专业领域划分部门，同质化
横向-跨职能部门，项目制，一个项目由各个职能部门人员组织在一起形成一个项目组，项目经理有部分绩效考核的权限，员工接受双重领导。
- 敏捷性组织
SCRUM
自组织团队
领导力
影响个人和组织相关目标的行为，领导力的强弱由各种因素决定，一种抽象模型是y=f(先天因素，个人特质，专业能力，判断力，执行力，。。),强化长处，避免短项。领导力特征：
谦虚谨慎：
自知之明：
决策英明：
用人不疑：
变革性领导：
愿景、使命、目标：
目标设定应满足SMART原则，所谓SMART 即
- 目标必须是具体的（Specific）
- 目标必须是可以衡量的（Measurable）
- 目标必须是可以达到的（Attainable）
- 目标必须和其他目标具有相关性（Relevant）
- 目标必须具有明确的截止期限（Time-based）
管理的秘籍
找发展方向：目标分解 -任务应满足SMART原则，这是一个任务可度量、可执行、可完成的，一般性的指导原则，不满足则需要考虑其原因，是一个风险点，要引起重视并找到解决办法。
团队人员成长：团队的管理，组织的产出取决于个人产出和团队规模
团队目标设置–团队自身定位+领导分配
团队人员管理–团队建设-球队类比，内部提升培养-加强个人相关技能提升，团队优化-寻找适合的人，适合公司文化。
事情如何做：
团队业绩实现，做事：任务管理，任务的分解，进度跟踪，风险管理
业务、技术之间的鸿沟
技术组织的两种基本模式：IT组织模式、产品组织模式，IT组织模式是给其他组织提供咨询和实施服务，目的是降低成本，提供员工的工作效率，是一个技术支持部门，服务于其他业务部门。
产品模式技术组织通过定义和创建产品推动业务增长和创造股东价值，更专注于外部市场，把产品服务的用户作为自己的客户。IT的思维模式对内部技术的发展支持比较好，对外部的产品开发不擅长。
好的产品都是由深谙客户需求的公司创造的，好的产品团队与客户互动并创新，聚集产品创新，而技术人员通常业务敏感性比较差，没有相关业务从业经验和教育经验，要做好产品，技术人员必须要有熟悉业务的意识，多了解学习相关业务领域的知识。
2、执行过程
变更管理
危机管理
故障管理
项目扩展性的落地是在日常工作过程中体现出来的，项目研发的生命周期的各个阶段都需要考虑扩展性问题。不同阶段考虑不同的方面，主要的扩展性问题如上图所示。
需求分析阶段要控制变更的范围，考虑分步骤设计、迭代实施。
功能设计阶段要考虑系统的可维护性，可扩展性，其中架构的可扩展性是首先要考虑的，结合实际需求及资源投入要确定必须满足的一些约束条件。
线上系统出现故障时，危机管理的流程，沟通机制的建立的一些原则性方案介绍。
常规的可扩展性架构原则有 ：
N+1原则： 避免单点部署，服务可靠性保证最基础的要求
回滚设计：设计层面要考虑兼容性，db层规范，不允许不兼容的脚本变更。
监控设计：埋点监控，日志分析，告警服务等
开关设计: 重要的服务要支持开关、启停控制，异常发生时可减少损失，减轻修复问题的时间压力。
多活设计：多机房，多集群部署等，避免地震火灾等不可控因素导致的服务整体不可用。
异步设计：减少调用链路的整体耗时，提升串联系统的整体可用率。异步常和并行调用一起作为服务性能优化的一种手段。
采用成熟的技术：创新性的技术一般有未知的缺陷，可以用在实验性的项目中，待验证成熟稳定后可以大范围推广。重要的、核心的系统，稳定性优先，不要因采用新技术而引入新的风险。
服务无状态：无状态服务具有良好的伸缩性，可随时扩充资源，使用率下来了也可以放心的停掉多余的服务，可以随时启停服务，运维简单，可以考虑引入自动化技术提升效率。
快速迭代 ：增量模式，好的架构应避免系统推倒重来，应该是积木式的逐步叠加、逐步丰富完善起来的。
采用自动化技术：自动化可以固化一些常规操作流程，减少人工误操作，提升研发效率，开发、运维人员可以集中精力做更有针对性的、个性化的事情。
为了确保必要的架构原则在项目上得到实施落地：成立架构评审委员会
3、架构实践
故障隔离的架构
AFK立方体
缓存以支持扩展性
异步以支持扩展性
数据存储的扩展性
第三部分，可扩展的架构方案重点介绍了AFK立方体：
从三个维度提升系统的扩展性，思路值得借鉴，和目前服务拆分、领域驱动模型设计所遵循的原则类似。
可扩展的架构技术在实现层面的详细介绍有本书的姊妹篇 《架构真经》。