1 大道至简

1.1 规则1 避免过度设计

【内容】在设计中警惕复杂的解决方案
【应用场景】适用于任何项目，应用所有大型项目和复杂系统或项目设计过程中
【用法】通过测试同事是否轻松的理解解决方案，来验证是否存在过度设计
【原因】复杂的解决方案实时成本过高，而且长期维护费用昂贵
【要点】过于复杂的系统限制了可扩展性。简单的系统易维护、易扩展。

1.2 规则2 方案中包括扩展

【内容】提供可扩展的DID方法
【应用场景】所用项目通用，是保证 可扩展方案的最经济有效的方式（资源和时间）
【用法】

• Design (D) 设计容量的30倍
• Implement (I) 实施3倍的容量
• Deploy （D）实施容量的1.5倍

【原因】 DID提供了经济、有效的、及时的方法。
【要点】在早期的考虑的可扩展性可以帮助团队节省时间和金钱。在需求发生一个月之前写完代码。在客户蜂拥至上的前几天部署

1.3 规则3 三次简化方案

【内容】在设计复杂系统时，从项目范围、设计和实施3个方向简化方案。
【应用场景】设计复杂系统或产品时，面临着技术和计算资源的限制
【用法】

• 采用帕累托(Pareto)原则简化范围
• 考虑成本优化和可扩展性来简化设计
• 依靠其他人的经验来简化部署

【原因】只关注“”不过度复杂“，并不能解决需求或历史发展或历史发展与前革中的各种问题
【要点】在产品研发的各个阶段都需要简化。
1 如何简化方案的范围？
不断使用帕累托法则，（也叫80-20%原则），不做那些不重要的需求。
2 如何简化方案设计？
不必把功能和场景设定的过于复杂。
3 如何简化方案的实施？
如何利用其它经验和解决方案的简化实施。开源项目还是其他模块。

1.4 规则4 减少域名解析

【内容】从用户角度减少域名解析次数
【应用场景】对性能敏感的所有页面
【用法】尽量减少下载页面所需的DNS解析测试，但要保证与浏览器的并发连接平衡。
【原因】域名解析耗时影响严重
【要点】减少对象、任务、计算等是加快页面速度的好办法，但要考虑分工。
使用多层缓存可以使用域名转化为IP地址的过程快速完成，缓存部署在包括浏览器、计算机操作系统、互联网服务提供商等多个层级以上。
谷歌或其他浏览器对每个服务器和网关最大连接数做了6个限制。

1.5 规则5 减少页面目标

【内容】尽可能减少网页下载的对象数
【应用场景】对性能敏感的所有页面
【用法】

• 减少或合并对象，但要平衡最大并发连接数
• 寻找机会减轻对象的重量
• 不断测试确保性能的提升

【原因】对象数量的多少直接影响网页的下载时间耗时
【要点】对象和服务对象的方法之间的平衡是一门科学，需要不断地测试和调整。这是在客户的易用性好、可用性和性能之间的平衡。
把网页的内容最好拆分足够多的对象，与并发是保持一致。把不同的网页对象储存在不同的子域名上。

1.6 规则6 采取同构网络

【内容】确保交换机和路由器源于同一个供应商
【应用场景】设计和扩大网络
【用法】

• 不要混合使用不同OEM的交换机和路由器
• 购买或者使用开启的其他网络设备防火墙、负载均衡

【原因】节约成本与间歇性的互用性问题相比不值得
【要点】异构引起可用性和可扩展性问题。

2 分而至之

AKF扩展立方体（Scalability Cube），是《架构即未来》和 《架构真经》 书中提出的可扩展模型，这个立方体有三个轴线，每个轴线描述扩展性的一个维度，他们分别是产品、流程和团队：

X轴 —— 代表无差别的克隆服务和数据，工作可以很均匀的分散在不同的服务实例上；

Y轴 —— 关注应用中职责的划分，比如数据类型，交易执行类型的划分；

Z轴 —— 关注服务和数据的优先级划分，如分地域划分。

1.X轴扩展

优点：成本最低，实施简单；

缺点：受指令集多少和数据集大小的约束。当单个产品或应用过大时，服务响应变慢，无法通过X轴的水平扩展提高速度；

场景：发展初期，业务复杂度低，需要增加系统容量。

2.Y轴扩展

优点：可以解决指令集和数据集的约束，解决代码复杂度问题，可以实现隔离故障，可以提高响应时间，可以使团队聚焦更利于团队成长；

