1.系统架构思维

系统架构

1.什么是系统架构？

百度百科给出的解释：

1.1系统架构的使命和责任

一.兼容过去问题：历史数据和业务的兼容，老系统过度

1、 空中加油：难度最大、历史数据兼容复杂、业务分支多、发布过程中的灰度要非常短， 切换速度再快也要防止脏数据的产生

2、 新旧分割：老用户用老系统，新用户用新系统，数据互相隔离，待新系统完全稳定后可以对老系统用户做后端迁移，常用于APP版本共存阶段

3、 休克疗法：一刀切，制定好停机时间，老系统关闭，历史数据迁移，新系统开启使用，升级失败会处于两难的境地，多用于垄断性APP或强大的甲方

二.解决当前问题：新需求的和业务功能的扩展

1、 投入产出比高：需求估时中，对系统流程和架构的了解时间比例要低于20%

2、 日常维护成本低：系统功能性问题不影响业务需求的发展

3、 可扩展性强：避免出现增加一个小功能就进行大动干戈的整体回归测试

4、 系统稳定、故障率低：SLA至少在四个9，服务停机时间不能超过5分钟以上

三.适度解决未来问题：don’t over design

1、 时间成本、人力成本、机会成本

2、 未来2-3年用户规模的扩大程度

3、 未来2-3年现有用户的自我成长和进化方向

4、 竞争对手商业竞争的残酷性

5、 未来2-3年技术栈的更新迭代

6、 研发团队的自身因素（团队稳定、结构、成本）

1.2明确架构的使命和责任后接下来：Just do it

1.2.1制定架构设计的目标

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

1、高可用性：系统整体可用性SLA至少99.99%，整个系统全年不超过50分钟，单个系统故障不超过5分钟；

SLA 99.99% 的计算方式 99.99% = 8760 *0.0001 = 0.876小时 = 0.876 * 60 = 52.6分钟

2、高可扩展性：架构简单清晰，应用系统间耦合低，容易水平扩展；

3、低成本：提高服务重用性，降低人力成本，减少服务器成本；

4、多快好省：构建平台兼顾效率和性能，以高时效低成本为目标。

1.2.2制定架构质量要求

一个好的架构要考虑各种影响因素，架构的质量要求是衡量架构的一个立体因素，贯穿了系统架构的各个方面

1.2.3掌握系统架构设计的方法论和原则

1、 单一责任原则：

一个接口、方法、类，都应该只承担一个任务或责任， 而不是完成多个任务功能，这样复杂度降低后便于功能维护、风险控制、变更管理等，而对于一个系统功能模块或服务也是一样，如果功能复杂，系统耦合度很高就不便于后续进行分布式 扩展，功能模块互相影响也会导致业务节点崩（业务系统和数据库放在同一台设备上就是严重违背单一责任的架构方式，这也就是俗称单一应用架构）

2、 DID原则：

Design(D)设计20倍的容量；
Implement(I)实施3倍的容量；
Deploy（D）部署1.5倍的容量 （在未来2-3年时间设计的系统架构在不进行系统化重构的情况下可以通过设备或节点 扩展正常支撑业务发展）

3、 N+1原则：

任何业务服务节点永远不要少于两个可独立运行设备（集群服务的前提条件）

4、版本可回退：

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

5、 功能可开关：

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

6、 系统容错：

一个系统总是或多或少出现一些未知的系统问题，但对于用户则不要将类似404、500、502等错误展示在前端（通过技术手段将错误展示页面转至提前准备的友好提示页面，并能从该页面继续进行业务操作）

7、 服务可重用：

这是系统服务化的前提

8、 服务可水平扩展：

水平扩展实现服务集群化以及水平服务能力随时增加，系统要水平扩展非垂直升级。永远不要依懒更大、更快的服务器系统。

9、 松耦合、抽象化：

开发层面的松耦合大家都很熟悉了了，系统架构层面最典型的应用就是模块之间的服务调用，而不是将模块功能内嵌，现在的微服务架构就很好的实现了这个原则

10、 不过度设计：

杜绝浪费是在任何时候都要考虑到的，开源节流中的节流是系统架构设计中需要着重考虑的，虽然前面有DID原则但一个系统的技术架构也不要为未来5年甚至是10年来买单。

11、 使用成熟的技术：

使用成熟技术好处有三点

A、没有太多技术坑，有问题也能很快的找到解决方案

B、学习资料充足，应用成本低

C、市场上技术人员量高，人好招

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

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

2.架构设计组成的关键层级

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

各架构层级间关系 ：

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

2.1.1业务架构的设计原则

2.1.2业务架构的设计实例

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

2.2.1应用架构设计原则

2.2.2应用架构设计过程

1.应用分层

2.应用架构的分解设计原则

3.应用架构的依赖设计原则

4.应用架构的服务设计原则

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

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

数据架构设计原则

典型的数据架构应用

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

2.4技术架构设计原则

2.4.1系统运行时原则

2.4.2系统部署原则

2.4.3根据业务、应用、数据架构进行整体技术架构

3.日均亿级流量应对方案

3.1.系统准备阶段

3.2大流量高并发过程中的流量应对措施

4.架构设计总结