架构实战案例解析¶
2020-02-19
王庆友
前 1 号店首席架构师
笔记时间：2022-10
备注
【书评】本文对我的帮忙不太大，亮点在一些实例的讲解上，参照我之前的工作经历，两相验证，明白了一些内容。整体上是讲架构分为业务架构和技术架构。业务架构讲扩展性和复用性；技术架构讲可用性和伸缩性。一个好的架构师需要有：基础（编程能力）技术上有一定的广度和深度，更重要的是抽象思维能力以及通过现象看到本质的能力，除此之外就是沟通能力和取舍能力。特别是09节的系统改造实例，让我想起了之前走的坑和积累的经验。
目录
01概述篇 (2 讲)¶
开篇词¶
成为一名优秀的架构师:
1. 首先，你需要跳出当前的小模块，站在系统整体的角度来考虑问题。
2. 其次，你不仅要从技术的角度考虑问题，也要学会从业务的角度来考虑问题，深入理解系统的挑战在哪里，不要在错误的地方发力。
3. 最后，你需要做好各方面的平衡，能在现有的各项资源约束下，寻求一个最优解。
业务架构篇:
扩展性和复用性
技术架构篇:
高可用和高性能 / 可伸缩
高可用的策略有避免事故、降低影响、快速恢复等
高可用的架构原则有无单点、可监控、水平扩展
01 | 架构的本质¶
架构的本质¶
熵增定律
备注
架构的本质就是：通过合理的内部编排，保证系统高度有序，能够不断扩展，满足业务和技术的变化。
首先，架构的出发点是业务和技术在不断复杂化，引起系统混乱，需要通过架构来保证有序。
其次，架构实现从无序到有序，是通过合理的内部编排实现的，基本的手段，就是 “分” 与 “合”，先把系统打散，然后将它们重新组合，形成更合理的关系。
架构的分类¶
业务架构就是讲清楚核心业务的处理过程，定义各个业务模块的相互关系，它从概念层面帮助我们理解系统面临哪些问题以及如何处理
应用架构就是讲清楚系统内部是怎么组织的，有哪些应用，相互间是怎么调用的，它从逻辑层面帮助我们理解系统内部是如何分工与协作的
技术架构就是讲清楚系统由哪些硬件、操作系统和中间件组成，它们是如何和我们开发的应用一起配合，应对各种异常情况，保持系统的稳定可用
备注
开发的痛点主要由业务架构和应用架构来解决，机器的痛点主要由技术架构来解决。做架构设计时，一般是先考虑业务架构，再应用架构，最后是技术架构。
什么是好的架构¶
一个好的架构必须满足两方面挑战：业务复杂性和技术复杂性。一个好的架构设计既要满足业务的可扩展、可复用；也要满足系统的高可用、高性能和可伸缩，并尽量采用低成本的方式落地。所以，对架构设计来说，技术和业务两手都要抓，两手都要硬。
什么是好的架构师¶
首先是一个出色的程序员，在此基础上，架构师要有技术的广度（多领域知识）和深度（技术前瞻）。此外，架构师还需要有思维的高度，具备抽象思维能力。架构师还需要有思维的深度，能够透过问题看本质。还有很重要的一点，能落地的架构才是好架构，所以架构师还需要具备良好的沟通能力（感性），能确保各方对架构达成共识，愿意采取一致的行动；而良好的平衡取舍能力（理性），可以确保架构在现有资源约束下是最合理的，能让理想最终照进现实。¶
抽象思维是架构师最重要的能力，架构师要善于把实物概念化并归类。比如，面对一个大型的 B2C 网站，能够迅速抽象为采购 -> 运营 -> 前台搜索 -> 下单 -> 履单这几大模块，对系统分而治之。
备注
如果说对于开发来说，最重要的是逻辑能力，那对于架构师来说最重要的是抽象思维能力，然后是学习能力（技术和业务）和平衡取舍能力。
评论¶
业务架构关注系统大的业务流，数据流和资金流，举个例子，假设 A 要通知 B，在业务架构里，我们简单标识 A”通知”B，过程中传递了什么信息即可；
在应用架构图里，这个具体的通知方式要给出，也就是从逻辑上理解这个过程是怎么回事的，可能是 A 同步调用 B；也可能是 B 定时轮询 A 的接口获取信息，还有可能是 A 先发送消息到 MQ，然后有个监听应用负责接收消息，然后调用 B 的接口实现。
技术架构，还要把具体的 MQ 技术选型给出来，是 RabbitMQ 呢，还是 Kafaka。当然在技术的架构图里，很可能有些地方按照业务架构简化表达，有些部分给出具体的技术选型，这个我们清楚就可以，不必太纠结，不是每个系统都要给出 3 个架构图，那太麻烦。
02业务架构篇 (9 讲)¶
02业务架构¶
从架构角度看，业务架构是源头，然后才是技术架构。
产品经理的职责¶
简单来说，产品经理的职责就是：告诉用户，系统长什么样子；告诉开发，他要实现什么功能。
产品经理首先会收集用户的原始需求，然后，将它们梳理成一个个业务流程，每个业务流程由多个业务步骤组成。一个业务步骤包含三部分的内容：输入、输出和业务功能。
经过产品经理的工作，大量零散的原始需求经过梳理和关联，变成一系列有序的业务流程，以及流程里面的业务步骤（业务步骤也称之为业务节点），然后产品经理把这一系列的业务流程和业务节点以用户界面的方式定义出来，总的来说，产品经理定义了系统的外表。
作用：让用户了解系统长什么样子，应该如何使用这个系统，以及系统是否满足他们的需求
业务架构师的职责¶
先把所有的业务流程拆散，这样得到了一堆业务节点；然后把业务节点进行归类，相关的业务节点放在同一个系统模块里。判断节点是否相关，主要看它们是否属于同一个业务领域，比如一个订单查询的节点，和订单创建的节点，它们都属于订单域，那么这些节点都可以归属到同一个订单模块里。
系统模块按业务流程拆分¶
如果按照业务流程来拆分系统模块，那么，有多少业务流程，就有多少个系统模块，这个对应关系比较直接，但实现起来很困难。
如果按照业务域来拆分，有多少业务领域，就有多个系统模块，流程中的业务节点按照业务域的不同，可以划分到不同的系统模块。
备注
对业务架构师来说，TA 的工作，就是把业务流程和节点打散，按照业务域的维度来划分系统模块，并定义这些模块之间的关系，最终形成一个高度结构化的模块体系。
两者对比¶
产品经理和业务架构师的工作既有区别又有联系，简单地说，产品经理定义了系统的外观，满足了用户；业务架构师在此基础上，进一步定义了系统的内部模块结构，满足了开发人员。
产品经理需要的能力主要偏向用户和商业模式，所以常说要有同理心、洞察人性、懂得用户心理和行为、了解市场；而业务架构师要能把业务划分出领域，业务由领域中不同的点串联成流程，便于团队组织用最小代价实现，需要有强的分析能力，找到系统中的变与不变
架构目标之¶
业务的可扩展¶
业务的主题是变化和创新，系统的主题是稳定和可靠。¶
支付宝的业务架构变化过程¶
业务的可复用¶
首先，模块的职责定位要非常清晰。
其次，模块的数据模型和接口设计要保证通用。
最后，实现模块的高复用，还需要做好业务的层次划分。
在一个实际的业务架构中，模块是怎么划分的，架构的可扩展和高复用是如何体现的。¶
评论¶
一般来说三个图:
1. [偏业务架构]模块的静态结构图，描述各个模块的层次关系
2. [偏应用架构]模块的动态关系图，比如业务流，数据流，调用关系
3. 针对核心的场景，补充交互序列图，从具体过程理解交互关系。根据需要，可能还需要状态机，核心库表模型等等
03 | 可扩展架构¶
系统的构成：模块 + 关系¶
模块¶
从扩展性的角度出发:
首先，对模块的要求是：定位明确，概念完整。
其次，模块还要：自成体系，粒度适中。
尽量围绕自身内部数据进行处理，对外部依赖越小，模块的封装性越好，稳定性也越强，不会随着外部模块的调整而调整。
高内聚低耦合
依赖关系¶
依赖关系定义了模块如何协作，一起完成业务流程，依赖关系实质上体现的是模块的组织结构。
扩展性的本质¶
业务架构扩展性的本质是：通过构建合理的模块体系，有效地控制系统复杂度，最小化业务变化引起的系统调整。
具体的架构手段就是按照业务对系统进行拆分和整合：通过拆分，实现模块划分；通过整合，优化模块依赖关系。
打造可扩展的模块体系:模块拆分¶
对系统进行模块化拆分，拆分有两种方式：水平拆分和垂直拆分。¶
一般做业务架构时，我们先考虑垂直拆分，从大方向上，把不同业务给区分清楚，然后再针对具体业务，按照业务处理流程进行水平拆分。
打造可扩展的模块体系:模块整合¶
备注
整合也有两种好的手段：通用化和平台化。
通用化整合¶
通用化指的是通过抽象设计，让一个模块具备通用的能力，能够替代多个类似功能的模块。
通过模块通用化，模块的数量减少了，模块的定位更清晰，概念更完整，职责更聚焦。在实践中，当不同业务线对某个功能需求比较类似时，我们经常会使用这个手段。
平台化整合¶
平台化是把定位相同的模块组织在一起，以组团的方式对外提供服务。对于外部系统来说，我们可以把这些模块看成是一个整体，一起对业务场景提供全面的支撑。
业务平台化是模块依赖关系层次化的一个特例，只是它偏向于基础能力，在实践中，当业务线很多，业务规则很复杂时，我们经常把底层业务能力抽取出来，进行平台化处理。
把这些基础模块放在同一层，构成一个基础业务平台。之前，它们是一个个离散的服务，独立地输出能力，现在变成一个大的业务平台，可以提供整体的能力输出。¶
04 | 可扩展架构案例1¶
国内电商平台架构发展的大致过程¶
单体架构¶
单体架构中的模块只是在逻辑上独立，并没有在物理上严格分开，导致系统在落地时，模块的职责和边界划分比较随意，相应地，模块之间的依赖关系也比较模糊。所以，在单体架构中，模块结构是否合理，很大程度上依赖于开发者的个人水平。¶
分布式架构¶
系统由多个独立的应用组成，它们互相协作，成为一个整体。¶
【优点】分布式架构在单体应用的基础上，进一步对系统按照业务线，进行了业务广度上的切分（所谓业务广度，指的是不同业务线的数量），这样就把一个大系统的业务复杂度，分割成多个小业务的复杂度，从而降低了整体的复杂度。通过拆分后，各个应用之间的耦合度低，就可以很好地支持多团队的并行开发。
【缺点】作为应用的开发者，除了要满足自身业务的需求之外，同时还需要考虑外部业务的需求，这两部分经常会打架。比如，由于自身业务的需求，引起底层的业务逻辑修改，这时会同时影响 API 接口功能，导致其他业务受影响；同样的道理，外部业务需求过来，需要 API 接口做调整，即使不影响底层业务逻辑，也会导致整个应用重新部署，影响自身业务的稳定性。另外，在分布式架构下，每个应用都是从头到尾，自搭一套完整的体系，导致业务之间重复造轮子，造成资源浪费。举个例子，在 2008 年，淘宝还没有开始服务化改造之前，不同业务线的用户、商品、订单逻辑非常类似，导致了整个系统有超过 1/3 的核心代码重复。
备注
分布式架构适用于业务相关性低、耦合少的业务系统。举个例子，企业内部的管理系统，分别服务于不同的职能部门，比如财务系统和 HR 系统，就比较适合按照分布式架构去落地。
SOA 架构¶
两个阶段:
1. 传统的 SOA 架构，它解决的是企业内部大量异构系统集成的问题
2. 新的 SOA 架构，它解决的是系统重复建设的问题
传统的 SOA 架构¶
新的 SOA 架构¶
相对于分布式架构，SOA 架构给系统的扩展带来了一系列的好处:
1. 首先，它通过服务化思想，提供更好的业务封装性，并通过标准技术，能更友好地对外输出业务能力；
2. 其次，SOA 服务不依附于某个具体应用，它可以独立地部署和扩展，这样避免了直接影响现有的系统；
3. 最后，服务通过封装通用的业务逻辑，可以供所有应用共享，解决了重复造轮子的问题。
【缺点】在系统实现上比较重，落地比较困难。
微服务架构¶
【区别-分布式服务】微服务围绕更小的业务单元构建独立的应用。
【相同-SOA】强调围绕业务，进行清晰的业务和数据边界划分，并通过良好定义的接口输出业务能力
【区别-SOA】微服务是去中心化的，不需要 SOA 架构中 ESB 的集中管理方式:
一方面，微服务强调所谓的哑管道，即客户端可以通过 HTTP 等简单的技术手段，访问微服务，避免重的通信协议和数据编码支持。 一方面，微服务强调智能终端，所有的业务逻辑包含在微服务内部，不需要额外的中间层提供业务规则处理。
各种类型的微服务:
1. 封装底层基础业务的是共享微服务
2. 封装流程的是聚合微服务
3. 封装具体业务场景的服务端是应用微服务
4. 封装基础中间件（如 Redis 缓存、消息推送）的是系统微服务
一个有序的层次化微服务体系大致样子¶
05 | 可扩展架构案例2¶
V1.0 架构¶
V2.0 架构¶
V3.0 架构¶
06 | 可扩展架构案例3¶
中台的定位¶
从 “川” 字型转为 “山” 字形¶
典型的业务中台的结构，一般包含三层：从上到下分别是通用聚合服务层、通用基础业务平台和通用中间件平台。¶
07 | 可复用架构¶
复用，它可以让我们站在巨人的肩膀上，基于现有的成果，快速落地一个新系统。
复用的分类¶
复用有多种形式:
1. 技术复用: 包括代码复用和技术组件复用
2. 业务复用: 包括业务实体复用、业务流程复用和产品复用
从复用的程度来看，从高到低，我们可以依次划分为产品复用 > 业务流程复用 > 业务实体复用 > 组件复用 > 代码复用。¶
技术复用¶
代码级复用和技术组件复用都属于工具层面，它们的好处是在很多地方都可以用，但和业务场景隔得有点远，不直接对应业务功能，因此复用的价值相对比较低。
业务复用¶
业务实体复用针对细分的业务领域
业务流程的复用针对的是业务场景
最高层次的复用是对整个系统的复用:
一个 SaaS 系统，它在内部做了各种通用化设计，允许我们通过各种参数配置，得到我们想要的功能 一个 PaaS 平台，它会提供可编程的插件化支持，允许我们 “嵌入” 外部代码，实现想要的功能。
备注
从技术复用到业务复用，越往上，复用程度越高，复用产生的价值也越大，但实现起来也越复杂，它能复用的场景就越有限。
基础服务边界划分¶
基础服务边界划分的原则:
1. 首先，是服务的完整性原则
2. 其次，是服务的一致性原则
3. 最后一个，是正交原则
08 | 可复用架构案例1¶
一个可高度复用的共享服务最核心的两点:
清晰的边界划分
内部的抽象设计
09 | 可复用架构案例2:如何对现有系统做微服务改造¶
一共分为两个阶段：准备阶段，实施阶段¶
准备阶段¶
圈表:
目的: 确定库存微服务具体包含哪些表，也就是确定服务的数据模型，划分服务边界 从数据库表的角度来考虑划分，是为了更好落地
收集 SQL:
收集所有业务系统访问这些表的 SQL 语句，包括它的业务场景说明、访问频率等等。 库存微服务后续就针对这些 SQL 进行封装，提供相应的接口给业务系统使用。 服务开发团队负责提供 SQL 收集的 Excel 模板，各业务系统开发团队负责收集具体的 SQL。
拆分 SQL:
对于收集过来的 SQL 语句，有些 SQL 不仅仅访问圈定的这几张库存表，还会和其他库中的表进行关联。 要求各个业务团队先进行拆分，保证最后提供给服务开发团队的 SQL，只包含访问库存的相关表。 通过 SQL 拆分，我们切断了库存表和其他表的直接联系，等后面微服务落地后，业务系统就可以通过接入微服务，完成现有 SQL 的替换。 SQL 拆分，会涉及一定的业务系统改造，这部分工作主要由各个研发团队负责，一般情况下，性能可能会受些影响，但问题不是很大。
实施阶段¶
构建库存微服务:
包括了接口设计、代码开发、功能测试等 服务开发团队会对业务方提供的 SQL 进行梳理，然后对接口做一定的通用化设计，避免为每个 SQL 定制一个单独的接口，以此保证服务的复用能力。 这部分工作由微服务开发团队负责，第一版的服务主要是做好接口设计，聚焦业务功能，以保证服务能够落地，业务系统能够顺利对接为目标。 将来，服务可以持续迭代，内部做各种技术性优化，只要服务的接口保持不变，就不会影响业务系统。
接入库存微服务:
库存服务经过功能和性能验证以后，会由各个业务开发团队逐步接入，替换原来的 SQL 语句 这部分工作主要由业务研发团队负责，难度不大，但需要耗费比较多的时间
数据库独立:
这部分工作主要由微服务开发团队和 DBA 一起配合完成，主要是要避免业务系统还有遗漏的 SQL 语句，避免它们还在直接访问库存的表。 在迁库前，通过代码扫描做好相应的检查工作。
微服务改造小结¶
整个改造大概持续了 3 个月，主要是对接的工作比较耗时。
除了做好库存服务本身的设计开发工作，相关团队之间的配合也是非常重要的。
系统改造不会产生直接的业务价值，对于业务开发团队来说，他们往往还需要承担大量新需求的开发工作。所以，从项目推进的角度来看，这种核心服务的改造，很多时候都是技术一把手工程。
1 号店的总体系统架构图¶
总结¶
基于现有系统进行改造和全新的服务设计是有所不同的，我们不能追求理想化和一步到位，而是要考虑到系统的平滑过渡，先实现微服务的顺利落地，后续再考虑各种优化。
10 | 可复用架构案例3:中台¶
中台架构¶
03技术架构篇 (9 讲)¶
11 | 技术架构¶
系统的物理模型¶
简化的系统物理模型¶
技术架构的挑战¶
硬件的问题:
1. 硬件的处理能力有限
Scale Up: 纵向扩展，垂直扩展
Scale Out: 横向扩展，水平扩展
2. 硬件不是 100% 的可靠，它本身也会出问题
做技术架构设计时，就要充分考虑各种硬件故障的可能性，做好应对方案。
比如说针对自然灾害，系统做异地多机房部署。
软件的问题:
1. 弥补了硬件的缺陷
2. 封装让我们可以更高效地访问系统资源
带来新的问题：一致性、可用性和网络分区
CAP 理论
技术架构的目标¶
系统的高可用:
一种是软硬件本身有故障，比如机器断电，网络不通。
这要求我们:
要么及时解决当前节点的故障问题，
要么做故障转移，让备份系统快速顶上。
一种是高并发引起的系统处理能力的不足，软硬件系统经常在处理能力不足时，直接瘫痪掉，
比如 CPU 100% 的时候，整个系统完全不工作。
这要求我们:
要么提升处理能力，比如采取水平扩展、缓存等措施；
要么把流量控制在系统能处理的水平，比如采取限流、降级等措施。
系统的高性能:
分两种情况：
1. 常规的流量
主要是优化每个接口的响应时间
2. 高并发的流量
主要保证系统的处理能力能够整体上做水平扩展
系统的可伸缩和低成本:
高可用、高性能、可伸缩和低成本，这些技术架构的目标不是孤立的，相互之间有关联
评论¶
大的技术体系改造:
1. 引入新的微服务框架：一般从不重要的业务开始，达到验证效果就可以。
2. 突出点的技术类改造：一般直接做在核心模块上，要能产生大的业务价值。
12 | 高可用架构¶
系统宕机对公司的影响:
2010年eBay:
系统每宕掉 1 秒: 损失三千美金
系统每宕掉 1 分钟: 损失3000*60=18万美金
系统每宕掉 1 小时: 损失3000*3600=1080万美金
系统有哪些故障点¶
故障点可以归纳为三类:
1. 资源不可用，包括网络和服务器出故障
网络出故障表明节点连接不上，
服务器出故障表明该节点本身不能正常工作。
2. 资源不足
常规的流量进来，节点能正常工作
高并发的情况下，节点无法正常工作，对外表现为响应超时。
3. 节点的功能有问题，这个主要体现在我们开发的代码上，比如
它的内部业务逻辑有问题，或者是接口不兼容导致客户端调用出了问题；
另外有些不够成熟的中间件，有时也会有功能性问题。
高可用策略和架构原则¶
高可用的总体解决思路¶
备注
处理线上事故的首要原则是先尽快恢复业务，而不是先定位系统的问题，再通过解决问题来恢复系统。
在做架构设计时，就可以从 正面保障 和 减少损失 两个角度来考虑具体的应对手段。¶
备注
处理事故三板斧：重启、回滚、加机器
13 | 高可用架构案例: 实现日订单 500 万¶
点餐平台的具体架构¶
高可用架构具体的改造点¶
14 | 高可用架构案例-可观测性¶
监控的分类¶
用户体验监控：指的是从前端用户的访问速度出发，来监测系统的可用性，包括页面能否打开、关键接口的响应时间等等，用户体验监控一般结合前端的埋点来实现。
业务监控：它是从业务结果的角度来看，比如说订单数、交易金额等等，业务监控也是最直观的，我们知道，如果业务数据没问题，系统整体也就没有问题。对于业务监控，我们一般是从数据库里定时拉取业务数据，然后以曲线的方式展示业务指标随着时间的变化过程。除了当前的曲线，一般还有同比和环比曲线。同比是和前一天的数据进行比较，环比是和一周前的数据进行比较，两方面结合起来，我们就能知道当前的业务指标有没有问题。
应用监控：指的是对自己开发的代码进行监控，比如接口在一段时间内的调用次数、响应时间、出错次数等等。更深入一点的应用监控还包含了调用链监控，我们知道，一个外部请求的处理过程包含了很多环节，比如说网关、应用、服务、缓存和数据库，我们可以通过调用链监控把这些环节串起来，当系统有问题时，我们可以一步步地排查。有很多 APM 工具可以实现调用链监控，如 CAT、SkyWalking 等等。
中间件监控：指的是对标准中间件进行监控，它是第三方开发的代码，比如数据库、缓存、Tomcat 等等，这些组件对应的是系统的 PaaS 层。这些中间件往往带有配套的监控系统，比如，RabbitMQ 就有自带的监控后台。
基础平台监控：指的是对系统底层资源进行监控，如操作系统、硬件设备等等，这个层次的监控对应的是系统的 IaaS 层。Zabbix 就是典型的基础设施监控工具，它可以监控 CPU、内存和磁盘的使用情况。
监控的痛点¶
解决思路¶
1. 首先要实时
2. 然后要直观
3. 最后是整体
架构方案和效果¶
监控系统的整体架构¶
实际监控效果图¶
15 | 高可用架构案例: 打造一体化的监控系统¶
监控系统主要分为 4 大部分:
1. 节点信息采集
2. 节点接入监控系统
3. 数据上报
4. 前端展示
16 | 高性能和可伸缩架构¶
系统性能的基线¶
高性能的策略和手段¶
加快单个请求处理:
a. 优化处理路径上每个节点的处理速度: 降低算法的时间和空间复杂度 通过索引，来优化数据库查询 通过缓存来代替数据库访问 b. 并行处理单个请求 MapReduce 思想同时处理多个请求:
多个节点来处理请求 多进程、多线程技术
请求处理异步化:
通过消息系统对流量进行削峰，系统先把请求存起来，然后再在后台慢慢处理。
可伸缩的策略和手段¶
系统的可伸缩有两种实现方式:
第一个是节点级别的可伸缩
第二个是系统级别的可伸缩
如果能实现系统端到端的伸缩，同时对多个节点进行伸缩处理，那系统的可伸缩能力就更高了。可以把多个处理节点打包在一起，形成一个处理单元。
高性能和可伸缩架构原则¶
可水平拆分和无状态
短事务和柔性事务
数据可缓存
计算可并行
可异步处理
虚拟化和容器化
17 | 高性能架构案例: 秒杀系统¶
秒杀系统主要使用了异步化处理的方式
18 | 可伸缩架构案例: 数据库扩展¶
水平分库是一项系统性工作，需要大胆设计，谨慎实施。你需要把握住这几个要点:
1. 首先，你需要在分库策略的指导下，结合实际情况，在每个方面做出最合适的选择；
2. 其次，对于特殊场景，如分页查询，你需要具体问题具体解决；
实时性要求不高的可以走大数据或 ES
实时性要求高的还是要并行直接查数据库
3. 最后，你要总体规划，控制好落地步骤，包括对系统改造、性能测试、数据迁移、上线实施等各个环节做好衔接，保证业务不出问题。
ID 取模进行分库，分库的数量是按照倍数增加的:
比如说，一开始是 4 个库，二次分裂为 8 个，再分成 16 个。
这样对于某个库的数据，在分裂的时候，一半数据会移到新库，剩余的可以不用动。
如果要扩充数据库的数量，从 6 个升到 12 个，我们可以分三步走:
1. 增加 6 个 MySQL 实例，把现有 6 个库的数据同步到新的库，比如说，0 号库同步到 6 号库，1 号库同步到 7 号库等等；
2. 在配置文件里把分库的取模从 6 变成 12；
3. 通过数据库脚本，每个库删掉一半数据，比如对于 0 号库，删掉用户 ID%12=6 的记录，对于 6 号库，删掉用户 ID%12=0 的记录。
19 | 综合案例: 电商平台技术架构演变¶
单体系统¶
SOA 架构¶
【优点】减少了代码冲突，系统的开发也变得更加高效，部署，也更容易针对各个系统的处理能力进行水平扩展。【缺点】内部服务通过中心化的负载均衡进行访问，中心化的负载均衡增加了服务的调用时间。此外，在电商场景下，内部的服务很多，服务调用的频率很高，每秒可能有上百万次，导致了负载均衡的连接能力不够。¶
服务调用去中心化¶
【优点】解决内部服务路由中心化的问题，还可以实现完善的服务治理，包括服务隔离、熔断、降级¶
垂直分库¶
【优点】解决单个数据库（比如 Oracle）的性能和储存容量无法满足需求¶
水平分库及高可用部署¶
【优点】主要解决：1. 单个数据库的可用性问题；2. 单个数据库的性能和容量问题¶
针对单个数据库的可用性问题，我们可以采用 MHA 高可用（Master High Availability）方式部署。比如数据库部署一主多从，通过 MHA 机制，我们可以实时检测主库的可用性，如果主库有问题，系统会自动 Failover（故障转移）到最新的从库。另一方面，我们还可以利用多个从库支持读写分离，减轻主库的访问压力。
针对单个数据库的性能和容量问题，首先我们可以引入缓存，在高读写比的场景下，让应用先访问缓存，大大减轻对底层数据库的压力。然后，我们可以对数据库按照某个维度（比如用户维度），进行水平拆分，把数据记录分布到多个实例中，最终分散主库的写压力以及数据存储的瓶颈（在上一讲中，我已经具体介绍过了，你可以点击链接去回顾内容）。
多机房部署¶
解决单个机房的服务器不够用¶
服务调用本地化¶
让每个机房的服务注册到同机房的注册中心。这样，客户端的服务调用会路由到同机房的服务端，实现了服务调用的本地化，大大降低了跨机房通信带来的延时和不可用性问题。¶
依赖分级管理¶
对于外部服务依赖的可用性问题，我们的解决办法是，针对这些外部依赖进行分级管理，根据依赖功能的重要性不同，把它们分为强依赖和弱依赖。¶
对于强依赖，我们实时同步调用，比如在用户下单时调用库存服务，由于库存非常重要，必须实时扣减，如果调用库存服务失败，下单也失败。
对于大量的弱依赖，我们以异步消息的方式进行信息同步，比如对于积分服务，可以通过柔性事务来保证数据的最终一致性，这样大大提升了核心系统的性能和可用性。
多机房独立部署¶
解决：1. 跨机房数据库访问的性能问题，2. 老机房整体故障带来的可用性问题。比如说，机房断电，通信光纤有问题或者发生自然灾害，导致老机房整体不可用。解决方案是，我们在多个机房做对等的部署，这样每个机房的系统可以形成内部闭环，¶
备注
机房间需要进行数据同步，可以是 A 地的主库包括部分数据（比如奇数用户 ID 的订单），同步给 B 地的从库，B 地也有主库（偶数用户 ID 的订单），同步给 A 地的从库，这样 A/B 地都有完整数据。如果 AB 物理挨得近，可以是裸光纤数据库同步的方式，远的话可以使用其他中间件同步。
总结篇 (2 讲)¶
20 | 架构设计的重点知识和学习路径¶
架构原则汇总¶
不同的原则对应着不同的目标¶
架构落地过程¶
首先，架构师要和产品经理或者业务人员沟通，了解业务；和开发人员沟通，了解系统。
- 了解完系统和业务后，架构师接下来就要设计具体的方案，方案设计要分三步走：
首先，架构师针对业务需求，分解相应功能到现有的各个系统，把系统的各个部分串起来，这个第一版的方案至少要能够在表面上解决当前的问题，这样就形成一个草根的方案。
然后，架构师要进一步深入思考业务的本质，对现有的草根方案进行升华，比如说，通过抽象，让方案更加通用，可以解决多个类似的或潜在的业务需求，这样，草根的方案就变成了一个高大上的方案，这里很考验架构师的透过问题看本质和抽象总结的能力，
接下来，基于现有的各项约束，比如时间、资金和人员技术能力等因素，架构师要对方案进行简化，把高大上的方案变成一个接地气的方案，以最小的代价实现最大的价值，这里很考验架构师的平衡取舍能力。
方案设计好之后，最后还要进行宣讲，架构师需要说服相关的人员接受方案，并且在后续的方案执行中，负责跟踪架构的落地，如果过程中有疑难问题，架构师还要协助解决。
架构师知识结构¶
- 首先，作为架构师，我们需要了解计算机硬件和操作系统的相关知识，如果对它们有深入的了解，我们就能知道系统底层是怎么执行的，在做具体设计的时候，我们也就可以做各种优化。比如说，在设计 RPC 通讯框架时，我们可以通过 IO 多路复用和内存零拷贝技术，来提升服务端并发处理请求的能力。之后就是具体技术相关的内容，从浅到深可以分为三个部分：
第一部分是开发相关的基本知识，比如数据结构和算法、具体的开发语言、常用的设计模式以及开发框架等等，这样你就具备了基本的开发能力。
第二部分是各种中间件知识，常用的中间件包括数据库、缓存、消息系统、微服务框架等等，对于这些核心中间件，我们不但要了解具体的用法，还要深入理解它们的适用场景。这样你就能写出高效健壮的代码，能够独立承担一个子系统的开发。
继续往下深入，你还要学习分布式系统相关的知识，包括底层网络和分布式通信技术，这样你就可以了解系统是怎么连接在一起的。除此之外，你还要了解一些周边的系统，比如大数据平台、运维监控系统、接入系统等等，这样，你就可以了解系统端到端的运行过程，从技术架构上保证系统的稳定可用。
之后，就可以往全面的架构师发展了。比如说，你可以结合业务，来设计应用体系，包括数据模型和服务设计；你可以了解各种应用架构模型，知道它们的优缺点和适用场景，能够定义一个良好的应用依赖关系。
再往上，就是成为业务领域专家。在这个阶段，你已经知道如何通过业务拆分，实现业务之间的解耦；如何通过业务抽象，实现业务的扩展和重用。
到最后，你已经对各种架构设计的目标和架构原则都非常了解了，知道面对一个具体的问题，大致都有哪些解决的手段；然后，经过大量的实践，你能够把技术架构、应用架构、业务架构融会贯通，并针对具体情况，对架构的各个目标做良好的平衡。当然，作为架构师，你还要和一系列的人员打交道，这时候就需要你培养更多的软技能，能把复杂的架构问题以简单的方式表达出来。
架构师成长路径¶
caption¶
结束语¶
业务架构聚焦人脑如何理解业务，针对的是业务性功能；技术架构聚焦电脑具体如何干活，针对的是系统性功能，这两者的目标以及处理手段都是不同的