飞天班第1节：走近架构

0、邓宁-克鲁格效应

我们要警惕自己要不断的学习

邓宁-克鲁格效应指的是能力欠缺的人在自己欠考虑的决定基础上得出错误结论，但是无法正确认识到自身的不足，辨别错误行为，是一种认知偏差现象。

这些能力欠缺者沉侵在自我营造的虚幻优势之中，常常高估自己的能力水平，却无法客观的评价他人的能力。

邓宁-克鲁格效应有几种现象：

能力越差的人越容易高估自己
能力越差的人发现不了自己和别人的差距
人类有虚幻的优越感，总觉得自己比别人棒。

邓宁-克鲁格效应归纳为：如果你没有能力，你就不会知道自己没有能力

简言之即庸人容易因欠缺自知之明而自我膨胀

1、系统架构师

定义

简单的说，系统架构师是一个技术人员，中间有很多修饰词，百度百科：

系统架构师是一个最终确认和评估系统需求，给出开发规范，搭建系统实现的核心架构，并澄清技术细节，扫清主要难点的技术人员。
主要着眼于系统的“技术实现”，因此他说特点的开发平台、语言、工具的大师，对常见应用场景能给出最恰当的解决方案，同时要对所属的开发团队有足够的了解，能够评估自己的团队实现特定的功能需求需要的代价。
他负责设计系统整体架构，从需求到设计的每个细节都要考虑，把握整个项目，设计的项目尽量效率高、开发容易、维护方便、升级简单。

你要提高，首先要把自己的认知提高到这样的一个高度：架构师

Java架构师是一个整体技术能力的体现，并不是一个具体的技术岗位，首先要有一个架构思维模式的学习。

责任

架构的使命和责任：透过现象看本质，你要能明白和提示你在公司的价值

1) 兼容过去问题

历史数据和业务的兼容，老系统过度，项目升级，要保留老系统的用户数据能正常使用，即老系统和新系统并行使用，难度最大。项目升级一般有下面三种方式

空中加油

难度最大，新老系统并行使用，灰度发布（又名金丝雀发布），指黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继续使用产品特性A，一部分用户开始用产品特性B。如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。

灰度发布可以保证整体系统的稳定。

灰度期：灰度发布开始到结束期间的这段时间，称为灰度期。
新旧分割

老用户用老系统，新用户用新系统，数据互相隔离，待新系统完全稳定后可以对老系统用户做后端迁移，常用于App版本共存阶段或者经常一些网站可以在新旧版本之间来回切换。
休克疗法

一刀切，制定好停机时间，老系统关闭，历史数据迁移，新系统开启使用，升级失败会处于两难的境地。就像我们常常看到的网站升级中，就是休克疗法的体现

思考：公司的项目中，有哪些问题

2) 解决当前问题

新需求和业务功能的扩展，尽量避免老去维护当前的业务（填坑），因为那样没有发展

日常维护成本低
可扩展性强：避免出现增加一个小功能就进行大动干戈的整体回归测试
系统稳定、故障率低：SLA至少在四个9，服务停机时间不能超过5分钟以上

重构：为了未来做准备

3) 适度解决未来问题

充分分析：时间成本、人力成本、机会成本

建立中台，就是为了降低维护系统业务的时间成本，服务可重用
未来2-3年用户规模的扩大程度。50W->500W的日活量规划
未来2-3年现有用户的自我成长和进化方向
未来2-3年技术栈的更新迭代
竞争对手商业竞争的残酷性（提高自己的能力）
研发团队的自身因素（团队稳定、结构、成本）

明白我们在一家企业的使命和责任后，接下来just do it

如何反思自己，让自己得到提升。

能力

架构师需要具备业务抽象分析、架构设计、架构选型、容量规划、代码落地、架构治理等能力。这些能力中，最核心的能力是架构设计和架构选型

1）架构设计分为服务架构设计和存储架构设计

服务架构设计是选用微服务架构还是云原生架构？
存储架构设计是选择RDBMS数据库、NoSQL数据库、还是NewSQL数据库？

2）架构选型分为服务架构选型和存储架构选型

微服务架构设计的选型可以选用Spring Cloud生态或者Apache Dubbo生态。
存储架构的选型，业务数据量不大的情况下，MySQL数据库是很好的选择。如果业务量比较大，想简化业务操作，MongoDB或者TiDB是比较好的选择。

回归公司业务现实，绝大多数业务场景的数据量都不会超过5000万行，那么MySQL数据库能够优雅地满足业务场景。同时通过合理的分库分表架构设计，MySQL也能支持千亿级数据。