缺点：成本相对较高；

场景：业务复杂，数据量大，代码耦合度高，团队规模大。

3.Z轴扩展

优点：能解决数据集的约束，降低故障风险，实现渐进交付，可以带来最大的扩展性。

缺点：成本最昂贵，且不一定能解决指令集的问题；

场景：用户指数级快速增长

2.1 规则7 X轴扩展（水平扩展部署）

【内容】通常叫水平扩展，通过复制服务或数据库以分散事物处理负载。
【应用场景】

• 数据库读写比例很高（5:1甚至更高，越高越好）
• 事物增长超过数据增长的系统

【用法】

• 克服服务的同时配置负载均衡器
• 确保使用数据库的代码清楚读和写之间的区别

【原因】以复制数据和功能为代价获得事物的快速扩张
【要点】X轴拆分实施速度快、研发成本低，事物处理效果好。数据运维成本低。

分散数据的几种方法：
1 查询加缓存
2 数据库复制

2.2 规则8 Y轴拆分（服务拆分–拆分不同的东西）

【内容】有时也称为服务或者资源扩展，本规则聚焦在沿着动词（服务）或名词（资源）的边界拆分数据集、交易和技术团队。
【应用场景】

• 数据之间的关系不是那么必要的大型数据集
• 需要专业化拆分技术资源的大型复杂系统。

【用法】

• 用动词来拆分动作，用名词拆分资源，或者两种混用
• 沿着动词、名词定义的边界拆分服务器和数据。

【原因】不仅允许事物以及相关的大型数据集有效扩展，也支撑团队的有效性。
【要点】Y轴或者面向数据和服务的拆分允许事物和大型数据集的有效扩展，有益于故障隔离，Y轴拆分也有助于减少团队之间的非必要沟通

2.3 规则9 z轴拆分(分片–拆分类似的东西)

【内容】经常根据客户的独特客户属性（例如ID、姓名、地理位置等）进行拆分。
【应用场景】非常大的类似的数据集，如庞大而且增长快速的客户群，或者响应时间对在地图上广泛分布的客户变得很重要的时候。

【用法】根据所知道的客户属性（例如ID、姓名、地理位置等）进行拆分。。

【原因】客户的快速增长超过了其他形式的数据增长，或者再扩展时，需要在某些客户群之间进行必要的故障隔离。
【要点】Z轴拆分对扩大客户基数效果明显，也用在其他那些无法使用Z轴拆分的大型数据集上。

3 水平扩展

3.1 规则10 向外扩展

【内容】向外扩展时通过复制或拆分服务或数据库而分散事物负载的方法，与之相对的是向上扩展（扩展硬件）。
【应用场景】任何预计迅速增长或追求低成本高效的系统、服务或者数据库。
【用法】用AFK制定正确的拆分方法。最简单的就是水平拆分
【原因】以复杂数据和功能为代价实现事务的快速扩展
【要点】让系统向外扩展而不是向上扩展。

3.2 规则11 用商品化系统（金鱼而非汗血宝马）

【内容】尽可能采用小的廉价系统。
【应用场景】在超高速增长的系统采用该方法，在比较成熟的产品中使用该方法。
【用法】在生产环境中原理那些庞大的系统
【原因】可快速和低成本增长。只采购必要的容量，不浪费在尚未明确的容量上。
【要点】构建能够依赖高商业化硬件系统，不要掉进高利润的陷阱。

3.3 规则12 托管方案扩展

【内容】把系统部署到三个或更多的数据中心，以降低成本、增加可用性，并实现容灾恢复。数据中心可以是自有设施、托管或云计算。
【应用场景】任何正在考虑添加容灾恢复数据中心的快速增长的业务，或希望通过第三方数据中心方案优化成本的成熟业务。
【用法】以多活方式配置系统。
【原因】数据中心故障对业务影响是灾难的，需要3个以上的数据中心。
【要点】如果系统扩展到三个以上数据中心，则为N-1个数据中心可用，功能不受影响。

3.4 规则13 利用云

【内容】有目的的利用云技术按需扩充
【应用场景】当需求是临时的、突增的、偶发的。响应时间不是产品的核心问题。公司从双活向三活数据中心迁移时，可用作为付三数据中心。
【用法】

