读书笔记思考总结《AKF15条架构原则》

Posted 2022-12-06 在路上的德尔菲

N + 1设计

永远不要少于两个，通常为三个。比方说无状态的Web/API一般部署服务器至少>=2个。(高可用)

回滚设计

确保系统可以回滚到以前发布过的任何版本。可以通过发布系统保留历史版本。发布阶段做到可监控、可灰度、可回滚。(高可用)

禁用设计

高可用：能够关闭任何发布的功能。如注册中心节点下线，或者使用动态开关机制(Feature Switch)，可以按需一键打开，如发现问题随时关闭禁用。(高可用)

监控设计

高可用：在设计阶段就必须考虑监控，而不是在实施完毕之后补充。例如在需求阶段就要考虑关键指标监控项，这就是度量驱动开发(Metrics Driven Development)的理念。监控、日志、链路追踪三驾马车。(高可用)

设计多活数据中心

高可用：不要被一个数据中心的解决方案把自己限制住。一般异地部署，两地三中心，当然也要考虑成本和公司规模发展阶段。(高可用)

使用成熟的技术

只用确实好用的技术。商业组织毕竟不是研究机构，技术要落地实用，成熟的技术一般坑都被踩平了，新技术在完全成熟前一般需要踩坑躺坑。但是也要考虑适合自己业务场景的技术，不能因为技术成熟而选择不适合自身的技术，毕竟适合的才是最好的。（）

异步设计

能异步尽量用异步，对于时效性有要求，同步线程非阻塞，处理效率不高，只有当绝对必要或者无法异步时，才使用同步调用。（高性能）

无状态系统

尽可能无状态，只有当业务确实需要，才使用状态。无状态系统易于扩展，有状态系统不易扩展且状态复杂时更易出错。(高可用)

水平扩展而非垂直升级

永远不要依赖更大、更快的系统。在上条无状态的基础快速水平扩展。(高可用)

设计时至少要有两步前瞻性

在扩展性问题发生前考虑好下一步的行动计划。架构师的价值就体现在这里，架构设计对于流量的增长要有提前量，不仅思考现在如何实现，而且要考虑未来可能产生的的各种问题，考虑应用的扩展性。(高扩展)

非核心则购买

如果不是你最擅长，也提供不了差异化的竞争优势则直接购买，因此现在IaaS、PaaS、SaaS服务越来越多，让我们更好的聚焦于业务发展。（成本）

使用商品化硬件

在大多数情况下，便宜的就是最好的。（成本）

小构建、小发布和快试错

研发全部研发要小构建，不断迭代，让系统不断成长。小步快跑，不要一次性构建很多功能，最好是分批次多次数构建，及时发现问题。（研发效率）

隔离故障

实现故障隔离设计，通过断路保护避免故障传播和交叉影响。通过舱壁泳道等机制隔离失败单元(Failure Unit)，一个单元的失败不至影响其它单元的正常工作。措施从小到大可分为线程隔离、进程隔离、集群隔离、机房隔离。（高可用）

自动化

设计和构建自动化的过程，如果机器可以做，就不要依赖于人。DevOps思想。

AKF扩展立方体

如何设计和分解微服务？
从粒度上看，如果服务分解过细，则会增加通信成本和运维成本；如果服务分解过粗，那么又达不到单独伸缩和运维的目的。两个原则可以在微服务拆分时借鉴：单一职责原则和共同封闭原则，单一职责让微服务保持足够小，仅拥有一个业务职责，保持微服务的业务单一性，共同封闭原则是指将那些业务概念联系得非常紧密的、通常一起发生改变的类，封装到同一个包中，这样当业务发生改变只需要一个业务团队单独修改。

《架构即未来》一书中提出了AFK扩展立方体，将应用抽象总结出可扩展的三个维度：产品、流程和团队

X轴: 关注水平的数据和服务复制，比如主备集群，数据完全一样复制。克隆多个系统(加机器)负载均衡分配请求。

• 优点：成本最低，实施简单
• 缺点：当个产品过大时，服务响应变慢
• 场景：发展初期，业务复杂度低，需要增加系统容量

Y轴:关注应用中职责的划分，比如数据业务维度拆分。比如把一个大库分为交易库，商品库，会员库拆分。

• 优点：故障隔离，提高响应时间，更聚焦
• 缺点：成本相对较高
• 场景：业务复杂，数据量大，代码耦合度高，团队规模大

Z轴: 关注服务和数据的优先级划分，比如在上面基础上按用户维度买家卖家切分，地域切分Set化。

• 优点：降低故障风险，影响范围可控，可以带来更大的扩展性
• 缺点：成本最高
• 场景：用户指数级快速增长
  

X轴和Z轴的扩展仅仅是提升了应用的容量和可用性，但没有解决随着业务发展日益巨增的开发、运维复杂度，而Y轴的扩展使得我们可以从业务功能的角度将庞大的单体应用进行分而治之，一方面降低了业务开发、运维的复杂度，另一方面通过分而治之可以实现服务故障的隔离，提高系统的响应时间，其次，拆分后可以控制每个团队的规模，让团队的工作更加聚焦，有利于团队的成长。

微服务架构的优点

• 松耦合：服务之间通过非具体实现的接口
• 抽象：只有该服务才可以对数据做出修改，其他微服务只有通过该服务才能够访问数据
• 独立：独立编译、打包、部署
• 应对用户需求的多样性：不同服务承担不同的职责
• 高可用性和弹性：去中心化的应用，每个服务都可以随时快速上线或下线

微服务机构缺点

• 处理分布式事务较棘手：传统开发通常会使用两阶段提交方案解决这个问题，但对于微服务架构而言并不是好的选择
• 全能对象组织业务拆分
• 学习难度曲线加大
• 组织架构变更