2、架构设计的目标

架构师都是野生的，一定要有自己的实战经验

系统架构不是无目的性的设计和规划，一定是基于业务本身去做设计和分析。
系统架构是随着业务的发展逐步优化和成长起来的，但在前期设计的时候需要给后期预留工作，这就需要对系统架构的相关设计理论和原则进行掌握和学习。

4个目标：

1）高可用性

N+1原则，集群保持服务可用。

SLA服务级别协议是指提供服务的企业与客户之间就服务的品质、水准、性能等方面所达成的双方契约。

全年SLA99.99% = 365*24=8760个小时*0.0001=0.8760*60=52.6分钟，换句话说整个系统全年宕机不超过50分钟。

2）高可扩展性

架构简单清晰（能够将公司的架构图画出来），应用系统间耦合度低，容易水平扩展。

OOP 面向接口编程就是为了解耦

3）低成本

提高服务重用性（中台系统），降低人力成本，减少服务器成本。

4）多快好省

构建平台捡骨效率和性能，以高时效低成本为目标。竞争是在任何地方都存在的，要提升自己的眼界

## 3、架构质量要求

质量要求贯穿整个系统架构的各个方面

设计原则

我们在架构设计的过程中需要走的弯路一步都不能少，但我至少知道自己正在走弯路，知道自己该如何快速的走出这些弯路

系统架构过程中有很多实践得出的设计原则，帮助我们在架构设计中提前规避问题，协助我们更好的实现系统架构目标，对于一个初涉系统架构设计的研发人员具有很好的指导意义。

明白了原则所阐述的标准和法则后就能在设计架构的时候尽量少走弯路。

技术层面上从可用性、可扩展性、成本3个维度，如下图：

从图中可以看出，三个圈的交集就是核心：

不过度设计
松耦合
抽象化
服务可重用
可水平扩展

1、单一责任原则

设计模式的基本思想，一个接口、方法、类，都应该只承担一个任务或责任，而不是完成多个任务功能，这样复杂度降低后便于功能维护、风险控制、变更管理。

对于一个系统功能模块或服务也是一样，如果功能复杂，系统耦合度很高，就不便于后续继续进行分布式扩展，功能模块互相影响也会导致业务节点崩溃。

2、DID原则

Design 设计20倍容量，Implement 实施3倍容量，Deploy 部署1.5倍容量

在未来2到3年时间你设计的系统架构在不进行系统化重构的情况下可以通过设备或节点扩展正常支撑业务发展。

3、N+1原则

任何业务服务节点不要少于两个可独立运行设备

4、版本可回退

git管理，线上版本发布后出现问题，可以回退上一次正常的业务状态。

5、功能可开关

系统的一些功能入口可以进行关闭并做出友好提示

eg：双11当天，无法查询个人历史订单和商品物流信息等

6、系统容错

一个系统总是或多或少出现一些未知的系统问题，但对于用户不要将类似404、505、502等错误展示在前端，应该跳转至友好提示页面（如提示服务开小差了等），并能从该页面继续进行业务操作。

7、服务可重用

系统服务化（服务中台）

8、服务可水平扩展

水平扩展实现服务化集群化以及水平服务能力随时增加，2年之内，用户增长，可以通过扩展服务器来解决服务问题

9、松耦合、抽象化

开发层面的抽象化（接口式编程）

系统架构层面的松耦合就是模块之间的服务调用，而不是将模块功能内嵌。

现在微服务架构就很好的实现了这个原则。

10、不过度设计

开源节流，一个系统的技术架构不要为未来5年甚至10年来买单，架构设计3-5年就够了

例如设计一款家用空调，室外可以达到热力学温度0K，在室内可以达到300F，这是在浪费资源且毫无必要。-20~30度，过度设计有过度使用资源的情况，包括为研发和实施硬件，软件解决方案付出的较高费用。如果因为过度设计造成系统的研发周度过长，影响公司产品的发布计划。

11、使用成熟的技术

不是吃螃蟹的第一人，没有太多技术坑，有问题也能很快的找到解决方案
学习资料充足，应用成本低
市场上有技术人员保有量高，人好招

12、采用同质化硬件或云服务

现在企业很少自建IDC机房，基本都上云了，整个系统的云服务采用同一家服务商，可以避免网络消耗，出现问题也好统一服务解决，避免跨服务商出现不可知的问题。

13、减少域名解析

内容：从用户角度减少域名解析次数场景：对性能敏感的所有网页用法：尽量减少下载页面所需的域名解析次数，但要保持与浏览器的并发连接平衡；原因：域名解析耗时而且大量解析会影响用户体验