• 采用第三方云环境应对临时需求，如季节向业务变动
• 用户请求超过某个峰值，扩展云应对高峰期。
  【原因】在云环境中配置硬件硬件可能只需要几分钟，在自己的托管设施配置物理设施可能几天或者几周。
  【要点】在所有网站采用虚拟化技术，并在云中扩展以应付意想不到的突发需求。

4 先利其器

4.1 规则14 适当使用数据库

【内容】需要一致性可以使用关系数据库上，其他数据的存储需要考虑更适合的工作，如NoSQL DBMS
【应用场景】当在系统架构中引入新数据或者数据结构时。
【用法】考虑数据量和储存、响应时间长短、关系和其他因素来选择适当的存储工具。也要考虑数据结构以及产品需要对数据进行管理和操作。
【原因】关系数据库能保证一致性，成本很高，难扩展，而且与其他许多可选系统相比可用性低。
【要点】使用合适的数据储存工具，不要因为易访问而用关系型数据库存储所有数据。

4.2 规则15 慎用防火墙

【内容】只有在能够显著降低风险是才使用防火墙。要认识到防火墙会导致可扩展性和可用性的问题。
【应用场景】所有。
【用法】可以使使用防火墙满足关键的PII\PVI的合规性要求，不太用在静态内容防护上面（css js）。
【原因】防护强会降低可扩展性并引起不必要的可扩展瓶颈。
【要点】防火墙虽然有用，但经常被滥用，设计和实施不当会带来可用性和可扩展问题。

4.3 规则16 积极使用日志文件

【内容】使用应用日志来诊断和预防问题。
【应用场景】制定监控日志文件的过程，迫使人们对发现的问题采取行动
【用法】制定监控工具，从自定义脚本到spunk或者ELK架构，监视应用日志中的错误，导出这些错误信息，安排资源去确定和解决问题。
【原因】日志文件是有关应用执行的绝好信息来源，不要轻易放弃。
【要点】若充分利用好日志问价，生成问题将越来越少，且当问题出现的时候可以迅速定位。

splunk ELK 和Kibana

5 画龙点睛

5.1 规则17 避免画蛇添足

【内容】翻来覆去的检查刚完成的工作或者马上读取刚写入的数据
【应用场景】总是
【用法】避免为了确认操作是否有效而读取刚写入的数据，如近期处理需要，可把数据存储在本地或分布式缓存中。
【原因】与不太可能出现的操作失败所产生的失败成本比，确认操作成本更高。与可扩展相违背。
【要点】永远不要为确认操作是否有效而读取刚刚写入的书。

5.2 规则18 禁止重定向

【内容】如果可能，避免重定向；确认需要时，采用正确的方法
【应用场景】总是
【用法】如需重定向，考虑通过服务器配置来实现，而不是利用HTML或者其他基于代码的解决方案。
【原因】重定向会延迟用户进程，消耗计算机资源，造成错误，不利于页面在搜索中的排名。
【要点】正确且必要时才使用重定向。
http协议中定义了3xx状态码，好像重定向是有理由的， 。
1 Apache服务器有mod_alias和mode_rewrite模块完成重定向。
2 想办法绕开重定向。

5.3 规则19 放宽时间约束

【内容】尽可能放宽系统中的时间约束
【应用场景】考虑在用户的操作某个步骤之间某些项目和对象必须保证某种状态约束时。
【用法】放宽业务规则的约束。
【原因】因为大多数关系数据库的AICD属性，扩展带有时间约束的系统难度极高。
【要点】认真考虑诸如某个产品从用户查看开始，到购买为止的时间约束的必要性。让用户有些失望，比系统无法扩展而停止服务的服务相比更为严重。
非立即生效，如BASE理论，购买商品，只有提交订单才会锁定。用户看到可以购买不代表真的可以购买。

6 缓存为王

互联网平台上的内容可以分为静态和动态两种。静态内容指那些不经常改变的文本和图像。动态内容是指随着时间的推移，不断变化的内容。
多层次缓存会使排查产品问题更加困难，因此应设计缓存监控系统。缓存也是需要设计可扩展性。

6.1 规则20 利用CDN缓存

【内容】用CDN（内容分发网格）来减少网站的复杂
【应用场景】速度提升和可扩展性的提升，可以平衡额外的成本。
【用法】大多数CDN借助DNS为网络提供内容。因此可能需要在DNS上做出小改动和添加记录，以便吧提供的内容的网址迁移到新的子域名上。
【原因】CDN有助于平缓流量高峰。常常网站流量扩展比较经济方式
【要点】CDN是快速而且简单的平缓高峰流量和一般流量增长的方式，平衡成本和收益，并监控CDN的使用量 。

假定某网站因为流量太大，决定采用 CDN 来解决问题。首先，会在域名服务器上新建一个别名把用户的请求从www.akfpartners.com/techblog指向1107.c.cdn_vendor.net（参见上图中的 DNS 表）。其次，当用户浏览器向域名服务查询（步骤 1）akfpartners.com时，接收到返回的 CDN 域名（步骤 2），然后，再对 CDN 域名进行另一轮域名服务查询（步骤 3），接收到返回的与1107.c.cdn_vendor.net相关的 IP 地址（步骤 4），最后，接收请求并将其路由到服务网站的某个 IP（步骤 5 – 6）。网站的内容缓存在 CDN 服务器上，CDN 服务器定期查询网站的源服务器以便更新。

正如本例所示，在网站服务器前使用 CDN 的效果是，CDN 负责处理所有的请求，只有当需要查询缓冲内容是否更新时才会访问源服务器。因此，只需要购买少量低配置的服务器和网络带宽，以及少数维护基础设施的人员。无论网站的网页是动态还是静态，都可以考虑加入 CDN 形成混合缓存。该层缓存可以提供快速交付的好处，通常有非常高的可用性，而且网站服务器处理更少的流量

6.2 规则21 灵活管理缓存

【内容】用CDN（内容分发网格）来减少网站的复杂
【应用场景】速度提升和可扩展性的提升，可以平衡额外的成本。
【用法】大多数CDN借助DNS为网络提供内容。因此可能需要在DNS上做出小改动和添加记录，以便吧提供的内容的网址迁移到新的子域名上。
【原因】CDN有助于平缓流量高峰。常常网站流量扩展比较经济方式
【要点】CDN是快速而且简单的平缓高峰流量和一般流量增长的方式，平衡成本和收益，并监控CDN的使用量 。

未完待续。。。。。。。。。。。

7前车之鉴

7.1 规则27 失败乃成功之母

【内容】学习失败经验吸收教训
【应用场景】从成功和错误中学习。
【用法】观察客户和A/B测试验证。建立事后分析过程。
【原因】CDN有助于平缓流量高峰。常常网站流量扩展比较经济方式
【要点】CDN是快速而且简单的平缓高峰流量和一般流量增长的方式，平衡成本和收益，并监控CDN的使用量 。

7.2 规则28 不靠QA发现问题

【内容】学习失败经验吸收教训
【应用场景】从成功和错误中学习。
【用法】观察客户和A/B测试验证。建立事后分析过程。
【原因】CDN有助于平缓流量高峰。常常网站流量扩展比较经济方式
【要点】CDN是快速而且简单的平缓高峰流量和一般流量增长的方式，平衡成本和收益，并监控CDN的使用量 。

7.3 规则29 不能回滚注定失败

【内容】必须具备代码回滚能力
【应用场景】却包所有版本都有回滚能力。
【用法】清理代码并遵循几个简单的步骤以确保可以回滚代码。
【原因】如果没有经历过无法回滚代码的并，那么随时在未来时刻体会这种痛苦。
【要点】稳健的飞行员不会再飞机不能着陆时起飞 。

8 重中之重

8.1 规则30 从事物处理中清除商务智能

商务智能（BI）是指用现代数据仓库技术、线上分析处理技术、数据挖掘和数据展现技术进行数据分析以实现商业价值。包含了数据分析的过程，重点体现在给企业带去商业价值，让企业决策者得到有价值的洞察力，使他们能够做出更优决策。随着云计算、SaaS（软件即服务）、大数据的发展和成熟，商务智能BI 已经不再是一个锦上添花的软件，越来越多的企业开始使用商务智能BI来提高企业竞争力。在未来商业智能将广泛普及，以数据为中心的企业管理将成为常态.。在线分析系统。
产品智能:将产品逻辑放入数据流存储过程中。

【内容】业务系统与产品系统分析、产品智能与数据库系统分离。
【应用场景】任何考虑公司内部需求和将数据转入、转出或在产品中间转换的时候
【用法】把存储过程重数据库迁移至应用逻辑。在公司和产品系统之间不做同步调用。
【原因】1 把应用逻辑放入数据库是昂贵的，且难以扩展的。2 把公司系统和产品系统绑定在一起也是非常昂贵的，同样会影响可扩展性并带来可用问题
【要点】由于许可证读系统独特性，扩展数据库和公司内部成本可能很高。1 对于数据库而言，我们希望数据库专用于事物处理，不是产品智能 2 对于商务智能骂我们不希望产品性能与这些系统的扩展能力挂钩