14、三次简化方案

“问三个如何”：如何简化方案范围；如何简化方案设计；如果简化方案实施；

如何简化方案范围：（确定系统边界）对这个简化问题的答案是不断的应用帕[pa]累托原则（也叫80-20原则）。收益的80%来自于20%的工作？对此，直接的问题是“你收入的80%是由哪些20%的功能实现的”，做得很少（工作的20%）同时取得显著的效益（价值的80%），解放团队去做其他的工作。如果删除产品中不必要的功能，那么可以做五倍的工作，而且产品并没有那么复杂！减少五分之四的功能，毫无疑问，系统将会减少功能之间的依赖关系，因而可以更高效率和更高本益比地进行扩展。此外释放出的80%的时间可用于推出新产品，以及投资思考未来产品可扩展性的需求。
如何简化方案设计：简化设计与过度设计的复杂性密切相关；简化设计的步骤要求以易于理解，低成本，高效益和可扩展的方式来完成工作。
如何简化方案实施：如何利用其它经验和已经存在的解决方案来简化方案实施？

a. 首先寻找被广泛采用的开源或第三方解决方案来满足需求； b. 其次看看在组织内是否有人准备了可扩展方案； c. 再次看看外部是否有人已经描述了一种可以合法复制或模仿的可扩展方案；

只有这三项都无合适的情况下，我们才会开始尝试自己创建解决方案。

15、学习方法

费曼学习法：通过你的讲述，能让别人理解到他不知道的知识点，这才说明你真正理解和消化这个知识点了。

也就是说你懂了并能教懂别人，才是真正的学会了。

4、架构设计组成的4个层级

系统架构不仅仅是技术层面的设计

首先要从业务角度出发，先完成业务层级的架构
根据业务层级需要对技术和数据层进行设计

架构主要分为4个层级间，关系如下图：

从以下6个方面体现架构设计

下面以电商业务为切入点，带领大家按照业务层级关系进行对应的架构设计

业务架构的设计方法与实现

1、设计原则

分清楚主次，可描述，可见的。分清重要-紧急的事情

2、设计实例

任何一个企业它一定是按照业务来发展，业务架构图

应用架构的设计方法与实现

1、设计原则

2、分析设计过程

应用分层

保证数据架构层是没有问题的，数据查询是正常的，避免慢SQL
分解设计原则

前台（app、小程序、pc）+ 后台(pc admin管理) + 数据库

并发量高的系统，应该独立部署
依赖设计原则
服务设计原则

应用架构的时候，大家更多的是思考自己的当前公司的状态

应用架构设计实例：基于交易订单部分

最终可以梳理出整个应用架构的依赖关系图

数据架构的设计方法与实现

在架构中，没有什么是加一层解决不了的

现在，一家公司能掌握的数据越多，公司的地位就越高，数据是很值钱的。

1、设计原则（数据库的高可用，数据安全）

2、典型的数据架构应用

3、典型的大数据平台架构应用

大数据 = 存储 + 计算

更多人目前，还在基础业务中，对于数据库的理解会相对较少。

数据 -》画像分析，如果没有好的数据架构是无法实现的。

技术架构的设计原则

开发人员必须要会的

1、系统运行时原则

如果这些原则不满足，则不能满足大流量和高并发。

主要有6个原则，如下图：

可监控：hystrix 、sentinal等技术框架，druid 数据库连接池的sql监控
在线扩容：k8s

2、系统部署原则

作为技术开发人员，主要了解N+1原则、DID原则、支持灰度发布

3、设计实例

5、大流量应对方案

系统准备阶段

通过下面6个维度去应对大流量问题：

大流量高并发应对措施：

6、架构设计总结

就是围绕我们上面说的4个核心层级和6个维度去做架构设计

业务架构+应用架构+数据架构+技术架构

解耦、拆分、抽象、集成、复用、治理

把平凡的事情做得不平凡了，那就是成功。

知识点思维导图：

参考系统架构图

7、其它设计原则

除了上面讲到的单一责任、DID原则、N+1原则，还有以下原则理论：

康威定律

任何组织在设计一套系统（广义概念上的系统）时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。
帕累托（Pareto）原则

也叫80-20原则，二八定律，如收益的80%来自于20%的工作。

二八定律是19世纪末20世纪初意大利经济学家帕累托发现，社会上20%的人占有80%的社会财富，即：财富在人口中的分配是不平衡的。

站在系统设计的角度看，简化系统边界，优先实现带来80%财富的20%功能，你收入的80%是由哪些20%的功能实现的，把他们找出来，简化系统