8.2 规则31 注意昂贵关系

【内容】注意数据模型的关系
【应用场景】当设计数据模型、添加表、列、写查询语句或从长计议，考虑实体之间的关系会如何影响效率和可扩展性。
【用法】当设计数据模型时，考虑数据库分离和未来可能的需求。
【原因】实施修改破幻数据模型的费用将是设计过程中修复的100倍
【要点】超前考虑，仔细计划数据模型。设计范式时，考虑将来如何查分数据库和应用系统可能的数据需求。
未完待续。。。。。。。。。。。

8.3 规则32 正确使用数据库锁

【内容】理解数据库的明锁和监控暗锁。
【应用场景】使用关系型数据库时。
【用法】代码审核是注意数据库明锁，选择允许锁类型和粒度灵活的数据库和存储引擎。
【原因】最大化数据库并发性和吞吐量
【要点】理解和管理数据库锁的使用，选择最优的数据库锁类型，多种锁配置也保证最低吞吐量。

8.4 规则33 禁止使用多段提交

【内容】不要使用多段提交协议来存储或处理事物。
【应用场景】总是传递或不使用分段提交。
【用法】采取Y轴或Z轴拆分数据存储和处理系统。
【原因】分段提交就是一个阻塞协议，它阻塞其他事物处理直到其完成。
【要点】理解和管理数据库锁的使用，选择最优的数据库锁类型，多种锁配置也保证最低吞吐量。

未完待续。。。。。。。。。。。

8.5 规则34 慎用select for update

【内容】定义有标识，select 语句应少使用for update。
【应用场景】总是。
【用法】审查并质疑每一个select for update。
【原因】select for update锁定行。
【要点】select for update锁定行，导致长时间占用锁，降低低吞吐量。

8.6 规则35 避免选取所有列

【内容】不要使用select *。
【应用场景】总是。
【用法】明确要查询和插入的列。
【原因】表结构变化。
【要点】明确要查询和插入的列。

9 有备无患

9.1规则36 用泳道隔离故障

【内容】在设计中实现故障隔离区或泳道
【应用场景】为可扩展性开始拆分持久层或服务时。
【用法】沿着Z或Y轴拆分持久层或服务时，禁止故障隔离的服务和数据见同步通信和访问。
【原因】提高可扩展性和可用性，减少返现和解决故障的时间。缩短上市的成本和时间。
【要点】故障隔离包括根除故障夜间的同步请求，限制异步调用和同步调用失败，以及避免泳道之间的服务和数据共享。

未完待续。。。。。。。。。。。

9.2规则37 拒绝单点故障

【内容】在设计中永远不要有单点故障的系统
【应用场景】架构审查和新系统设计时。
【用法】在架构图设计上，寻找单个实例。尽可能配成主动或主动模式
【原因】通过多实例配置最大化可用性。
【要点】努力实施主动/主动而非主动/被动配置。使用负载均衡器在服务的不同实例之间实现流量平衡。对需要单例的情行，可以在中/被动模式的实例中采用控制器。
1 采取主/被动配置。热/冷配置通常去除SPOF的第一步
2 使用其他组件控住数据访问，配置成主从模式。或负载均衡。

9.3规则38 避免故障串联

【内容】避免以串联方式连接的组件数量
【应用场景】每次考虑添加组件时。
【用法】删除不必要的组件、收起组件或添加多个并行组件以减少影响
【原因】串联组件受多重失败乘法的效应影响。
【要点】避免向串联系统添加组件。如果有必要这样做，添加多个版本的组件，如果一个出故障，其他组件可以取代它的位置。

9.4 规则39 启用和禁用功能

【内容】搭建一个框架来启动与禁用产品功能。
【应用场景】考虑上下线框架控制新的研发的、非关键性的或者依赖第三方的功能。
【用法】研发共享库以自动或基于请求的方式控制功能的启用与禁止，参见下表。
【原因】为了保护对最终用户很重要的关键功能，关闭有问题或非关键性的功能。
【要点】当实施成本低于风险损失时，实现上下线框架。开发可以服用的共享库以降低未来实施的成本。
有时公司将类似的功能称为功能切换或断路器。

。。。。。。。。。

10 超然物外

。。。。。。。。。

10.1 规则40 力求无状态

【内容】设计和实施无状态系统。
【应用场景】在设计新系统和重现设计现有系统时。
【用法】尽可能选择无状态的实施方案。如业务必须，可以实施状态方案，参见规则41和42
【原因】有状态可能限制可扩展性、降低可用性并增加成本。
【要点】始终拒绝任何系统中状态的需求，采用业务指标和对比（A/b测试）来确定应用中的状态是否能带来价值。

10.2 规则41 在浏览器中保存会话数据

【内容】彻底避免会话数据，但需要时，考虑把数据保存在用户的浏览器中。
【应用场景】任何为了用户体验而需要保存的回话数据的场合。
【用法】在用户的浏览器中使用cookie来保存数据
【原因】在用户的浏览器中保存会话数据，允许任意Web服务器为用户请求提供服务，并减少存储要求。
【要点】使用cookie来保存数据，优点是易扩展，需要加密防劫持。

10.3 规则42 用分布式缓存处理状态

【内容】使用分布式缓存在系统中存储会话数据。
【应用场景】任何需要存储会话数据但又不能再用户的浏览器上存储的情况。
【用法】主要一些常见错误，如需要用户对web服务器黏性的会话管理
【原因】仔细考虑如何存储会话数据以帮助确保系统可以继续扩展。
【要点】。

。。。。。。。。。。。。。。。。。。。

11 异步通讯

11.1 规则43 尽可能异步通信

【内容】尽可能使用异步通信而不是同步通信。
【应用场景】服务与层之间的所有调用尽可能是异步实现，特别是所有非关键请求。
【用法】使用特定语言调用，以确保请求是以非阻塞方式发出且调用方不阻止等待响应
【原因】同步调用导致连续性延迟缓。
【要点】采用异步通讯技术确保服务和层尽可能独立，使系统扩展能力远超所有的组件紧密耦合在一起的情况 。

11.2 规则44 扩展消息总线

【内容】同任何物理或逻辑系统一样，消息总线也会因需求而失败，需要扩展。
【应用场景】消息总线是架构一部分。
【用法】采用Y轴或Z轴拆分
【原因】确保消息总线系统可以扩展满足需求。
【要点】对待任何其他关键组件那样对待消息总线 。

11.3 规则45 避免消息总线拥堵

【内容】总线流量仅限那些价值高于处理成本事件。
【应用场景】在任何消息总线上。
【用法】去除低价值高成本的流量
【原因】消息流量不是免费的。
【要点】确保成本与价值之间的平衡。

12 意犹未尽

12.1 规则46 警惕第三方方案

【内容】不要依赖第三方解决方案来实现可扩展性。
【应用场景】每当考虑第三方新功能和新产品时。
【用法】尽可能用最简单的方式使用供应商的产品。
【原因】消息流量不是免费的。
【要点】1 掌握自己的命运 2 保持架构的简单 3降低总成本。

12.2 规则47 梯级存储策略

【内容】将存储成本与数据价值匹配，包括删除价值低于存储成本的数据 。
【应用场景】设计时期间及数据的整个生命周期，应用于数据及其基础存储设施。
【用法】将存储成本与数据价值匹配。
【原因】数据价值是不同的，不能采用单一的存储解决方案。
【要点】理解和计算存储成本与数据价值。
。。。。。。。。。。。。。。。。

12.3 规则48 分类处理不同负载

【内容】 。
【应用场景】 。
【用法】 。
【原因】 。
【要点】 。

12.4 规则49 完善监控

【内容】设计时考虑什么才能监控应用 。
【应用场景】 每当增加或修改代码库的模块时。
【用法】 在系统中适当埋点记录事务时间。
【原因】 深入了解应用的性能将有助于在出现故障时回答许多问题。
【要点】 把监控应用作为一条架构原则。
监控系统可以解决“”有问题吗“” 问题在那 和什么问题 三个核心问题。

12.5 规则50 保持核心竞争力

【内容】设计时考虑什么才能监控应用 。
【应用场景】 任何解决方案。
【用法】系统中每个组件，确定职责和核心竞争力。
【原因】 。
【要点】 可以购买解决方案，部署、运维要保持核心竞争力 。

参考

1 https://guobinhit.blog.csdn.net/article/details/70234185
2 架构真经
3 https://blog.csdn.net/weixin_44337261/article/details/89838601